Václav Slavík [Thu, 29 Apr 2010 08:31:42 +0000 (08:31 +0000)]
Always use active wxTranslations instance via wxLocale.
Don't use m_translations directly, if the user made changes to
wxTranslations instance, it would be too confusing if calls through
wxLocale compat API did nothing.
Also don't change active wxTranslations object from wxLocale if already
done by user, only call wxTranslations::Set() from wxLocale constructor
if it wasn't already set by the user. Still do if wxTranslations
instance currently in use was set by previous wxLocale on the locale
stack.
Václav Slavík [Mon, 26 Apr 2010 20:51:16 +0000 (20:51 +0000)]
Shorten lang names in wxTranslations, not wxFileTranslationsLoader.
If a catalog with full language name ("fr_BE") doesn't exist,
wxFileTranslationsLoader tries to look for just the base language ("fr")
too. This isn't something specific to wxFileTranslationsLoader, it makes
sense to do it regardless of the loader.
Add wxLoadUserResource() overload not copying the resource data.
The existing wxLoadUserResource() copies the resource data which is often
unnecessary. Add another overload which just returns the pointer directly to
the resource data.
Also move the function into base from core as it can be useful for the console
applications as well.
Finally, define wxUserResourceStr used by this function only in the same file
where the function itself is defined instead of datacmn.cpp.
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.
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.
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.
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.
Václav Slavík [Sun, 25 Apr 2010 12:07:30 +0000 (12:07 +0000)]
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).
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.
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.
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.
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.
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.
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.
Jaakko Salli [Sat, 24 Apr 2010 10:02:25 +0000 (10:02 +0000)]
In wxPropertyGrid::DoPropertyChanged(), call GetEditorControl() as late as possible so that editor can be changed in wxPGProperty::OnSetValue() (fixes #11987)
Václav Slavík [Sat, 24 Apr 2010 07:06:32 +0000 (07:06 +0000)]
Split intl.h into intl.h, language.h and translation.h.
To make the code more manageable, intl.h now contains wxLocale and
translation.h all translations-related stuff (wxTranslations, _() etc.).
Code generated by genlang.py was moved into its own files (language.h,
languageinfo.cpp).
Václav Slavík [Sat, 24 Apr 2010 07:06:18 +0000 (07:06 +0000)]
Split wxLocale into wxLocale and wxTranslations.
wxTranslations is for handling gettext translations. wxLocale manages
locale and provides compatiblity API for translations. Separating these
two loosely related tasks makes it possible to use translations into
languages not known by Windows or using localized GUI without all the
locales compilations.
Work around wrong client size computation for not yet shown maximized windows.
The client size of maximized windows which hadn't been shown yet isn't
computed correctly by wxMSW because WM_NCCALCSIZE returns too small values for
some reason. Attempts to fix this were unsuccessful so just ensure that the
window is re-laid out using the right size from WM_SIZE it receives when it is
shown instead of using the wrong pending size.
Don't test possibly uninitialized variable in wxGCDC::SetLogicalFunction().
The variable "mode" is not filled by TranslateRasterOp() function if the input
function is not supported, so don't compare it with wxCOMPOSITION_XOR later.
Just compare "function" itself with wxXOR as this works in any case.
Jaakko Salli [Thu, 22 Apr 2010 13:51:38 +0000 (13:51 +0000)]
Allow wxAny to contain 'const char*' or 'const wchar_t*'. This was previously not possible since these pointers were converted to wxString, as convenient means to work with string literals. Now pointers (to string literals) are stored instead, and As<wxString>(), comparison operators do the type conversion.
We incremented the index once more even after finding the line we were looking
for in the array which meant that we accessed a wrong array element in any
case and could even attempt to access an out of bound one if the file was
found in the last line.
Use symbolic names for popup menu ids in wxEVT_MENU_HIGHLIGHT events in wxMSW.
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.
Fix bug with using incorrect negative ids in wxEVT_MENU_HIGHLIGHT events.
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.
Override wxWindow::MSWGetCreateWindowCoords() in wxTopLevelWindow.
The old code was messy because it handled both top level and child windows at
wxWindow level when they need quite different treatment. This resulted in
several errors: first, wxWindow versions of WidthDefault and HeightDefault
were used to determine the initial size even of top level windows which was
clearly wrong as it created tiny windows (20*20). Second, CW_USEDEFAULT could
be used for child window for which this shouldn't be done.
Fix this by making MSWGetCreateWindowCoords() virtual and overriding it in
wxTopLevelWindow. This makes the code much simpler and more obviously correct.
Also make MSWGetCreateWindowCoords() void, as nobody was using its return
value anyhow (and the old version also had a bug in it and wrongly returned
true when default size was passed to it).
Remove the extra margins when checking owner drawn menu icons size.
The extra +4 in IsLessThanStdSize() functions resulted in assert failures
under Windows XP after the ownerdraw drawing changes so remove it as nobody
knew why was it there anyhow.
Also replace IsLessThanStdSize() with IsGreaterThanStdSize() to allow using it
directly instead of always testing for !IsLessThanStdSize().
Although the information about "Cancel" and "Skip" buttons presses is returned
from Update(), sometimes it may be more convenient to ask the dialog about
whether it was cancelled or skipped instead of storing it in the program
itself.
Jaakko Salli [Mon, 19 Apr 2010 14:25:41 +0000 (14:25 +0000)]
When deciding whether to convert wxAny to 'long' or 'longlong' wxVariant, use wxINT32_MAX instead of LONG_MAX (for more consistent results across builds)
Use "monospace" face name for all Unix systems, hopefully it should work.
This fixes failures of several build bot slaves (all running Debian or
Ubuntu) which were due to using "Fixed" under these Linux distributions.
Unfortunately "Fixed" didn't work as Pango doesn't seem to recognize it as a
valid face name. "DejaVu Sans" should probably work on most current Linux
systems but "Monospace" should hopefully be available on other Unix systems as
well.
We could also just take whatever wxFontEnumerator returns which should
probably be even more fool-proof.