Don't leave currentContext set to the temporary context indefinitely,
but restore the previous one when done. It's apparent from the code that
this is how it was meant to be done.
Not doing this can result in strange, insanely hard to debug errors in
completely unrelated places, because OS X (at least < 10.9) reuses a
pool of contexts. For example, this change fixes Quicklook crashes in
file open panel on 10.8.
For detailed explanation, see the lengthy discussion at
https://code.google.com/p/chromium/issues/detail?id=90140
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75708 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Document that this function adjusts the window font size under non-OS X
systems and explain why it should still be used instead of changing the font
size directly.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75632 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Do prevent the app from exiting when the help frame is shown in the special
case of the help viewer application where the default behaviour of exiting the
application when only the help window remains open is inappropriate and
results in unexpected program exit if we open and then close any dialog, e.g.
from the help frame toolbar.
Even though the previous commit actually already fixed the problem in the
current code, still apply this fix as well, just in case we can (or could, in
the future) should any dialogs with NULL parent in this program.
Closes#15880.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75631 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This counterintuitive behaviour could happen when a dialog of a frame
returning false from its ShouldPreventAppExit() was closed: if there were no
other TLWs in the application, then the parent frame could be closed as well,
even if this clearly shouldn't happen.
See #15880.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75630 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The screen to client conversion for this event coordinates took the toolbar
height into account twice, resulting in a wrong value if the event was handled
in a frame that did have a toolbar.
Closes#15812.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75559 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The number of columns in the table is now (since r60717) stored in m_numCols,
so there is no need to get it from wxGrid any more. This is not only simpler
and faster but also more correct as the first row might not have the full
number of values yet.
Closes#15809.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75551 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
SetSize() doesn't do anything for MDI children in wxGTK and other ports using
TDI version of MDI, but it shouldn't result in an assert from
wxTLW::DoMoveWindow() neither, so override DoMoveWindow() in wxTDIChildFrame
to avoid it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75523 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Drawing on a wxBitmap via wxMemoryDC modified its pixmap representation in
wxGTK and even if its pixbuf representation was later changed using direct
access to the bitmap pixels, the out of date pixmap continued to be used,
creating the illusion of direct access being completely ignored.
Fix this by purging the old pixmap representation when locking the bitmap for
raw access.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75518 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The code could crash if m_overflowVisible was true but m_overflowSizerItem was
NULL. Ideally this shouldn't happen in the first place, but it did, so at
least fix the crash for now -- and hopefully this code will be refactored to
make it more clear later.
Backport from trunk, see #15747.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75399 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Previously, when reading files with completely nonstandard - but
occurring in the wild thanks to broken Notepad - files with CRCRLF, all
content would be replaced with empty lines.
Fix the code to do what many editors do with such files: treat this as
data line followed by an empty one. This is not ideal, but it is better
than discarding data - and arguably, silently cleaning up the endings
wouldn't be great either (and would add extra complications for what is
an obscure and broken case).
See http://stackoverflow.com/questions/6998506/text-file-with-0d-0d-0a-line-breaks
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75388 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
