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
- Add classes: wxTaskBarButton and wxTaskBarButtonImpl.
- New interface in wxTopLevelWindowMSW to get its wxTaskBarButton:
MSWGetTaskBarButton.
- A simple sample and build files under msvc.
Author: Chaobin Zhang
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77591 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
- Add classes: wxTaskBarButton and wxTaskBarButtonImpl.
- New interface in wxTopLevelWindowMSW to get its wxTaskBarButton:
MSWGetTaskBarButton.
- A simple sample and build files under msvc.
Author: Chaobin Zhang
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77572 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Both "caption" and "style" arguments were documented as having default values,
but didn't really have them. Fix this by actually adding them.
Closes#16524.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77540 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This assignment operator is not portable and a better alternative is available
now with the addition of the wxBitmap ctor from wxCursor in the previous
commit.
See #15699.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77538 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
__MINGW64_VERSION_MAJOR is defined only in _mingw.h, so it was never defined
in wx/compiler.h, included before any other headers and we can't include
_mingw.h for the same reason we must define wxCHECK_MINGW32_VERSION() in
wx/msw/gccpriv.h: this has to be done after defining UNICODE/_UNICODE, but
wx/compiler.h is included before this.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77532 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This doesn't make much sense for an interface declaration anyhow and produces
a warning from g++ about assigning string literal to (non-const) BSTR pointer.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77076 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This ended up being broken due to an interplay between different unrelated
changes (at least r15120 and r41134) which were both correct, but didn't work
well together and resulted in not only preventing IsDialogMessage() from
handling ESC, but also our own accelerator tables.
Fix this by doing the check for IsDialogMessage() brokenness in
MSWProcessMessage() itself, just before calling it, instead of doing it in
MSWShouldPreProcessMessage() which is (and must be) called before
MSWTranslateMessage() which checks for accelerators using ESC.
Closes#3813.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77071 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The native control doesn't redraw itself, so force it to do it from the
overridden DoMSWControlColor() which is called every time the background
colour might have changed.
See #12271.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76985 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
Don't call SetBitmap from GetHBitmapForMenu but instead handle possibly
needed bitmap modifications earlier on during SetBitmap. Allows for
GetHBitmapForMenu to be const and gets rid of the clumsy re-entry check
introduced in r76754.
Also check the bitmap for alpha presence instead of needlessly converting
the bitmap to an image and checking the latter for alpha.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76781 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Merge wxMenuItem::GetHBitmapForMenuCheckable and ::DoGetHBitmapForMenu
into wxMenuItem::GetHBitmapForMenu. Change its boolean parameter to an
enum specifying the kind of bitmap that is wanted (normal, checked, or
unchecked).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76760 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Since r76202 InsertMenuItem is used when adding checkable menu items even
without a bitmap. The call fails because hbmpChecked and hbmpUnchecked are
set to HBMMENU_CALLBACK on pre-Vista, making the menu owner drawn
unnecessarily.
Fix by adding GetHBitmapForMenuCheckable which is used when assigning
values to hbmpChecked and hbmpUnchecked. GetHBitmapForMenu remains
unchanged (for possible porting reasons) and is used for hBmpItem only.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76757 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
In wxMSW, use IRichEditOleCallback::GetContextMenu() to provide our
default context menu for rich text controls, instead of using
EVT_CONTEXT_MENU.
The latter completely overrides native control's handling and in
particular breaks Windows 8's builtin spellchecking support.
Fall back to the previous non-OLE code for older richtext versions.
Also make the new MSWCreateContextMenu() method virtual so that the
context menu can be customized.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76723 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
wxASSERT_MSG( m_menuDepth > 0, wxS("No open menus?") );
The conditions to reproduce:
- Windows 8.1
- An application manifest that indicates Windows 8.1 compatibility
In this case, wxGetWinVersion() used to return wxWinVersion_Unknown (Without a manifest indicating 8.1 support, wxWinVersion_8 is being returned). This in turn causes the version check against Windows98 in toplevel.cpp:450 to fail, ultimately leading to the mentioned assert.
See http://msdn.microsoft.com/en-us/library/windows/desktop/ms724439%28v=vs.85%29.aspx for details.
This patch on trunk adjusts adds the wxWinVersion_8_1 enum value and returns it on Windows 8.1 if the program is manifested as such.
In future, a different approach needs to be chosen that does not depend the deprecated GetVersion function.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76714 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use position, not the ID, to find the native menu items to allow the code in
wxMenuItem::SetItemLabel() and DoSetBitmap() to also work with submenus and
not just the normal items.
Closes#16246.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76676 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't offset the returned values by the parent window origin unnecessarily: as
popup windows are created as children of the desktop window in wxMSW, their
coordinates are already expressed in screen coordinate system (which is
exactly the same as display window coordinate system) and we must not try to
translate them to it once again, this is completely wrong and was probably a
left over from earlier wxPopupWindow implementation in which it wasn't created
as a child of desktop.
Closes#4440.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76675 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This must be done both at wxWidgets and MSW level, otherwise changing the ID
results in window not recognizing itself as the recipient of the messages sent
to it by Windows.
Closes#3697.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76672 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This fixes g++ compilation problem in 64 bit mode after the changes of r76653,
it complained about comparing pointer (HANDLE) with an integer. It might also
fix compilation with icc.
See #16233.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76658 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't leave the tooltip shown on screen if the window it was shown for was
hidden or iconized (without moving the mouse, as that would have dismissed the
tooltip as well).
Closes#16265.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76657 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make AutoHANDLE a template to allow specifying the invalid handle value, which
is inconsistent across Win32 API and is INVALID_HANDLE_VALUE for most kinds of
handles but 0 for some others, e.g. event object handles.
See #16233.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76653 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
