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

Select Changelog:

FileZilla 3, FileZilla Server,
Legacy FileZilla 2, Legay FileZilla Server

Select page:

[] [1 131 261 391 392 393 394 395 1203 2010 2818] []

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.

Select page:

[] [1 131 261 391 392 393 394 395 1203 2010 2818] []

Imprint