[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Tabbed dialogs
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Tue, 02 May 2006 12:00:55 +0100
- Subject: Re: [XaraXtreme-dev] Tabbed dialogs
This may be a stupid quection, but how does using a dynamically created
wxPropertySheetDialog stop a dialog being managed by wxAUI?
wxAUI can only manage objects which are not TLWs, like wxPanel. So
as wxPropertySheetDialog is derived from wxDialog, which in turn is
derived from wxTopLevelWindow, wxAUI cannot manage it.
You would need to have a contained /not/ derived from wxTopLevelWindow
in order for wxAUI to manage it.
In fact perhaps that ought to be my test for wxAUImanaged (i.e.
if it's /not/ derived from wxTopLevelWindow), because by definition
if it is not a TLW it will require managing, and if it IS a TLW
it will require not to be managed.
I just ported the Camelot implementation on the principal that it would
mean that client code would be easier to port.
Sure, that's fair enough. We could make it so that if no resource is
present in the resource file, it uses the default implementation
Much of the dialog creation stuff has changed (as you can tell by
the way I load them) anyway, without too much collateral damage.
I can convert it over to do resource loading after you've done
if you like.
> Although I have noticed
that the dialog code in Kernel is make all kinds of naughty abstraction
busting direct calls to oily stuff.
Yes there are all sorts of nasties in there. I only got rid of a few.
In general I've pushed them down into dialogmanager, and where easy
done weak abstraction a la CWindowID typedef.