Always use native task dialog for wxProgressDialog under MSW if supported.
Use task dialogs even for the dialogs with wxPD_AUTO_HIDE style flag and
without wxPD_CAN_ABORT one. Generic fallback was used in this case as native
task dialog doesn't support dialogs without buttons but it is finally better
to create a dummy button and use the native dialog nevertheless. We already
have a mostly disabled "Close" button for the dialogs without wxPD_AUTO_HIDE
style so it seems logical to also have it (but just never enable it at all)
when this style is used.
Ignore time component of SYSTEMTIME in wxMSW wxDatePickerCtrl.
This is similar to the fix of r64208 for wxCalendarCtrl and ignores the time
component of SYSTEMTIME objects returned by the native functions in
wxDatePickerCtrl too to ensure that we operate with pure dates only.
Don't use native MSW functions in wxString::CmpNoCase().
While the native CompareString() is much more efficient than MSVC CRT version
of _wcsicmp(), it gives unexpected results for non-letter characters, so don't
use it but use the slow but correct wxStricmp() instead.
At least don't use char-by-char comparison (in non-UTF-8 case) as it's the
slowest possible implementation of this function, the new one using
wxStricmp() is 3 times faster (by comparison, using CompareString() is 16
times faster still -- but wrong).
Add benchmarks for various ways to compare strings.
Benchmark the abstraction overhead of wxString methods compared to plain
functions and also benchmark native functions for string comparison under MSW.
Steve Lamerton [Sun, 19 Sep 2010 10:02:57 +0000 (10:02 +0000)]
Increase the number of expected events in TreeCtrlTestCase::KeyDown and ListBaseTestCase::KeyDown from four to six as this is the number of events seen when testing using their samples. This also stops the tests failing after the recent keyboard event improvements.
Really fix setting fonts in RichEdit 4.1 controls.
The fix applied in r64394 wasn't enough and the control could still decide to
overwrite the font used by default when non-ASCII characters were inserted
into it. To really force it to use the font we want we apparently must send it
EM_SETCHARFORMAT with SCF_ALL flag (MSDN also documents SCF_DEFAULT but it's
not clear if we should use it instead or together with SCF_ALL, for now it
doesn't seem to be necessary).
No changes, just refactor wxTextCtrl::SetStyle() in wxMSW.
Split this overly long function into MSWSetCharFormat() and MSWSetParaFormat().
No real changes otherwise except for the use of PARAFORMAT instead of
PARAFORMAT2 if wxUSE_RICHEDIT2 is not set as it was certainly intended (but
the fact that nobody complained about this problem means that nobody must be
compiling without wxUSE_RICHEDIT2 by now so arguably we should just remove it
completely).
Robert Roebling [Fri, 17 Sep 2010 19:07:02 +0000 (19:07 +0000)]
Postpone EnsureVisible() to idle as this sometimes seems to be required, fixes #12480: wxDataViewCtrl::EnsureVisible does not make item visible in some
circumstances on GTK
Add missing svn:eol-style property to all .cpp files. Also set svn:keywords for .cpp files which don't have that property yet to Id, including src/osx/core/glgrab.cpp for consistency (it doesn't make use of the property).
Allow setting Mac-specific menu item ids to wxID_NONE to suppress them.
If s_macAboutMenuItemId or s_macPreferencesMenuItemId was explicitly set to
wxID_NONE by the application, don't add them to the standard menu at all,
otherwise they would be present there but be always disabled and useless.
This is still not documented because we really need a better API for this but
it at least provides a temporary workaround for having useless menu items
under OS X.
Allow use of report mode non-native wxListCtrl in wxListBook under Mac.
The use of wxListBook in report mode was disabled for wxOSX in r54001 and
r54318 (see #9484) because it created problems with the native wxListCtrl
implementation but the report mode can be used if we're using the generic
wxListCtrl version so do allow to use it if the system option governing the
choice of the version to use is set to "generic".
Of course, the real fix would be to correct the bugs in the native wxListCtrl
version and use report mode always but for now this at least restores correct
behaviour with the generic version.
Only use wxFORCE_LINK_MODULE() in mediaplayer sample in static build.
The linking optimization this macro protects against can't happen when using
DLL and so using it is at best useless and actually harmful (because it
doesn't contain the correct DLL export declarations) in the latter case.
Compilation fixes for non-MSVC 9 compilers after r65555.
Somehow MSVC 9 compiled invalid wxT(__FUNCTION__) expressions but both MinGW
and MSVC 6 (correctly) failed. Don't use this construct at all but instead
call wxLogLastError() with the real function name.
Also refactor the code slightly to avoid having to repeat this fix thrice.
Václav Slavík [Thu, 16 Sep 2010 09:05:48 +0000 (09:05 +0000)]
Fix wxMSW rendering artifacts with modal dialogs.
When a modal dialog showed another modal dialog, parts of the parent
window weren't refreshed correctly. This demonstrated itself as
rendering artifacts when moving the child dialog to another position:
parts of the dialog were shown as disabled, parts as enabled.
Remove display information caching from MSW wxDisplay implementation.
Don't cache display rectangle and client rectangle as they can both change
during the program lifetime (especially the latter which changes whenever
taskbar is moved or shown/hidden) and retrieving them every time they're
needed doesn't seem to be a problem performance-wise anyhow.
We still cache the list of all the monitors, ideally we'd refresh it when we
receive a notification about a display being [dis]connected.
Fix possible errors introduced while generating Xcode project.
Under some unknown circumstances two added source files are concatenated into one faulty entry in an Xcode project (this probably occurs either at the Xcode or XMLTools2 level). Try to detect these errors in the Python script and fix them by patching up the project.pbxproj file.
Update the text hint display correctly when ChangeValue() is called.
wxTextEntry::ChangeValue() doesn't generate any events so we need to
explicitly update the text stored by wxTextEntryHintData when it is called to
ensure that it corresponds to the real controls value.
Fix several bugs in generic text entry hints implementation.
The text controls contents and colour was not updated correctly in several
situations (see #12475).
The old code was completely wrong as it didn't store the actual value of the
control at all and so could never work. Do store and update it now and show
the hint if and only if the real contents is empty.
Also handle "text updated" event to correctly update the hint when the control
becomes [non-]empty.
Fix wxTextEntry::SelectAll() in presence of hints in wxGTK.
Translation of wx (-1, -1) selection to (0, GetValue().length()) in
wxTextCtrl::SetSelection() was unnecessary as it ended up calling the base
class wxTextEntry::SetSelection() version which didn't need it. Moreover, this
translation was actually harmful when the text control happened to show a hint
string as its official value was empty in this case and so SetSelection(0, 0)
was called which didn't do anything and broke clearing/changing the controls
text when it was showing a hint.
Simply don't translate the indices when using a single line control to fix
this.
Make Xcode identifier consecutive when there is a collision.
Making them consecutive groups source files that are repeated next to each other in the project file like Xcode does, instead of creating a complete new random identifier which resulted in creating a distance between the source files after they were sorted.
Václav Slavík [Tue, 14 Sep 2010 18:35:50 +0000 (18:35 +0000)]
Click on wxOwnerDrawnComboBox's animating popup should close it.
Previously, it behaved differently from native combo box: clicking the
popup while its opening animation was running had no effect. This was
different from the native control, which would close the popup in this
case (just like when it's fully opened).
Fix drawing of items with custom background in wxGenericListCtrl.
This was broken by the changes of r64879 which erroneously used
wxRendererNative::DrawItemSelectionRect() even for the non-selected items.
Now only use DrawItemSelectionRect() for the selected items to make them
appear natively while drawing the non-selected items with custom background
colour ourselves.
Also refactor the code to avoid (the not quite and hence especially
pernicious) duplication between wxListLineData::Draw() and DrawInReportMode():
rename SetAttributes() to ApplyAttributes() and draw the item background in
this function now instead of doing it in both Draw() and DrawInReportMode().
Delete wxListCtrl item data after handling its deletion event in wxMSW.
We deleted the data associated with the item too soon as we did it before the
handler for the item deletion event was run and this handler could still
access this data.
Robert Roebling [Sun, 12 Sep 2010 20:07:28 +0000 (20:07 +0000)]
Moved more code from wxDataViewCtrl to wxDataViewCtrlInternal.
Add new special API for wxDataViewVirtualIndexModel::Reset() as
wxDataViewModel::Clear is something different and needs a different, two
step API under GTK+, one for destroying the current view and one for
rereading the new contents.
Added ::BeforeReset() and ::AfterReset() notifications for that purpose.
Generate the same flags for modifier key events in wxGTK as in wxMSW.
Resolve the discrepancy between modifier flags of the key events corresponding
to the modifier key itself between wxMSW and wxGTK by changing the latter to
follow wxMSW behaviour.
Clearly document the now officially correct behaviour of the modifiers for the
key events corresponding to the modifiers keys themselves in the manual.
This fix also makes it unnecessary to work around this bug in the keyboard
unit test so remove it from there.
Generate unshifted Unicode key codes in wxEVT_KEY_XXX events in wxGTK.
wxGTK generated wxEVT_KEY_XXX with key codes corresponding to the unshifted
state of the key (except for the letters) but Unicode key codes corresponding
to the current shift state. This was inconsistent with wxMSW and also with the
idea that key events, unlike char ones, don't depend on the modifiers states.
Change wxGTK to behave as wxMSW and use unshifted values for Unicode key codes
as well.
Remove the now unnecessary workaround for different key event Unicode codes
from test.
Also try to explain the difference between normal and Unicode keys and key and
char events even better and mention that the Unicode key codes for the key
events are also untranslated in the documentation.
Fix generation of key events for non-alphabetic keys under Windows.
Don't hardcode the values of VK_OEM_XXX keys which are completely nonsensical
on keyboards with non-US layouts. Use the real unshifted value of the key as
its key code instead -- at least if it's a Latin-1 character. Otherwise, use
WXK_NONE as the key code and pass the character generated by the key as
Unicode character code.
Also generate WXK_NONE events for dead keys to avoid confusing them with the
corresponding normal key events.
Rename wxCharCode{MSWToWX,WXToMSW}() and move them to a separate header.
These functions were confusingly named as they work with MSW (virtual) key
codes and not character codes, rename them to better indicate what they do.
They also don't need to be in wx/msw/window.h included by all wx code when
they are only really needed in a couple of files, so move them to a private
header.
Fixes to key codes in keyboard events generated by wxMSW.
Only set Unicode key code if the event corresponds to a character key and set
it to (newly added) WXK_NONE for the other ones to avoid nonsensical values in
it for e.g. "Home" key presses.
Also set non-Unicode key to WXK_NONE for the characters that can't be
represented in the current locale. This is consistent with wxGTK and avoids
conflicts between special key values and Unicode keys.
Clearly document the above behaviour.
Notice that implementing the correct behaviour in wxMSW involved untangling
previously interwoven WM_KEY{DOWN,UP} and WM_CHAR messages handlers. Clearly
separate them now as they get different input (key codes for the former,
characters for the latter) and especially don't try to convert from both kinds
of input using a single wxCharCodeMSWToWX() function. As this function doesn't
need to distinguish between keys and characters any more it can simply return
the converted value in all cases instead of returning 0 sometimes to indicate
a character value instead of a key. Simplify the code using this function
accordingly.
Add WXK_NONE symbolic constant indicating absence of a key.
wxKeyEvent::GetKeyCode() and GetUnicodeKey() return 0 to indicate that the key
code or Unicode character is not available, give symbolic name to this 0 to
make the code using these methods more clear.
No real changes, just use KF_EXTENDED instead of hard-coded bit mask.
KF_EXTENDED is defined in Windows headers as the mask for extracting the
"extended" bit from LPARAM of the keyboard messages. Use it instead of
explicitly writing less clear "1 << 24".
Check that the events generated by wxUIActionSimulator result in the same
wxKeyEvents being generated under all platforms. This is not the same as
checking the event generation for the actual keys pressed by the user as there
are some small differences between the two but better than nothing.
Generate correct events for extended keys in wxMSW wxUIActionSimulator.
Simulating keys such as WXK_END resulted in WXK_NUMPAD_END event being
generated instead of the expected WXK_END one.
Fix this by returning from wxCharCodeWXToMSW() whether the key code is a
normal or extended one and use this to set KEYEVENTF_EXTENDEDKEY in
wxUIActionSimulator::DoKey().
Remember the last key event in wxGTK before passing it over to IM.
Save the last key event before calling IM filter to be able to get the correct
modifiers, timestamp, position &c to use for the CHAR event generated from IM
commit callback.
This restores the changes of r34504 which were reverted for unknown (or at
least unmentioned) reason in r34521.
Explicitly send events for modifier keys in wxUIActionSimulator.
Key down/up events for the modifiers were already explicitly sent under wxMSW
and wxOSX but not under wxGTK where, as the result, the corresponding events
were not generated at all.
Do send these events explicitly to make the events generation consistent under
all platforms now. This means that wxUIActionSimulator::DoKey() now generates
exactly one event everywhere.
Notice that the modifiers for the key events generated by the modifier keys
are also the same under all platforms now which is not the case for the events
actually generated by the user (wxMSW sets the corresponding bit for the
modifier key down event but not the key up one while wxGTK does exactly the
contrary). This should be fixed in the future so that wxUIActionSimulator
generates the same sequence of events as the user would and that it's still
the same for all platforms.
Remove assert checking for wxMOD_CONTROL from wxUIActionSimulator.
It doesn't make sense to fail if modifiers parameter includes wxMOD_CONTROL
telling the caller to use wxMOD_CMD instead as the latter is exactly the same
as the former under non-Mac platforms.
This macro can be used to easily register a test following a standard naming
convention in both the global test suite and the test suite with the same name
as this test instead of having to use 2 different cppunit macros to do the
same thing.
Use wxLocale::GetInfo() to get date format in wxDatePickerCtrlGeneric.
Instead of trying (and failing) to manually decode the format used by "%x",
simply use wxLocale::GetInfo(wxLOCALE_SHORT_DATE_FMT) and just change "%y" to
"%Y" if necessary.
The new code is more than 10 times shorter and also gives correct results
unlike the old version.
Don't add spurious NULs at the end of wxTextDataObject text under OS X.
For some reason we added an extra NUL character to the data copied from
wxTextDataObject but this doesn't seem necessary because the Pasteboard API
is passed the correct data size and so the string doesn't need to be
NUL-terminated.
In fact, adding this NUL broke drag and drop between wx and native controls,
including the case of dropping text in our own wxTextCtrl as this uses its
built in support for dnd and not our code (the fact that we can't even set a
drop target for a wxTextCtrl is a separate bug). In this case we got a string
with an extra NUL in the control resulting in all sorts of hard to debug
problems.
So simply don't add the extra bytes, dnd works fine without them both between
wx windows and from/to another OS X applications.
Initialize wxGenericProgressDialog button members in Init() too.
wxGenericProgressDialog::m_btn{Abort,Skip} were not initialized neither which
resulted in crashes inside EnableAbort() which was called if the "Cancel"
button was pressed in a native MSW dialog but the dialog wasn't cancelled (and
hence the button needed to be reenabled).
Block in wxMSW wxProgressDialog::Update(max) until the dialog is dismissed.
For consistency with the generic version and because it makes more sense than
blocking in the dialog destructor (which is the only other alternative for the
dialogs without wxPD_AUTO_HIDE to work), we should block in Update() when the
maximal value is reached for dialogs without wxPD_AUTO_HIDE style until the
dialog is dismissed.
Fix errors in handling of maximum field in wxGenericProgressDialog.
Provide a SetMaximum() function for setting just m_maximum and return its
value from GetRange() instead of using m_gauge->GetRange() which doesn't work
when the native MSW version is used nor when the range is > USHRT_MAX under
MSW in any case.
More generally, this should fix a lot of bugs for progress dialogs using such
range as the values were not interpreted correctly in many places.
No changes, just use less long progress dialog states names.
We can refer to them using wxProgressDialog class name and not the base
wxGenericProgressDialog so do this as it is shorter and more clear because
these states have nothing to do with the generic version when used by the
native MSW implementation.
Add a possibility to show a progress dialog on dialog sample startup.
Add a command line option to the dialogs sample to allow testing of different
wxProgressDialog styles more easily. This also tests for showing them before
the main event loop is started (see r65499).
Don't use wxGenericProgressDialog::m_windowStyle for wxPD_XXX styles.
Storing progress dialog styles in the normal window style didn't work because
they clashed with the TLW styles. The original progress dialog implementation
worked around this by using separate m_has{Abort,Skip}Button variables instead
of relying on wxPD_CAN_{ABORT,SKIP} style bits but this didn't work for the
other styles and was unclear so the new native MSW implementation blithely
used m_windowStyle to test or them and other bits which didn't work at all,
see #12416.
Solve this by using a separate m_pdStyle variable for storing the progress
dialog styles and use it for all wxPD_XXX tests in both the generic and MSW
code. This fixes some bugs (although not all of them yet) and allows to get
rid of m_has{Abort,Skip}Button.
Create temporary wxEventLoop in wxGenericProgressDialog if needed.
wxGenericProgressDialog needs to have an active event loop in order to repaint
itself and process clicks on its buttons but it's more helpful to create a
temporary event loop if there is no currently active one instead of just
asserting. In particular, this allows to use wxProgressDialog from overridden
wxApp::OnInit().
Add temporary event loop creation and remove the now unnecessary asserts
verifying that there is an active event loop as there always will be one.
This field wasn't initialized by Init() which might have been harmless
considering the current code structure but still untidy, do set it to NULL
there.
Also move the forward declaration of wxWindowDisabler class in
wx/generic/progdlgg.h to the top of the file for consistency with the other
forward declarations.
Fix wxKill(wxSIGNONE) always returning true for child processes in wxMSW.
The fact that a handle to a process can be opened doesn't mean that the
process is still running. In fact, for a child process that we store a handle
for ourselves we will always be able to open (another copy of the) handle even
if it already terminated.
Check for the process termination using WaitForSingleObject() instead in both
normal and wxSIGNONE cases.
Also simplify the code by not using GetExitCodeProcess() at all as we don't
need the process exit code.
Remember last values used in exec sample "Kill" menu item dialogs.
Remember the PID entered in the dialog and also remember the last used signal
number. This makes these dialogs slightly less painful to use when testing
even though ideally we'd have a single dialog for choosing both values instead
of two consecutive modal dialogs.
Don't filter out Cairo libraries from GTK libraries list in configure.
This undoes the hack of r35357 which surreptitiously removed all Cairo
libraries from the GTK libraries list. This shouldn't be necessary any more as
we use Cairo calls in our own code and so can't run without it anyhow and in
fact is even actively harmful as it results in linking errors under Fedora 13
(which seems to use a slightly different linker?).
Use the same logic for closing dialogs as for handling Escape key.
Pressing "Esc" key closed the dialog with only wxID_OK button (but no
wxID_CANCEL one) by default but pressing the "close window" button only closed
it if wxID_CANCEL was present.
Fix this by using the same code in OnCloseWindow() as in OnCharHook(), after
extracting it into the new SendCloseButtonClickEvent() method.
Remove the unused "monolithic" MSW wxMediaCtrl file.
The contents of this file was split over src/msw/mediactrl_{am,qt,wmp10}.cpp a
long time ago and this file is unused and not compiled into the library so
having it in the repository is useless and confusing -- remove it.
Force linking of all wxMSW wxMediaCtrl backends in mediactrl sample.
Force the linker to include all the backends in the sample executable instead
of discarding them because they are not used directly to allow testing all of
them in the sample.
Remove debugging wxLogMessage from wxMediaCtrl::Create().
This was added apparently by mistake in r45478 and resulted in showing the
backend being used by the control in a message box whenever it was created
ever since.
Don't exclude "contrib" from wxMSW setup.exe generation.
This was presumably needed to exclude the top level contrib directory but also
seems to apply to src/tiff/contrib and excluding this directory breaks
configuration of libtiff as it looks for src/tiff/contrib/Makefile.in.
As we don't even have top level contrib any more, simply don't exclude it any
longer.
Make Xcode identifiers in generated project files be the same after each run.
From the AppleScript that composes the Xcode projects call a Python script that bases the identifiers on an associated name instead of being random each run like Xcode does. After the Python script reopen the project again in Xcode to have the identifiers sorted (Xcode wants them to be), resulting in the project.pbxproj file being completely different inside but in the IDE the order of files still will be the same.
Use correct Unicode define for wxScintilla compilation.
Compilation of wxScintilla with Borland failed because -D_UNICODE was not
passed on command line resulting in mismatches between wxChar and Windows
TCHAR. It's a mystery why this didn't happen with the other compilers but
defining _UNICODE for them too can't hurt.
Steve Lamerton [Sun, 5 Sep 2010 13:31:13 +0000 (13:31 +0000)]
Simplify ButtonTestCase::Bitmap. The old test was not correct as it tested all bitmaps to see if they were valid, however these do not get set by SetBitmap and so the tests only passed if the platform set valid defaults.
Improve main and extended messages handling in new wxMSW wxMessageDialog.
Don't use the main message if there is no extended message: this looks bad as
the main message is emphasized to contrast with the extended one which doesn't
make sense visually if there is no extended message.
Also recognize the common use of wxMessageBox() with a multiline text composed
of the first string that plays the role of the main message with the rest
being the extended one and handle this appropriately automatically. This
results in a better appearance by default for a lot of message boxes,
including even the one in our own minimal sample.
Add a link to Microsoft guidelines from wxICON_QUESTION documentation.
Microsoft documentation provides explanations as to how the icons should be
used in the message dialogs which can be useful for people wondering which
icon style to use an when.
projects / wxWidgets.git / log
