[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] XCode - built Mac Version will not display wxXtra SplashScreen
- From: "Ben Fowler" <ben.the.mole@xxxxxxxxx>
- Date: Sat, 1 Jul 2006 09:58:17 +0100
- Subject: Re: [XaraXtreme-dev] XCode - built Mac Version will not display wxXtra SplashScreen
On 01/07/06, Alex Bligh <alex@xxxxxxxxxxx> wrote:
> [ snip ]
> On (a) isn't it sufficient that the 'this' pointer is the same -- have
> I shown that it is the same? Am I missing something about C++ and
I don't think we've checked that the (consistent) this pointer ties
up with event.EventObject (i.e. what is being passed to IsKindOf() ).
I'll take a look at that.
> i) I think that wxFrame is a base class of wxAdvSplashScreen, and
> this is why its constructor is called before wxAdvSplashScreen's runs.
Ah. I was misreading the stack dump. I thought it was wxAdvSplashScreen's
constructor that was calling ::Create in wxFrame. Actually the "forked"
construction mechanism (i.e. calling ::Create is done at the wxFrame level),
so at the point it gets into the "Create" loop, wxFrame's constructor has
not completed, so the VFT pointer in the object is still pointing to a
wxFrame VFT and this is confusing the IsKindOf() stuff.
Sounds reasonable. Given that TLWs need to murder the
wxAdvSplashScreen, it is tight that wxAdvSplashScreen is itself a TLW.
Whilst one possibilitity would be to check ahead of
CamResource::DoneInit() that we are not trtying kill the window we are
So I think I know how to fix this cleanly - do a separate call into
Frame's Create function rather than rely on wxFrame to do it, because
the VFT pointer by then will be set to wxAdvSplashScreen's VFT as the
underlying constructors will have exited even though Create() won't yet
have been called. I'll try to fix that up this PM.
> ii) I need to check that I am using the mac/carbon/frame.h
This is so.