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-04-26 18:23 VZ, revision 64147

Remove a harmless unused parameter warning in wxOSX/Carbon.

2010-04-26 16:19 VZ, revision 64146

Fix wxGTK1 event loop definition mismatch between base/GUI. We must define wxEventLoopBase in the same way in base and GUI code, otherwise, even though we fool the compiler into accepting our code, it crashes or behaves otherwise weirdly during run-time because of vtbl mismatch. This fixes wxGTK1 which was crashing on startup since the FSWATCHER branch merge in r62474 and associated changes to support the event loop sources.

2010-04-26 16:19 VZ, revision 64145

Use wxMenuBar::Attach/Detach() instead of SetInvokingWindow() in wxGTK1. This is the same as r64127 for wxGTK.

2010-04-26 16:19 VZ, revision 64144

Fix wxGTK1 link after toolbar files renaming. Fix a typo in r62849: tooltip.cpp was used instead of toolbar.cpp resulting in linking errors for the duplicate symbols in the former and undefined symbols in the latter.

2010-04-26 16:19 VZ, revision 64143

Set popup menu invoking window in wxWindowBase and not in all ports. Don't duplicate the code for setting (and unsetting, which was forgotten by at least wxGTK) the popup menu invoking window in all ports but do it in the base class PopupMenu() itself. Also add a helper wxMenuInvokingWindowSetter class which ensures that the invoking window will be unset in any case.

2010-04-26 16:19 VZ, revision 64142

Don't set invoking window recursively in wxGTK wxWindow::PopupMenu(). Setting the invoking window for all submenus is unnecessary as wxMenu::GetWindow() recurses upwards anyhow and results in assert failures after recent menu code changes. Simply don't do this. OTOH do reset the invoking window to NULL after the menu is dismissed to avoid storing a dangling pointer in the menu.

2010-04-25 23:33 FM, revision 64140

no real change: just fix RCS-ID so that it reflects the current revision number

2010-04-25 14:07 VS, revision 64139

Don't include wx/msw/private.h from dynlib.h. Because it's private header and introduces dependency on window.h.

2010-04-25 14:07 VS, revision 64138

Declare various WXH* handles compatibly with SDK. It is no longer necessary to cast between e.g. HINSTANCE and WXHINSTANCE, they are now declared as the same type (without including Windows SDK header).

2010-04-24 22:39 VZ, revision 64136

Remove unnecessary duplicate code dealing with invoking window from wxOSX. This is roughly the same as r64127 for wxGTK but for wxOSX: don't duplicate the functionality already present in the base class in Mac-specific way. Just use wxMenu::GetWindow() instead of painstakingly propagating invoking window changes via the entire menu hierarchy. Also attach the root menu used in wxOSX to the menu bar to ensure that the correct window can be found for all its menus. Closes #11990.

2010-04-24 22:39 VZ, revision 64135

Recurse upwards the menu hierarchy in wxMenu::GetWindow(). Only the top level menus have non-NULL wxMenuBar pointer too, so recurse upwards the menu hierarchy in GetWindow() and not (just) GetInvokingWindow(). This fixes event processing for submenus broken by the recent changes.

2010-04-24 19:52 VZ, revision 64134

Disable ImageTestCase::LoadFromFile() on build slaves. This test case keeps failing erratically resulting in too many bogus build breakage notifications. Disable it until someone has time to fix it properly.

2010-04-24 19:20 PMO, revision 64133

Update to trunk r64122 to get fix for wxMenu::SendEvent()

2010-04-24 19:08 PMO, revision 64132

Handle Qt signals for menu items

2010-04-24 19:06 PMO, revision 64131

wxQtAction implementation

2010-04-24 18:59 VZ, revision 64130

A slightly better compilation fix after PCH-less build breakage in r64126. Include wx/frame.h header instead of casting wxFrame to wxWindow using C style cast. Although this does work now and probably will work later too it seems better to not use the cast nevertheless.

2010-04-24 18:10 VS, revision 64129

Added missing @since tags to wxTranslationsLoader classes.

2010-04-24 16:40 PC, revision 64128

non-pch build fix

2010-04-24 17:08 VZ, revision 64127

Don't use invoking window in wxGTK wxMenuBar implementation. wxGTK wxMenuBar used its own SetInvokingWindow/UnsetInvokingWindow() and related functions instead of reusing the base class Attach/Detach() which exist for exactly the same purpose. This resulted in unnecessary code duplication and confusion and, since the changes of r64104, resulted in asserts due to use of SetInvokingWindow() for non-popup menus. Fix this by removing the wxGTK-specific functions and doing the work they used to do in (now overridden) Attach() and Detach(). Also call Attach/Detach() instead of these functions from wxGTK wxFrame and wxMDIParentFrame code.

2010-04-24 17:07 VZ, revision 64126

Use wxMenu::GetWindow() instead of GetInvokingWindow() in SendEvent(). This simplifies the code as we don't need to walk the menu hierarchy upwards any more (GetInvokingWindow() does it now) and also makes it work for all menus, not just the popup ones.

2010-04-24 17:07 VZ, revision 64125

Avoid code duplication in wxGTK menu events generation code. Reuse the existing DoCommonMenuCallbackCode() function instead of duplicating its code in menuitem_select() and menuitem_deselect() GTK callbacks. No changes in behaviour.

2010-04-24 17:07 VZ, revision 64124

No real changes, just remove empty wxMenuBar dtor in wxGTK.

2010-04-24 17:07 VZ, revision 64123

Move wxMSW wxMenu::GetWindow() down to wxMenuBase. GetInvokingWindow() can only be used for the popup menus which have the invoking window, so add a new function which can be used to get the window associated with any kind of menu in all ports -- it already existed in wxMSW but is needed elsewhere too.

2010-04-24 13:09 PMO, revision 64122

Update to trunk r64121

2010-04-24 12:13 JMS, revision 64121

Allow wxPGProperty::Hide() to be called on unattached property (see #11987)