The flicker was only visible under Windows XP or when using a class theme
and was due to mis-positioning the status bar initially in PositionStatusBar().
Fix this by adjusting its position by the toolbar offset before calling its
SetSize().
Closes#16705.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78325 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78227 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Store the various parameters in wxTaskBarButton itself and reapply them when
the button is (re)created. This fixes problems with getting the "taskbar
button created" message twice, e.g. because Explorer was restarted, or getting
it too late, as now wxTaskBarButton can be configured both before and after
receiving this message.
Closes#16566.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78036 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
It is possible to receive more than one TaskbarButtonCreated message for the
same window, so at the very least don't leak memory if this happens.
We really ought to notify the application to allow it to reinitialize the
taskbar button in this case though.
See #16566.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77907 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This allows to encapsulate checking for errors, which should be handled when
using this class as task bar buttons API is not available under Windows XP.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77705 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The check for top level menus being disabled added in r77657 is broken as it's
used, with the expectedly bad consequences, for non top level menus as well,
as can be seen by opening any submenu, so revert it.
See #2168.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77704 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxFrame::m_taskBarButton needs to be initialized in its Init(), not Create(),
which is not necessarily used by the derived classes such as wxMDIParentFrame,
resulting in a guaranteed crash when deleting an uninitialized pointer later
in wxFrame dtor.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77688 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxDynamicLibrary::RawGetSymbol() (from inside wxDL_INIT_FUNC() macro)
instead of GetSymbol() to avoid the error message which was given every time a
new wxFrame was created after wxTaskBarButton changes under XP as
ChangeWindowMessageFilter() function is not available in it.
Also simplify the code a little and don't make pfnChangeWindowMessageFilter
static, we don't need to keep it around.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77681 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Check if a top level menu is disabled and consume WM_[UN]INITMENUPOPUP that
Windows still generates for it when it's clicked for some reason.
Closes#2168.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77657 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
- New API: InsertThumbBarButton, AppendThumbBarButton, RemoveThumbBarButton.
- Though MSDN said that "Buttons cannot be added or deleted later, so this must
be the full defined set. Buttons also cannot be reordered.", we can work
around it by: when first time adding button, initialize all of the possible
seven buttons and hide them, except the button adding. In the next time adding
button, just show it, which can make it looks like it is added on the fly.
Author: Chaobin Zhang
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Since there are two sub-classes of wxTopLevelWindowMSW: one is wxFrame, the
other is wxDialog. However, wxDialog have no button shown in taskbar on
windows, so the taskbar button feature should be only avaiable in wxFrame.
Author: Chaobin Zhang
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77595 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
- New API: InsertThumbBarButton, AppendThumbBarButton, RemoveThumbBarButton.
- Though MSDN said that "Buttons cannot be added or deleted later, so this must
be the full defined set. Buttons also cannot be reordered.", we can work
around it by: when first time adding button, initialize all of the possible
seven buttons and hide them, except the button adding. In the next time adding
button, just show it, which can make it looks like it is added on the fly.
Author: Chaobin Zhang
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77583 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Since there are two sub-classes of wxTopLevelWindowMSW: one is wxFrame, the
other is wxDialog. However, wxDialog have no button shown in taskbar on
windows, so the taskbar button feature should be only avaiable in wxFrame.
Author: Chaobin Zhang
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77576 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxGTK1, wxGTK, wxMSW and wxOSX all did the same thing in their wxFrame dtor,
so just do it in wxFrameBase instead.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76804 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Contrary to MSDN implications, at least some of these messages are not
actually sent to the TLW for popup menus, but to the owning window or
even its parent window (!).
Move the handling of these events from wxTLW to wxWindow. Move menu
depth tracking to wxFrame, because it only makes sense for frame's
menus and move DoGiveHelp() from wxTLW to wxFrame.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76721 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Creating the status bar before the menu bar but associating it with the frame
after creating the menu bar resulted in a status bar of completely wrong height.
Fix this by enforcing the default height on the status bar when it's attached
to the frame.
Closes#10956.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76417 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The previous workaround of defining it explicitly if it's not defined was left
in src/msw/frame.cpp while the code using WM_UNINITMENUPOPUP was moved to
src/msw/toplevel.cpp in r73562. Move the fallback definition there too.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73682 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This allows to generate the menu open/close/highlight events correctly for the
popup menus used in the dialogs.
Extend the menu sample with a test using such menus.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73562 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make wxMSW consistent with the other ports and set the menu itself, not the
window it is attached to, as the event object for the menu open/close events.
See #1595.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@71115 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Get rid of two identical implementations in wxFrame and wxDialog and only
override this function once in wxTopLevelWindow.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70511 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
WM_UNINITMENUPOPUP is "only" available since Windows 98/2000 so restore the
old code using WM_EXITMENULOOP as fall back, just to avoid any regressions for
people who might still be using these systems.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70156 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Set the wxMenu correctly for wxEVT_MENU_CLOSE events in wxMSW.
Set the menu id correctly to allow wxMenuEvent::IsPopup() to work for both
wxEVT_MENU_OPEN and wxEVT_MENU_CLOSE in wxOSX.
Closes#11313.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70151 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Additionally renamed wxOSX' private wxNativePrinterDC::Ok() function to IsOk().
Didn't deprecate the various Ok() functions: given the amount of changes already introduced in 3.0 a trivial one like this seems more suitable for after 3.0.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67681 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We didn't find the menus corresponding to the submenu handles. This resulted
in incorrect processing of EVT_UPDATE_UI events for the submenus and probably
other problems.
Fix this by searching for the HMENU recursively in all menus.
Closes#13080.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67355 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We need to account for the full size of status bar, including potential
borders, when calculating the client size of the frame containing it.
Closes#12697.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66225 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
No real changes, just use wxID_NONE instead of hardcoded -1 (in one place) and
-3 (in another one). Hardcoding them not only made the code less readable but
also resulted in two numbers actually becoming different when they almost
certainly were meant to be the same.
This shouldn't result in any changes in the user-visible behaviour but we now
avoid searching the menu bar for menu items with id of -1 needlessly.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64103 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxMSW code implicitly cast ids carried by wxEVT_MENU_HIGHLIGHT events to
unsigned short so that they didn't compare equal to the (signed, negative) ids
of the real menu items. Because of this menu help strings were not shown for
any items with negative ids, i.e. those created using wxID_ANY.
Closes#11977.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64102 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The hack introduced in r22410 artificially set wrong size for toolbar under
MSW. This completely breaks any calculations that can be done using it (e.g.
to find the space available for the stretchable part of the toolbar) and is
completely and utterly unexpected.
Revert it, toolbar flicker must be dealt in another way if it is still a
problem.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62848 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
