moving to wxWidgets 3.1

[jon bird]

Hi,

I've been rebuilding my app to use wxWidgets 3.1 (over 3.02) because I
want to take advantage of some of the new features, notably support for
high DPI displays under Windows. Aside from having to fix a few
inconsistencies with some of my window flags which are now picked up as
assertions, I've got one issue and a query:

During startup, I'm now getting an assertion failure:

... assert "traits" failed in wxStandardPathsBase::Get(): create wxApp
before calling this

This is being triggered by a call to
wxStandardPaths::Get().GetExecutablePath() invoked as part of the main
windows's OnInit call. This wasn't happening with 3.02 (it still yields
the correct answer though even under 3.1). It seems clear that it's not
happy with this call being made this early on in the initialisation
process but bearing in mind this is *the* Init call from wxApp and I
want to retrieve this information as part of my app initialisation how
is this addressed?

wxGenericStaticBitmap::SetScaleMode, this is a new call in 3.1 however
it doesn't appear to do anything under Windows ie. whatever I pass to
the routine has the same effect as if it were Scale_None.

Rgs,


Jon.

--
== jon bird - software engineer
== <reply to address _may_ be invalid, real mail below>
== <reduce rsi, stop using the shift key>
== posted as: news 'at' onastick 'dot' clara.co.uk

[Vadim Zeitlin]

On Sun, 10 Dec 2017 18:06:18 +0000 jon bird wrote:

jb> During startup, I'm now getting an assertion failure:
jb>
jb> ... assert "traits" failed in wxStandardPathsBase::Get(): create wxApp
jb> before calling this
jb>
jb> This is being triggered by a call to
jb> wxStandardPaths::Get().GetExecutablePath() invoked as part of the main
jb> windows's OnInit call. This wasn't happening with 3.02

This is rather surprising, considering that this assert was added in
81f9c575047d54b1a5feb28b9d16ed1ce1eeb9b6 12.5 years ago, i.e. it was even
in 2.8, let alone 3.0. I can't really explain why hadn't you been getting
it before...

jb> (it still yields the correct answer though even under 3.1).

Yes, there is no problem with doing this under MSW or Unix, but it would
silently fail to work correctly in GUI applications under OS X if you call
it before the application object creation because it would use the standard
Unix/POSIX implementation there instead of the CoreFoundation-based one
which is only available via wxApp.

jb> It seems clear that it's not happy with this call being made this early
jb> on in the initialisation process but bearing in mind this is the Init
jb> call from wxApp and I want to retrieve this information as part of my
jb> app initialisation how is this addressed?

By the time YourApp::OnInit() is called, wxTheApp is already set, so there
should be no problem with using wxStandardPaths from it. Please try to
provide SSCCE of the problem, I tried reproducing it with:

---------------------------------- >8 --------------------------------------
#include <wx/app.h>
#include <wx/frame.h>
#include <wx/stdpaths.h>

class MyFrame : public wxFrame
{
public:
MyFrame()
: wxFrame(NULL, wxID_ANY, wxStandardPaths::Get().GetExecutablePath())
{
}
};

class MyApp : public wxApp
{
public:
virtual bool OnInit() wxOVERRIDE
{
(new MyFrame)->Show();
return true;
}

virtual int OnExit() wxOVERRIDE { return 0; }
};

wxIMPLEMENT_APP(MyApp);
---------------------------------- >8 --------------------------------------

but it worked just fine for me.


jb> wxGenericStaticBitmap::SetScaleMode, this is a new call in 3.1 however
jb> it doesn't appear to do anything under Windows ie. whatever I pass to
jb> the routine has the same effect as if it were Scale_None.

I'm not sure what do you expect it to do, in particular please note that
this has nothing to do with DPI. From looking at the code, it looks like it
ought to do what it's documented to do, i.e. resize the bitmap when the
control is resized. If it doesn't work for you, an example or a patch to
the (static page of the) widgets sample would again be welcome.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[jon bird]

In article <E1eO9hQ-...@smtp.tt-solutions.com>, Vadim Zeitlin
<va...@wxwidgets.org> writes

>On Sun, 10 Dec 2017 18:06:18 +0000 jon bird wrote:
>
>jb> During startup, I'm now getting an assertion failure:
>jb>
>jb> ... assert "traits" failed in wxStandardPathsBase::Get(): create wxApp
>jb> before calling this
>jb>
>jb> This is being triggered by a call to
>jb> wxStandardPaths::Get().GetExecutablePath() invoked as part of the main
>jb> windows's OnInit call. This wasn't happening with 3.02
>
> This is rather surprising, considering that this assert was added in
>81f9c575047d54b1a5feb28b9d16ed1ce1eeb9b6 12.5 years ago, i.e. it was even
>in 2.8, let alone 3.0. I can't really explain why hadn't you been getting
>it before...
>

