Paul Cornett [Tue, 16 Aug 2011 07:02:37 +0000 (07:02 +0000)]
Avoid creating rect with negative size while clipping to DC size.
Also, don't convert result of wxDC::GetSize() to device coords, it's already device coords.
Vadim Zeitlin [Sun, 14 Aug 2011 19:39:31 +0000 (19:39 +0000)]
Fix return value of wxMBConvUTF8::ToWChar() when not using MAP_INVALID_UTF8_NOT.
wxMBConvUTF8::ToWChar() was off by 1 when the input length was explicitly
specified, the extra NUL should only be added in the implicit length case.
This bug didn't occur for the default wxMBConvUTF8 object as it simply
forwarded to the base class wxMBConvStrictUTF8 implementation but it happened
when MAP_INVALID_UTF8_TO_OCTAL or MAP_INVALID_UTF8_TO_PUA was used.
Vadim Zeitlin [Sat, 13 Aug 2011 13:54:26 +0000 (13:54 +0000)]
Fix bitmap position attribute name in XRC handler.
Bitmap position attribute was called "bitmapposition" in the documentation and
in the code that generated an error message for a wrong value in it but was
inexplicably called "direction" in the code that really looked it up.
This seems to be just a straight typo from the original r61065. Surprising as
it is that it wasn't noticed before, do correct it now.
Vadim Zeitlin [Fri, 12 Aug 2011 14:09:41 +0000 (14:09 +0000)]
No changes, just remove gratuitous inefficiency from generic wxDVC.
Don't return wxDataViewMainWindow::m_selection array by value, returning a
const reference to it is enough and avoids completely unnecessary memory
allocations and copying of potentially large amounts of data.
Also make wxDataViewMainWindow::GetSelections() const.
Vadim Zeitlin [Fri, 12 Aug 2011 14:09:37 +0000 (14:09 +0000)]
Fix compilation of generic wxDVC code when not using STL containers.
wx sorted containers don't implement iterators so use indices to iterate over
wxDataViewMainWindow::m_selection, just as r68613 already did in another place.
Vadim Zeitlin [Thu, 11 Aug 2011 10:56:05 +0000 (10:56 +0000)]
Use separate strings for stock labels with and without mnemonics.
Obtaining the string without mnemonics by simply removing "&" characters from
the string containing mnemonics doesn't work for some languages, notably
Chinese where the convention is to use "Chinese Text (&M)" for the labels with
"M" being the ASCII mnemonic and just "Chinese Text" and not "Chinese Text (M)"
should be used if wxSTOCK_WITH_MNEMONIC flag is not specified.
Fix the fundamental problem by using separate strings for the two cases.
Translations still need to be updated to really correct the labels appearance.
Since r68621 dataview.cpp didn't compile anymore (at least with wxOSX-Carbon). Fixed by explicitly using wxDataViewItem's void * constructor in a few cases.
The code to update m_selection was too aggressive in the virtual list
case, when it simply cleared it, and broken for single-item selection in
the general case.
Fixed to recompute selection properly.
Václav Slavík [Wed, 10 Aug 2011 15:21:22 +0000 (15:21 +0000)]
Make the wxDataViewItem(void*) constructor explicit.
Not having this as an implicit one made it possible to create
wxDataViewItem from any pointer without realizing it, leading to hard to
debug crashes later.
Added NSApplicationDelegate's openFiles for wxOSX-Cocoa.
openFiles (available since OS X 10.3) replaces using the openFile method. It allows for more convenient handling of multiple drops and knowing in advance how much files/folders are dropped instead of openFile with which you only get to respond to a single file/folder drop at a time. By default openFiles calls the newly added MacOpenFiles which calls MacOpenFile multiple times, so ordinarily the behaviour is backwards compatible (both on wxOSX Cocoa and Carbon).
The openFile instance method has been removed because it doesn't seem to be called anymore: neither when dropping a single file on the application in the dock or Finder nor when passed as a command-line argument.
Vadim Zeitlin [Mon, 8 Aug 2011 15:15:50 +0000 (15:15 +0000)]
Don't manually centre dialogs created with default position in wxMSW.
We always centered the dialogs on the main display which was wrong if the
parent window was on another one. Instead of fixing it, simply don't centre
them at all and let Windows position them, there is no reason to change the
default behaviour.
Václav Slavík [Mon, 8 Aug 2011 10:11:04 +0000 (10:11 +0000)]
Remove selection methods taking int from generic wxDataViewCtrl.
Current public API uses wxDataViewItem, this code dated back to 2.8.
They were now protected instead of public, the code wasn't used
anywhere and wasn't portable, it existed only in the generic version.
Vadim Zeitlin [Mon, 8 Aug 2011 09:32:39 +0000 (09:32 +0000)]
Added private wxMenu::MSWNewFromHMENU() method.
Add a method allowing creation of a wxMenu object from a native menu handle.
This will be used to implement access to the system menu in an upcoming commit
but could also be useful for other purposes.
Vadim Zeitlin [Mon, 8 Aug 2011 08:33:19 +0000 (08:33 +0000)]
Fix compilation with g++ 4.7 (prerelease).
The workaround for a bug in g++ 3.5 breaks compilation with 4.7 which
implements two-phase lookup correctly, so disable this workaround for 4.7 and
later. We could probably even only enable it for 3.x but this doesn't really
matter as previous 4.x releases don't have problems with this anyhow.
Vadim Zeitlin [Thu, 4 Aug 2011 22:53:42 +0000 (22:53 +0000)]
Add support for wxHELP button to wxMessageDialog.
Implement support for wxHELP for wxMSW, wxGTK and wxOSX/Cocoa (at least when
showing the message box from the main thread, there doesn't seem to be any way
to show more than three buttons with CFUserNotificationDisplayAlert() so
"Help" button is not supported when using it).
This is useful not only on its own, i.e. to allow the user to ask for help,
but also because it brings the total number of buttons supported by the
message dialog to 4, meaning that more choices can be offered to the user
(which is rarely, but not quite never, useful).
Vadim Zeitlin [Thu, 4 Aug 2011 16:12:41 +0000 (16:12 +0000)]
Add missing header for minimalistic builds not using PCH.
wxWindow might not be fully declared in dcbase.cpp but we need its full
declaration for wxDCImpl::InheritAttributes() so explicitly include
wx/window.h -- while this is usually already included from somewhere else it
might not be in minimal builds with a lot of features disabled.
Vadim Zeitlin [Thu, 4 Aug 2011 16:12:31 +0000 (16:12 +0000)]
Use wxWindowMSW instead of wxWindow to fix wxUniv/MSW compilation.
wxFindWindowAtPoint() only returns wxWindowMSW, not the derived wxWindow, in
wxUniv build so assign its return value to wxWindowMSW to avoid compilation
problems in it.
Vadim Zeitlin [Thu, 4 Aug 2011 13:19:57 +0000 (13:19 +0000)]
Avoid unwanted line break in wxDataViewListModel::GetCount() docs.
Using "i.e." in the brief Doxygen comment makes it end it after the second
period and results in truncated brief description and an unwanted line break
in the full description.
Just avoid using periods for now inside the brief description. Maybe a better
solution could be found in the future.
Vadim Zeitlin [Wed, 3 Aug 2011 00:45:42 +0000 (00:45 +0000)]
Fix bug with TAB being able to switch focus between MDI frames.
The keyboard navigation code correctly checked that TAB was not propagated
above the TLW containing the window in which the key was pressed to avoid
switching focus between different TLWs by pressing TAB.
However wxMDIChildFrame is not a TLW and so it was possible to switch focus
between two different MDI child frames by pressing TAB. This was unexpected
and counterintuitive, especially because the frame receiving focus was not
even activated (which might be another bug).
Fix this by adding a new wxWindow::IsTopNavigationDomain() virtual method that
can be overridden to indicate that a window is a self-contained "keyboard
navigation domain" and that keyboard events shouldn't propagate outside of it
and override it in both wxTopLevelWindow and wxMDIChildFrame to ensure that it
behaves correctly.
Vadim Zeitlin [Wed, 3 Aug 2011 00:45:38 +0000 (00:45 +0000)]
No real changes, just rename a variable.
"focussed" spelling is unusual and inconsistent with "focused" used in many
other places in the same file, so renamed "focussed_child_of_parent" and also
use standard camelCase naming convention for it.
Vadim Zeitlin [Tue, 2 Aug 2011 19:46:40 +0000 (19:46 +0000)]
Fix wxSocket::WaitForAccept() in blocking mode.
When wxSocket::WaitForAccept() was called from another thread or on a socket
with wxSOCKET_BLOCK flag it didn't work because it called
wxSocketImpl::Select() with wxSOCKET_CONNECTION_FLAG which was only handled
for the client sockets in this function.
Handle it now for the server ones too, this should allow blocking server
sockets to work again.
Václav Slavík [Sun, 31 Jul 2011 13:25:33 +0000 (13:25 +0000)]
Silence Clang warning about numeric_limits<> specialization.
libstdc++ (which is used by Clang) defines numeric_limits<> as a struct
and Clang issues a warning about our specialization that uses 'class'.
As libstdc++ developers have no intention of fixing this, silence the
Clang warning by using 'struct' for it.
Václav Slavík [Sun, 31 Jul 2011 13:25:30 +0000 (13:25 +0000)]
Disable symbols visibility support for the Clang compiler.
Even Clang++ shipped with Xcode 4.1 still can't handle visibility
of non-inline methods in exported template classes if the default
visibility is 'hidden'.
Disable visibility support for Clang for now, we'll revisit it in the future.
Generate events with WXK_NONE Unicode keys for non-characters in wxOSX.
The keyboard keys not corresponding to real characters, such as cursor arrows
or function keys, must generate wxKeyEvents with WXK_NONE as Unicode key code
to make it possible to distinguish them from the printable characters but
wxOSX generated events with valid Unicode key codes for them instead.
Avoid this by excluding Unicode key codes corresponding to code points in the
Unicode private use area: while this doesn't seem to be documented anywhere,
all non-printable characters seem to have their Unicode representation inside
it.
This change brings wxOSX keyboard event generation in line with the other
ports and, as a side effect, also closes #12423.
Avoid bogus focus loss event when wxTextCtrl is modified in wxOSX.
A wxEVT_KILL_FOCUS event was generated when wxTextCtrl::WriteText() was called
in wxOSX, even though the control didn't lose focus at all in this case. This
was completely unexpected and thoroughly confused wxGrid code which closed the
in place editor immediately after showing it because of this (this was perhaps
only the case since r68319 but the changes there were correct so they only
masked the real bug).
Avoid this bogus event by remembering the NSView currently being
programmatically modified and not doing anything in textDidEndEditing
notification if it is generated for this view.
Improve wxTextCtrl::GetNumberOfLines() unit test and documentation.
First, enable execution of the Lines() wxTextCtrl unit test case under wxOSX
as it passes since the fix in the previous commit.
Do add a test for GetNumberOfLines() that currently doesn't work in the same
way under all platforms -- but with this test we at least can be sure how does
it work exactly where.
Also mention the current discrepancy in this function behaviour in the
documentation.
See #12366.
Fix Lines() wxTextCtrl unit test to pass under wxGTK too.
No modifiers were used for stock accelerators, i.e. Append(wxID_NEW) resulted
in an item with the label "New" and plain "N" as accelerator in wxOSX. This
was due to wxACCEL_CMD not being handled in wxAcceleratorEntry::ToString() so
map it to the same prefix as wxACCEL_CTRL there, this is enough to make the
accelerators work even though it's not clear whether this is really the best
thing to do or if we should use a separate "Cmd+" prefix for it (and recognize
it in Parse() too then) as otherwise it's unclear why do we have wxACCEL_CMD
at all, it just seems to be treated identically to wxACCEL_CTRL everywhere.
Get rid of ugly wxCONTROL_ITEMCONTAINER_CLIENTDATAOBJECT_RECAST macro.
Replace it with wxWindowWithItems<> template class which takes care of
disambiguating between the two inherited Get/SetClientXXX() versions and use
it as a base class in all clases that previously used the macro.
Resolve ambiguity between GetClientXXX() methods in wxOSX wxComboBox.
Use wxCONTROL_ITEMCONTAINER_CLIENTDATAOBJECT_RECAST for wxOSX/Cocoa too, not
only for wxOSX/Carbon. This macro adds methods to explicitly disambiguate
between the two inherited versions of each GetClientXXX() method, the one from
wxItemContainer and the other one from wxEvtHandler.
Compilation fix: include wx/event.h from wx/containr.h.
We now need wxEVT_XXX constants declarations in this file (at least when not
wxHAS_NATIVE_TAB_TRAVERSAL) so include wx/event.h to fix PCH-less build of
wxOSX.
OS X' wxComboBox::Init does not exist anymore since r68366 but an implementation still was present in combobox_osx.cpp which is used in Cocoa compilation. Removed the function.
At least apple-gcc 4.0 and 4.2 gave a compilation error on the three Connect calls in containr.h, insisting (unless using -fpermissive) on a declaration of Connect because there are no arguments to it that depend on a template parameter. Fixed by prepending BaseWindowClass to the Connect calls. Regression since r68363.
Exclude windows not accepting keyboard focus from GTK focus chain.
For some reason the test for AcceptsFocusFromKeyboard() wasn't done in the
correct place when constructing the GTK focus chain and even windows returning
false from it were still added to it.
Do not do this any more, this prevents the windows which are really not meant
to be focusable from keyboard (such as the pseudo-buttons in the generic
implementation of wxSearchCtrl) from gaining focus unexpectedly.
Replace wxControlContainer-related macros with wxNavigationEnabled<>.
Simply inherit classes which need to provide TAB navigation among their
children from wxNavigationEnabled<> and remove the now unnecessary
WX_DECLARE_CONTROL_CONTAINER() macros.
Also remove WX_INIT_CONTROL_CONTAINER(), WX_DELEGATE_TO_CONTROL_CONTAINER()
and WX_EVENT_TABLE_CONTROL_CONTAINER() which are not needed neither any more.
And remove the event tables which became empty after removing the last macro.
Don't give focus to wxSearchButton when using keyboard navigation.
The search control buttons don't show that they have focus and are not meant
to have it anyhow as they are more control decorations than real buttons and
their functionality can be activated by pressing "Enter" or "Escape" already
from the keyboard. But giving it to them made TAB behave unexpectedly and
wrongly when wxSearchCtrl had focus.
Override AcceptsFocusFromKeyboard() to return false to correct this.
Use wxNavigationEnabled<> for keyboard navigation in generic wxSearchCtrl.
Derive generic wxSearchCtrl implementation from wxNavigationEnabled<> to
ensure that TAB navigation works correctly in it. While it did work before for
search controls without wxTE_PROCESS_ENTER style (because this wasn't handled
by this control itself at all in fact), it stopped working as soon as this
style was used in wxMSW because then the navigation was implemented by
manually calling wxWindow::Navigate() and this requires wxControlContainer
support.
Use wxNavigationEnabled<> to easily add it to wxSearchCtrl.
Add wxNavigationEnabled<> helper for implementing TAB navigation.
Provide a clean, public and documented way to implement proper TAB navigation
for subwindows of a composite control: instead of using various ugly and never
documented WX_XXX_CONTROL_CONTAINER macros it is now enough to simply inherit
from wxNavigationEnabled<BaseClass> to do it.
No real changes in the code as the new class is not used anywhere yet.
Ignore WM_CLOSE generated by wxMSW edit control when Escape is pressed.
Multiline edit control posts WM_CLOSE to its parent window when Escape key is
pressed inside it for some reason. This is unwanted as it totally bypasses our
logic for only closing the dialog when Escape is pressed if there is a
Cancel-like button in it, so suppress this behaviour by not letting the edit
control to get Escape at all.
Don't create an unnecessary extra button in wxMSW wxProgressDialog.
MSWCommonTaskDialogInit() now (probably since r67620) always creates a
IDCANCEL button so don't create another one in wxProgressDialog code, just
ensure that the one created by that function has the correct label (either
"Cancel" or "Close").
Set wxDidCreatePaintDC to true even if we reused a cached wxPaintDC.
Reusing a cached wxPaintDC should count as painting the window, otherwise we
could call DefWindowProc(WM_PAINT) if WM_PAINT was generated from inside
EVT_PAINT handler (e.g. by calling wxWindow::Update()) and this validated the
entire window and no painting was really done.
In particular this fixes redrawing of wxStyledTextCtrl which does call
Update() (completely unnecessarily AFAICS) from its EVT_PAINT handler when it
wants to fully refresh itself.
This method can be overridden to customize the previously hard-coded handling
of the case when a file selected from the MRU menu doesn't exist any more: we
used to always remove it from the file history completely. This may, however,
be inappropriate and, in fact, probably never, or very rarely, is the right
thing to do when the file that we failed to open still exists.
So never remove the file from the MRU if we failed to open an existing file
(also don't give an error about it as it should have been already given by
CreateDocument()) and, while we still do it for the non-existent files, allow
to override this behaviour by overriding the new OnMRUFileNotExist() method.
Allow passing the error value to wxStreamBase::Reset().
It can be useful to induce an error on the stream explicitly, e.g. because an
incorrect value was read from it and we want to indicate it to the caller by
setting stream error to wxSTREAM_READ_ERROR.
Allow to do this by passing an optional error value to wxStreamBase::Reset().
Add an example of using the new functionality to the docview sample which
needs it to be able to signal errors while reading the files.
Also document this method that previously wasn't documented at all.
Don't pass spin text control messages processed at wx level to Windows.
Windows messages handled at wx level shouldn't be processed again at Windows
level but we always passed the events forwarded by spin control "buddy" text
window to its default window proc as we had no way to determine whether they
were really handled or not.
Now we do have a way to do, by using the newly added MSWHandleMessage(), so
only pass the messages to default window proc if they hadn't been handled
already.
This notably suppresses the annoying beep which happened if Enter key was
pressed in a wxSpinCtrl with wxTE_PROCESS_ENTER style (as used by the
corresponding wxDataViewCtrl renderer, for example). It probably corrects some
other bugs/discrepancies with the other ports in event handling in wxSpinCtrl
too.
Refactor wxWindow::MSWHandleMessage() out from MSWWindowProc().
This commit just refactors the code without changing anything in its
behaviour and will be followed by the real changes in the next one.
The new function just handles the message, without calling MSWDefWindowProc()
if it wasn't handled. This allows to call it and determine whether the message
was really handled and only continue processing it if it wasn't.
Notice that while in theory this shouldn't be necessary because the return
value of MSWWindowProc() should indicate whether the message was handled or
not (0 meaning that it was, for most messages), in practice it doesn't work
because many standard controls window procs return 0 even for message they do
nothing with, e.g. "up down" control always returns 0 for WM_CHAR messages
even it it only really handles the arrow keys.
projects / wxWidgets.git / log
