On 11/17/05, Ray Gilbert <ray...@sc...> wrote:
> I am still working on generating a new set of interfaces directly from
> wx head cvs. I am making progress, but nothing stable yet.
Good. You had mentioned that these interface files are in XML, is that righ=
t?
> Trying to figure out the best way to handle issues involving base
> classes that vary according to implementation (e.g. using wxGeneric vs
> native)
Which classes give you a problem?
As an aside, but I'm guessing that this is kinda' along the same lines
as your problem, I've been wondering if I should ask on wx-dev if
wxWidgets should rename all the classes to follow something like this.
wxListCtrlBase (for example)
msw wxListCtrlMSW
gtk wxListCtrlGTK
univ wxListCtrlUniv
generic wxListCtrlGeneric (and GTK would be typedefed to this)
etc...
and then using #defines typdef wxListCtrl to the appropriate class.
This way, in MSW for example, you could use wxListCtrlGeneric and
wxListCtrlMSW (the latter of which would be typedefed to just
wxListCtrl.
> wxLua tends to only create luac functions for prototypes in lua
> metatable, if not found it then goes to base class metatable.
This seems reasonable, if not the best way to do it.
> My current thought is simply merge all base class calls up to main class
> metatable and ignore base class redirection - thereby avoiding bad
> casts.
Maybe this could be worked around somehow with our own code, if there
aren't too many of them. Maybe add something like this to the
interface files, where we can add C++ to the generated files directly.
%verbatim (or %inline)
#if __WXGTK__
typedef wxXXXGeneric wxXXX
#elseif __WXMSW__
...
#endif
%endverbatum
-John Labenski
|
