These comments are suggestions for the correct translations and are not
needed any longer after the translations had been updated to take them
into account.
This doesn't make any sense and can prevent wxLogFrame menu items such
as "Save" from working if the parent frame defines an wxEVT_UPDATE_UI
handler for wxID_SAVE disabling it.
Closes#22486.
The default art provider has many icons of 16x15 size, suitable for use
in the standard-sized MSW toolbars (which nobody uses any more, but this
is not the point), so handle them specially and not only resize them to
16x16, which was already done as part of the normal logic here (in the
past this used to be handled specially too, but bd0db4a5f9 (Still resize
(16, 15) bitmaps to (16, 16) ones in wxArtProvider, 2022-02-05) changed
this), but also upscale them to 32x32 and other multiple-of-16 sizes by
resizing them to 16x16 first and then upscaling.
This makes the appearance of 16x15 and 16x16 icons consistent with each
other when showing them in bigger sizes in the resource browser dialog
of the artprov sample, which seems to be the right thing to do.
This commit is best viewed with Git --color-moved
--color-moved-ws=ignore-all-space options.
The changes of 6feeed9fe9 (Handle transparency to the best of our
ability in wxImageList, 2022-05-05) didn't handle the icons with mask
(and without alpha) correctly, as the native image list doesn't handle
the icon masks without ILC_MASK, so the masks were just ignored.
Fix this by handling icons as bitmaps: for them everything already works
and even it means extra unneeded conversions, it's much simpler than the
alternative of reimplementing GetImageListBitmaps() logic for the icons.
See #22349.
The changes of 4f9186f1a1 (Increase usable scrolling range in wxMSW by a
factor of 10,000, 2022-04-30) broke using wxGraphicsContext, and wxGCDC,
with scrolled wxDC, as GDI+ wasn't aware about the origin shift in it
any more, now that it's not done at MSW level any longer.
Fix this by shifting the origin before constructing the Graphics object
from HDC to restore the old behaviour.
Note that this means that the origin shift is still limited to 2^27
(instead of the full int range) when using wxGCDC, which is not ideal,
but better than breaking it completely (and when using wxGraphicsContext
directly, world transformation can, and should, be used to avoid this
limit).
Closes#22480.
Remove __WXGTK__ checks and highlight it everywhere, this can be useful
under other platforms too depending on the colour schema and not having
platform-specific checks is better than having them if they're not
absolutely required.
If we really want to avoid highlighting in some cases, we should check
for the contrast between the border and background colours, but it seems
to be much simpler to just always show it.
No real changes, but calling wxRect::Deflate() once here with the value
depending on whether wxBORDER_NONE is used seems more clear in this
particular context.
The existing code only worked correctly if overridden
wxArtProvider::CreateBitmap() returned bitmaps with scale factor of 1,
but not for anything else.
Account for the bitmap scale factor when determining the default size
and available scales correctly to fix this.
Co-authored-by: Václav Slavík <vaclav@slavik.io>
Radio buttons are different from the other controls internally in
IFileDialogCustomize-based implementation, so check that disabling them
also works correctly.
Using a section looks better and prepares for adding another one in the
upcoming commit.
Also remove a note about Motif file dialog limitation, nobody cares
about it any more anyhow.
Add unnecessary virtual dtor to this class just to avoid
-Wdelete-non-virtual-dtor from gcc (which is wrong here as this class is
never used polymorphically, i.e. never deleted via a pointer to its base
class).
Update the extra controls whenever anything changes in the dialog to
make the example in the dialogs sample actually work with the generic
dialog (previously nothing was updated at all).
Also delete the extra controls earlier to make the behaviour more
consistent with the native dialogs.
Use the new customization API for the generic dialogs in the sample too.
Forward the events from the actual wxControls used in the generic
implementation of wxFileDialogCustomize to wxFileDialogCustomControl so
that they could be handled by the application code binding to them.
Keep wxFileDialog HWND valid until it's dismissed in order to allow any
operations involving the dialog geometry to work correctly while it's
shown, so that e.g. resizing windows from the custom controls event
handlers works.
This should be rarely needed, but it doesn't cost anything to support
the new customization API if IFileDialog is not available at either
compile- or run-time, as this just reuses the existing generic
implementation.
Add implementation of the new file dialog customization API in terms of
the old one for the non-MSW ports (or even wxMSW if IFileDialog can't be
used for whatever reasons).
Just map wxFileDialogFoo to the corresponding wxFoo.
The hack with creating a dummy dialog just to get the size of the extra
controls is only used in wxMSW, so move it to MSW-specific file from the
common code.
To allow doing this there, add CreateExtraControlWithParent() helper,
which is still not really used anywhere else than in wxMSW, but at least
doesn't do anything particularly ugly and doesn't really penalize the
common code for wxMSW sins.
No real changes.
There is no need to call this function, just call CreateExtraControl()
directly -- it will do nothing if there are no extra controls to create.
No real changes.
Creating a text with a label is a common operation and can be
implemented to look slightly better than AddStaticText() followed by
AddTextCtrl() without a label when using IFileDialog.
Inherit wxFileDialogCustomControl from wxEvtHandler to allow Bind()ing
to events on it and use this to handle wxEVT_BUTTON and wxEVT_CHECKBOX
in the sample.
And inherit from IFileDialogControlEvents in wxMSW code to actually
generate these events when they happen.
wxFileDialog::SetCustomizeHook() can be implemented in terms of
IFileDialogCustomize in wxMSW, which means that it can be used with the
new style dialogs shown by IFileDialog, unlike SetExtraControlCreator(),
which could only be supported when using older style common dialogs.
Add support for a few different controls and wxMSW implementation, more
controls, generic implementation and the documentation will be updated
later.
Also update the sample to show the new API in action and allow toggling
between using it and the old API for testing.
Using the helper macros won't work with multiple inheritance that is
going to be used in the upcoming commits.
We also don't need real reference counting here, so simplify the code by
not using it.
The calls to SetSize() were doing nothing because our own overridden
DoGet{Position,Size}() fooled it into thinking that the window already
had the correct geometry.
Return the actual position and size during MSWOnInitDone(), i.e. when we
have a correct HWND, to prevent this from happening.
This allows to use the new style dialog for the file dialogs for which
Centre() or SetSize() had been called, as we can now position the window
even when not using a hook function.
As there is no IFileDialogEvents function corresponding to CDN_INITDONE
notification, use the first call to OnTypeChange() instead.
Instead of requiring the function itself to use GetParent(), call it in
the hook function and pass the actual dialog HWND to MSWOnInitDone().
No real changes, just refactoring to prepare for further changes.
Call it from the hook function when it gets CDN_INITDONE notification
instead.
This doesn't change anything yet, but will when MSWOnInitDone() is
called from elsewhere.
Extract a private function from src/msw/dirdlg.cpp, change its return
type to avoid losing information about the error and rename it to a more
clear name now that it's used outside of this file.
No real changes.
Also simplify the hook function code a little by using OPENFILENAME
local variable directly instead of using OFNOTIFY only to always use its
OPENFILENAME member and nothing else.
No real changes.
It was confusing to take the notification code from NMHDR itself in one
place and then from OFNOTIFY just below -- use NMHDR in both places, as
OFNOTIFY field refers to the same thing.
No real changes.
These functions were always marked as being implementation-only, but we
can actually do better and make them private, by making the dialog hook
function a (static) member of wxFileDialogMSWData and making this class
(which is now a class and not a struct any more, as it's not just a
collection of fields any longer) a friend of wxFileDialog.
No real changes.
No real changes, just make it possibly to add more fields to the private
struct in the future without affecting the ABI.
This commit is best viewed with git --color-moved
--color-moved-ws=ignore-all-space options.
