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

2014-12-11 19:34 PC, revision 78263

avoid generating wxEVT_CHAR when WriteText() is called from wxEVT_CHAR handler, closes #16717

2014-12-10 02:04 VZ, revision 78262

Restore Kolya Kosenko copyrights on parts of wxQt code. The original code was originally submitted of #12042. Closes #16721.

2014-12-10 01:14 VZ, revision 78261

Cast size_t value when using it with printf() in a test. Use %lu with a cast to avoid warnings in both 32 and 64 bit builds. Closes #16720.

2014-12-09 18:11 AW, revision 78260

Refactor: mark wxPropertyGridManager::SetId() as overridden virtual method.

2014-12-09 18:07 AW, revision 78259

Reconnect wxPropertyGridManager event handlers when wxPG id is changing. Because some event handlers are bound to the particular id's they need to be reconnected when wxPG id is the subject of change.

2014-12-09 13:51 VZ, revision 78258

Update wxGetTranslation() documentation. Document "i18n" trace mask. Correct warning about [not] using wxT(). See #16714.

2014-12-09 13:51 VZ, revision 78257

Update i18n overview in the manual. Remove obsolete warning about gettext 0.10, add a link to Poedit instead. Also fix Doxygen markup: @see can't be used inside a list item. See #16714.

2014-12-07 17:40 VS, revision 78256

Don't crash on OS X on exit if -NS* argument used When converting argv[] from char* to wchar_t* in ConvertArgsToUnicode(), keep an extra (shallow) copy of argc and the argv[] array so that it can be safely freed in FreeConvertedArgs(). The reason is that other functions such as wxApp::Initialize() may modify argv[] and remove some arguments from it; this is indeed exactly what wxOSX does. After such changes, gs_initData.argv would no longer be in the original state and could contain e.g. duplicate pointers or be missing some of the pointers that we should free.

2014-12-07 17:40 VS, revision 78255

Use int& type for argc in wxInitialize and wxInitializer Other functions that take (argc,argv) arguments (wxEntry, wxEntryStart) take argc by reference, because they may manipulate the arguments list. wxInitialize() used passing by value, so any modifications would be silently lost. Make all the functions consistent in their handling of argc by using int& everywhere.

2014-12-07 17:40 VS, revision 78254

Don't crash on OS X on exit if -NS* argument used When converting argv[] from char* to wchar_t* in ConvertArgsToUnicode(), keep an extra (shallow) copy of argc and the argv[] array so that it can be safely freed in FreeConvertedArgs(). The reason is that other functions such as wxApp::Initialize() may modify argv[] and remove some arguments from it; this is indeed exactly what wxOSX does. After such changes, gs_initData.argv would no longer be in the original state and could contain e.g. duplicate pointers or be missing some of the pointers that we should free.

2014-12-07 14:47 VZ, revision 78253
  • D /wxWidgets/trunk/src/expat/.cvsignore
  • D /wxWidgets/trunk/src/expat/conftools/.cvsignore
  • D /wxWidgets/trunk/src/expat/examples/.cvsignore
  • D /wxWidgets/trunk/src/expat/gennmtab/.cvsignore
  • D /wxWidgets/trunk/src/expat/lib/.cvsignore
  • D /wxWidgets/trunk/src/expat/tests/.cvsignore
  • D /wxWidgets/trunk/src/expat/win32/.cvsignore
  • D /wxWidgets/trunk/src/expat/xmlwf/.cvsignore

Remove .cvsignore files from expat sources. These files shouldn't be included in the distribution and it's simpler to just remove them, as it is pretty unlikely that a new Expat release is going to be made, and even less likely that it would still use CVS if it does happen, than to filter them out from the distribution creation scripts. Closes #16711.

