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 4 7 10 11 12 13 14 949 1883 2818] []

Changes per page:

25 50 100 250 500 1000 2000

Changelog for wxWidgets (70435 changes):

2014-12-05 23:18 VZ, revision 78238

Make all bitmaps of the same size in the toolbar sample. This is a requirement under MSW and resulted in problems when a secondary toolbar was created. Closes #16707.

2014-12-05 23:18 VZ, revision 78237

Don't use right-to-left markers in wxMSW wxMessageDialog code. This mechanism is provided as an alternative to specifying MB_RTLREADING style, e.g. if the source code can't be modified but the [string] resource from which the message box message is loaded can be. We don't need to do this if we do add MB_RTLREADING however.

2014-12-05 23:18 VZ, revision 78236

Fall back to default process layout direction in wxMSW. Add helper wxApp::MSWGetDefaultLayout() static method and use it instead of wxTheApp->GetLayoutDirection() in wxMSW code. This serves two purposes: first, wxMessageDialog doesn't crash when it's shown before wxTheApp is created (or after it's destroyed) any more. And second, we use the correct layout direction if the main application has enabled it by calling SetProcessDefaultLayout() or using two U+200E characters in the beginning of its "FileDescription" resource field by default now.

2014-12-05 23:18 VZ, revision 78235

Use the layout direction of wxTextCtrl itself, not the app, in wxMSW. A wxTextCtrl inside an RTL window in an otherwise LTR application should still be considered RTL, it's not clear at all why do we need to ask the application for the layout here, so change this for consistency.

2014-12-05 23:18 VZ, revision 78234

Don't dereference wxTheApp unconditionally when showing wxMessageDialog. The application might not yet (or already) exist, don't crash in this case.

2014-12-05 23:18 VZ, revision 78233

Fix crash when using wxMessageBox before creating wxTheApp. CheckIfCanBeUsedAsParent() used by wxMessageBox ctor shouldn't dereference wxTheApp unconditionally, otherwise it's impossible to show a message box before creating the application object or after destroying it without crashing.

2014-12-05 23:18 VZ, revision 78232

Don't put wxMenu::MSWGetMenu() inside wxUSE_OWNER_DRAWN check. This doesn't make any sense, this function is not related to the owner drawing code at all and should always be available. This corrects the changes of r70316, see #13851.

2014-12-05 23:18 VZ, revision 78231

Remove unnecessary assert from wxMenuBar::MSWGetMenu(). This assert was triggered after the changes of the previous commit as we can get WM_MENUSELECT with menu bar handle as parameter from Windows and still search for the menu with this handle -- and there is nothing wrong with this, so just return NULL but without asserting in this case. This corrects the changes of r67355, see #13080.

2014-12-05 23:17 VZ, revision 78230

Harmonize wxMenuEvent handling between all major ports. Send these events to the menu itself first, then to the menu bar containing it or the window invoking it if it's a popup menu and, finally, to the top level window in all of wxGTK, wxMSW and wxOSX. In particular, this ensures that help strings are now shown in the parent MDI frame status bar by default, even when the menus are attached to the client MDI frame or shown as popup menus. At the implementation level, this logic is now encapsulated in a new static wxMenu::ProcessMenuEvent() method which can be easily modified and reused in other ports.

2014-12-05 23:17 VZ, revision 78229

Fix fields initialization in wxCommandEvent copy ctor. Neither m_isCommandEvent nor, worse, m_propagationLevel was set correctly for wxCommandEvent objects constructed using copy ctor -- and hence Clone(). This means that such events were not propagated upwards the window hierarchy, quite possibly resulting in mysterious bugs. Fix this now by initializing these fields in both the normal and copy ctors.

2014-12-05 23:17 VZ, revision 78228

Refactor: extract menu event handling logic from wxMenu::SendEvent(). Make this logic available for reuse with the events of different kind, e.g. wxMenuEvent in the upcoming commit.

2014-12-05 23:17 VZ, revision 78227

Remove "isPopup" parameter from DoSendMenuOpenCloseEvent() in wxMSW. This parameter is redundant, we can find out whether a menu is a popup one or not from the menu itself, assuming that we always have a valid wxMenu pointer for popup menus events, which really should be the case (we may not have one for the events from system menus). This allows to handle popup menu events case in the base class version of MSWFindMenuFromHMENU() which will allow to reuse it from places other than DoSendMenuOpenCloseEvent() without code duplication now. There should be no changes to the behaviour, this is just a simplification.

2014-12-05 23:17 VZ, revision 78226

Add a popup menu to the MDI sample. This is just to test how wxEVT_MENU_HIGHLIGHT events from popup menu items are handled under the different platforms. Also log menu events to the canvas window too as it now gets some.

2014-12-05 23:17 VZ, revision 78225

Add logging of wxEVT_MENU_HIGHLIGHT events to the MDI sample too. This allows to easily compare which events are generated and sent to which objects under different platforms.

2014-12-05 23:17 VZ, revision 78224

No real changes, just shorten log messages in the MDI sample. There is not enough space for the relatively long messages logged when menus are opened or closed (added in r78130), shorten them as much as possible while leaving them still readable.

2014-12-05 23:17 VZ, revision 78223

Document the long existing wxFrame::DoGiveHelp(). This function was added way back in 2002 (r15339) but was never documented. Do it now as it's a useful method to override for customizing the help strings display.

2014-12-05 23:17 VZ, revision 78222

Send idle events from inside wxYield() in all ports, including wxMSW. This means it can be now done in wxEventLoopBase itself and calls to ProcessIdle() in the port-specific code are not needed any more, so remove them. This introduces a change in behaviour for wxMSW, where idle event handlers were not invoked from inside wxYield() at all previously, and for wxOSX, where only a single idle event is now generated from wxYield() instead of a stream of them until no idle handler needs any more of them as before. But on the bright side, the new behaviour seems to make most sense and is now the same in all ports.

2014-12-05 23:17 VZ, revision 78221

Use DTM_GETIDEALSIZE to implement wxDateTimePickerCtrl::DoGetBestSize(). If possible, i.e. when running under Vista or later, just ask the control for its best size instead of trying to approximate it ourselves. Notice that we still use our own height, to ensure that it's the same as for the text controls, but it's the width that really counts.

2014-12-05 23:17 VZ, revision 78220

Add wxLocale::GetOSInfo() and use it in MSW wxDateTimePickerCtrl. This fixes the size of wxDateTimePickerCtrl in programs that don't set any specific locale: previously, the standard "%m/%d/%y" format was used for computing the best size of the control in this case, but this could have been significantly shorter than the format actually used (compare with the default "%d %b, %Y"), resulting in the control contents being truncated by default. GetOSInfo() is currently different from GetInfo() only under MSW, but we might need to make the same distinction under OS X too, so do make this function public instead of keeping it MSW-specific.

2014-12-05 23:17 VZ, revision 78219

Remove unneeded CacheBestSize() from wxMSW wxDateTimePickerCtrl. The best size is already cached by the base class GetBestSize(), no need to do it here as well.

2014-12-05 23:15 VZ, revision 78218

Don't keep out of date column widths in generic wxDataViewCtrl. The cached widths need to be invalidated whenever an item is expanded or collapsed, whether it's done programmatically (which was already handled) or interactively by the user (which wasn't). Closes #16678.

2014-12-05 16:56 VS, revision 78217

Xcode project: src/regex must be in non-user search path Otherwise it wouldn't be included as <regex.h> and the system copy would be used. We need to always use the builtin, wxChar-aware copy.

2014-12-05 16:55 VS, revision 78216

Xcode project: src/regex must be in non-user search path Otherwise it wouldn't be included as <regex.h> and the system copy would be used. We need to always use the builtin, wxChar-aware copy.

2014-12-03 18:18 VZ, revision 78215

No real changes, just fix some typos in comments. Closes #16699.

2014-12-03 18:01 AW, revision 78214

Define wxPG toolbar event handler only if library is compiled with toolbar classes. Include wxPropertyGridManager::OnToolbarClick() code only if wxUSE_TOOLBAR is set to 1.

Select page:

[] [1 4 7 10 11 12 13 14 949 1883 2818] []

Imprint