This is entirely my fault, I realised early this morning that one of my
DLLs was still linked with the 3.02 library. Apologies for the
inconvenience.

[...]

>
>jb> wxGenericStaticBitmap::SetScaleMode, this is a new call in 3.1 however
>jb> it doesn't appear to do anything under Windows ie. whatever I pass to
>jb> the routine has the same effect as if it were Scale_None.
>
> I'm not sure what do you expect it to do, in particular please note that
>this has nothing to do with DPI.

Yes, I haven't got started with the DPI stuff, this is something else I
was interesting in using.

>From looking at the code, it looks like it
>ought to do what it's documented to do, i.e. resize the bitmap when the
>control is resized. If it doesn't work for you, an example or a patch to
>the (static page of the) widgets sample would again be welcome.
>

Looking (and playing) with the sample, the key bit which seems to be the
key is messing around with the sizer holding the control - from the
sample:

wxStaticBitmapBase::ScaleMode scaleMode =
(wxStaticBitmapBase::ScaleMode) m_scaleRadio->GetSelection();
m_statbmp->SetScaleMode(scaleMode);
if ( m_statbmp->GetScaleMode() != scaleMode )
wxLogError("Scale mode not supported by current
implementation");
wxSizerItem* sbsizerItem = GetSizer()->GetItem(m_sbsizer);

if ( scaleMode == wxStaticBitmapBase::Scale_None )
{
sbsizerItem->SetProportion(0);
sbsizerItem->SetFlag(wxCENTER);
}
else
{
sbsizerItem->SetProportion(1);
sbsizerItem->SetFlag(wxEXPAND);
}

If I comment out the final "if" statement, the behaviour is exactly as I
get with my app. I've not quite figured out what:

wxSizerItem* sbsizerItem = GetSizer()->GetItem(m_sbsizer);

is actually doing (my bitmap is sat in a grid sizer, not sure if that is
relevant at all) but I'll carry on digging around this.

[Vadim Zeitlin]

On Mon, 11 Dec 2017 18:53:32 +0000 jon bird wrote:

jb> Looking (and playing) with the sample, the key bit which seems to be the
jb> key is messing around with the sizer holding the control - from the
jb> sample:
jb>
jb> wxStaticBitmapBase::ScaleMode scaleMode =
jb> (wxStaticBitmapBase::ScaleMode) m_scaleRadio->GetSelection();
jb> m_statbmp->SetScaleMode(scaleMode);
jb> if ( m_statbmp->GetScaleMode() != scaleMode )
jb> wxLogError("Scale mode not supported by current
jb> implementation");
jb> wxSizerItem* sbsizerItem = GetSizer()->GetItem(m_sbsizer);
jb>
jb> if ( scaleMode == wxStaticBitmapBase::Scale_None )
jb> {
jb> sbsizerItem->SetProportion(0);
jb> sbsizerItem->SetFlag(wxCENTER);
jb> }
jb> else
jb> {
jb> sbsizerItem->SetProportion(1);
jb> sbsizerItem->SetFlag(wxEXPAND);
jb> }

The sample is unfortunately being too fancy here, and I don't really know
why because just always use the proportion of 1 and wxEXPAND wouldn't do
any harm when scaling is not supported and would be much less confusing.

jb> If I comment out the final "if" statement, the behaviour is exactly as I
jb> get with my app. I've not quite figured out what:
jb>
jb> wxSizerItem* sbsizerItem = GetSizer()->GetItem(m_sbsizer);
jb>
jb> is actually doing (my bitmap is sat in a grid sizer, not sure if that is
jb> relevant at all) but I'll carry on digging around this.

You just need to make it resizable -- and then it will resize.

[jon bird]

In article <E1eOV7W-...@smtp.tt-solutions.com>, Vadim Zeitlin
<va...@wxwidgets.org> writes

>On Mon, 11 Dec 2017 18:53:32 +0000 jon bird wrote:
>
>jb> Looking (and playing) with the sample, the key bit which seems to be the
>jb> key is messing around with the sizer holding the control - from the
>jb> sample:
>jb>

[...]

>
> The sample is unfortunately being too fancy here, and I don't really know
>why because just always use the proportion of 1 and wxEXPAND wouldn't do
>any harm when scaling is not supported and would be much less confusing.
>
>jb> If I comment out the final "if" statement, the behaviour is exactly as I
>jb> get with my app. I've not quite figured out what:
>jb>
>jb> wxSizerItem* sbsizerItem = GetSizer()->GetItem(m_sbsizer);
>jb>
>jb> is actually doing (my bitmap is sat in a grid sizer, not sure if that is
>jb> relevant at all) but I'll carry on digging around this.
>
> You just need to make it resizable -- and then it will resize.
>

Marvellous, yes that all works as I'd expect now thanks for the support.