2014-12-07 14:46 VZ, revision 78252
  • D /wxWidgets/branches/WX_3_0_BRANCH/src/expat/.cvsignore
  • D /wxWidgets/branches/WX_3_0_BRANCH/src/expat/conftools/.cvsignore
  • D /wxWidgets/branches/WX_3_0_BRANCH/src/expat/examples/.cvsignore
  • D /wxWidgets/branches/WX_3_0_BRANCH/src/expat/gennmtab/.cvsignore
  • D /wxWidgets/branches/WX_3_0_BRANCH/src/expat/lib/.cvsignore
  • D /wxWidgets/branches/WX_3_0_BRANCH/src/expat/tests/.cvsignore
  • D /wxWidgets/branches/WX_3_0_BRANCH/src/expat/win32/.cvsignore
  • D /wxWidgets/branches/WX_3_0_BRANCH/src/expat/xmlwf/.cvsignore

Remove .cvsignore files from expat sources. These files shouldn't be included in the distribution and it's simpler to just remove them, as it is pretty unlikely that a new Expat release is going to be made, and even less likely that it would still use CVS if it does happen, than to filter them out from the distribution creation scripts. Closes #16711.

2014-12-07 02:52 VZ, revision 78251

Fix appearance of wxMSW wxToggleButtons with bitmaps in pressed state. Correct the "pushed" state determination in our own drawn code, it didn't work for wxToggleButton which doesn't return BST_PUSHED from BM_GETSTATE. But it does have BM_GETCHECK returning its state directly, so add a new virtual MSWIsPushed() method and implement it differently for it. Closes #13755.

2014-12-06 14:07 VZ, revision 78250

Move MSWGetDefaultLayout() outside of #if wxUSE_EXCEPTIONS block. Build fix for wxUSE_EXCEPTIONS==0 after r78236.

2014-12-06 00:09 VZ, revision 78249

Build fix for wxOSX after the changes of r78230. Fix wrong signature of DoHandleMenuEvent() by getting rid of this function entirely, it's not just a trivial wrapper for ProcessMenuEvent() anyhow, so just use the latter directly.

2014-12-05 23:19 VZ, revision 78248

Fix checked disabled wxToolBar tools with custom images in wxMSW. Windows doesn't use the correct image for checked disabled tools, at least up to and including Windows 7, so don't put such tools in the "checked" state at all: this doesn't matter as they are disabled anyhow, but shows the correct image for them. Closes #12989.

2014-12-05 23:19 VZ, revision 78247

Don't generate wxEVT_MENU_{OPEN,CLOSE} for disabled top menus in wxMSW. Windows still sends these messages even if a top level menu is disabled, for some reason, so filter them out manually. Closes #2168.

2014-12-05 23:19 VZ, revision 78246

No real changes, just make wxMenuBar::MSWGetMenu() const. There is no reason not to.

2014-12-05 23:19 VZ, revision 78245

Handle updating tooltip text in wxCompositeWindow correctly. While calling SetToolTip(wxToolTip*) overload already worked correctly for wxCompositeWindow, using SetToolTip(wxString) did not if a tooltip already existed, as it didn't use the virtual DoSetToolTip() in this case, resulting in e.g. impossibility to update wxSpinCtrlDouble tooltip using this method. Fix this by introducing DoSetToolTipText() virtual which is used by that overload now and overriding it in wxCompositeWindow. Also don't override DoSetToolTip() in wxSpinCtrlGenericBase any more, it is not necessary as it's already done by its base class wxCompositeWindow. Closes #16595.

2014-12-05 23:19 VZ, revision 78244

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 23:18 VZ, revision 78243

Use another bool constant instead of BOOL one in wxBitmapComboBox. Just s/FALSE/false/ See #16690.

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

Measure wxBitmapComboBox height correctly if it has images. This fixes a regression introduced in r77548 (see #14279): wxBitmapComboBox must be higher than a normal wxComboBox if it has big enough bitmaps. Closes #16690.

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

Prefer file types with a defined open command in Unix wxMimeTypesManager. It can happen that more than one file type maps to the given extension, in this case prefer the one which has an open command defined for it as it is typically more useful. See #16703.

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

Load *.desktop files recursively in wxMimeTypesManager under Unix. Not all .desktop files are directly under /usr/share/applications, some or, in some cases, most of them, may be under its subdirectories, so look for them there as well. See #16703.

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

No changes, just fixes for typos in comments in wxMSW headers. Closes #16706.

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.