Changelogs

Overview

These changelogs reflect the history of all files in the Subversion repository. The changelog has been generated at 2016-05-09 08:38:04

Changes per page:

25 50 100 250 500 1000 2000

Changelog for wxWidgets (70435 changes):

2010-09-11 12:18 VZ, revision 65520

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".

2010-09-11 12:18 VZ, revision 65519

Add a simple test for keyboard events generation. 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.

2010-09-11 12:18 VZ, revision 65518

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().

2010-09-11 12:18 VZ, revision 65517

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.

2010-09-11 12:18 VZ, revision 65516

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.

2010-09-11 12:18 VZ, revision 65515

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.

2010-09-11 12:18 VZ, revision 65514

Add a convenient wxREGISTER_UNIT_TEST() macro. 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.

2010-09-11 12:17 VZ, revision 65513

No real changes, just some small cleanup in wxMSW keyboard code. No changes, just use more clear variable name ("keycode" instead of "id") and anonymous namespace instead of static keyword.

2010-09-11 11:20 SC, revision 65512

fixing 'main screen'

2010-09-10 21:42 VZ, revision 65511

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.

2010-09-10 21:28 VZ, revision 65510

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.

2010-09-10 19:26 VZ, revision 65509

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).

2010-09-10 19:26 VZ, revision 65508

Fix closing logic in wxMSW native wxProgressDialog. The dialog must always close if the C++ object was destroyed, independently of whether it was cancelled or finished.

2010-09-10 19:26 VZ, revision 65507

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. Document this behaviour even more clearly.

2010-09-10 19:25 VZ, revision 65506

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.

2010-09-10 19:25 VZ, revision 65505

Rename wxGenericProgressDialog::ProgressDialogState to just State. Repeating "ProgressDialog" twice is redundant.

2010-09-10 19:25 VZ, revision 65504

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.

2010-09-10 19:25 VZ, revision 65503

Use determinate mode in native wxMSW wxProgressDialog by default. The dialog was created in indeterminate ("marquee") mode for some reason.

2010-09-10 19:25 VZ, revision 65502

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).

2010-09-10 19:25 VZ, revision 65501

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.

2010-09-10 15:41 SC, revision 65500

adjusting to new gui mutex for osx, see #12411

2010-09-10 13:44 VZ, revision 65499

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.

2010-09-10 13:44 VZ, revision 65498

Initialize wxGenericProgressDialog::m_winDisabler properly. 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.

2010-09-10 13:44 VZ, revision 65497

Don't return false from IsOk() for accelerators without flags. wxAcceleratorEntry::IsOk() checked for m_flags != 0 for some reason. Simply remove this test. See #12444.

2010-09-10 00:20 VZ, revision 65496

Fix infinite loop in wxDateTime::Format() when fields width was used. Just add a missing increment of the loop variable. See #12451.

2010-09-10 00:20 VZ, revision 65495

Fix cast of pointer to int in artprov sample. This prevented the sample from building when using MinGW-64 and also probably prevented it from working correctly on other 64-bit systems. Closes #12453.

2010-09-09 23:57 VZ, revision 65494

Initialize all fields of struct tm used by wxDateTime::Format(). Passing not fully initialized struct tm to strftime() results in Valgrind errors and possible nastiness, see #12455. Simply use memset() to set all fields of this system-dependent struct to 0 initially.

2010-09-09 23:49 VZ, revision 65493

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. Closes #2834.

2010-09-09 23:49 VZ, revision 65492

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.

2010-09-09 23:49 VZ, revision 65491

Very minor fixes to wxKill() documentation. Fix "the the" typo.

2010-09-09 23:48 VZ, revision 65490

Use minimal required process access mask in wxMSW wxKill(). We don't need PROCESS_TERMINATE permission if we are not going to call TerminateProcess() for it.

2010-09-09 22:59 VZ, revision 65489

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?).

2010-09-09 22:53 VZ, revision 65488

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.

2010-09-09 22:34 VZ, revision 65487
  • D /wxWidgets/trunk/src/msw/mediactrl.cpp

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.

2010-09-09 22:33 VZ, revision 65486

No real changes, just don't use obsolete FORCE_LINK_ME in wxMediaCtrl. Use wxFORCE_LINK_THIS_MODULE() instead of the obsolete FORCE_LINK_ME.

2010-09-09 22:33 VZ, revision 65485

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.

2010-09-09 22:33 VZ, revision 65484

No changes, just remove cruft from mediactrl sample. Remove the test for wxUSE_GUI together with the comment questioning its presence.

2010-09-09 22:33 VZ, revision 65483

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.

2010-09-09 12:18 VZ, revision 65482

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.

2010-09-09 10:57 DS, revision 65481

use svn:keywords instead of eol:keywords

2010-09-08 22:01 RR, revision 65480

Unregister configure callback, fixes #12447: wxGTK patch: Segfault on Drag&Drop

2010-09-08 22:00 RR, revision 65479

Unregister configure callback,part of #12447: wxGTK patch: Segfault on Drag&Drop

2010-09-08 19:11 DS, revision 65478

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.

2010-09-07 23:37 VZ, revision 65477

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.

2010-09-07 18:05 SC, revision 65475

resetting the wrapper flag later, otherwise the native destructors dealloc too much, fixes #12448

2010-09-07 08:51 SC, revision 65474

modeling subclassing along msw, unsubclassing filedialog at end of ShowModal, fixes #12236

2010-09-06 15:50 SC, revision 65473

using non-sleep version for GUI mutex, solves #12411

2010-09-05 15:31 SJL, revision 65472

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.

2010-09-05 15:14 SJL, revision 65471

Fix typo from previous commit.

2010-09-05 15:11 SJL, revision 65470

Move the second wxListBox sort test back to the ownerdrawn section and re-enable it under wxGTK.