RE: wxWindows DLLs
> From: David Cuny [mailto:dcuny at LANSET.COM]
> The include makefile apparently builds a DLL, but it's
> apparently for the
> libraries that wxWindows uses, as opposed to the wxWindows
> functions. I could
> be wrong about this.
Hmmm. I'll have to try it...
> > In any case, I use Dependency Walker to get a listing of all the
> > exports--undecorated--and I've been importing them by ordinal, and
> > calling by pointer.
>
> If you've got a trivial example you could send me, I'd appreciate it.
It's actually pretty simple. GetProcAddr will take either a pointer to a
string, or an ordinal number (if the high word is 0, then it assumes you're
asking for an ordinal). Then I have a pointer to the function (equivalent
to define_c_var). I think Rob was going to allow this in 2.4. Then I can
use my fptr.e lib to call the functions by pointer.
> > I've been able to create a window, but unable to get the main
> > message loop to work.
>
> A lot of initialization is hidden in the macros, so it's not
> entirely clear
> how things should be set up. Working with DLLs makes it doubly so.
Yeah, it took a while to straighten some of that stuff out.
> > The debug version of the dll is about 4.8Mb (takes about a
> half hour to
> > compile on a P/MMX 200), though it UPXs down to about
> 1.5Mb, and then zips
> > to a little over 1Mb. There are between 11,000 and 12,000 exports.
>
> That sounds about right.
>
>
> > Here's what I've done in Eu to try to make it work:
>
> In my code, all callbacks are handled by the same routine.
> The identity of the
> callback is stored in the m_callbackUserData of the event:
<snip>
> Pretty trivial. All events are handled by the same routine,
> defined in wxApp.
I hadn't gotten that far yet. I'd just made explicit routines for the
events.
> All that's left is to connect a handler to an event. That's
> also pretty
> trivial:
>
> handler->Connect( id,
> (wxEventType) theEvent,
> (wxObjectEventFunction) (wxEventFunction)
> &wxBasic::HandleEvent,
> new wCallback( routine ) );
Yeah, I'm using Connect, as well.
> I was thinking the way that it should work is there be a routine like
> set_callback() in the DLL that you could pass a pointer to,
> and it would set
> up the pointer back to Euphoria (or whatever language was
> calling). Getting
> the DLL to call back was something I never quite figured out
> - the syntax to
> pointers to functions gives me a headache.
Well, it calls myApp_Create() and myApp_OnInit() alright.
> > Set up an OnInit for class MyApp.
> > Set up a wxCreateApp function that allocates memory and
> calls the wxApp
> > constructor, then pokes the address for MyApp::OnInit into the vtbl.
> > Call wxAppInitializer (it's exported in the dll) with a pointer to
> > wxCreateApp.
> > Then I call wxEntry.
>
> I'm not clear why you have to poke the address of
> MyApp::OnInit into the
> vtable. DLL magic?
No, C++ magic. :) Since I'm coding in Euphoria, I have to do some of the
housekeeping that C++ automatically does when you derive a class and
override a virtual function. The 'this' pointer points to where the object
stores everything about itself. The first 4 bytes contain the pointer to
the object's vtable. That's the only way to call a function's virtual
functions (OK, OK, they're actually exported by the DLL, so you can get
pointers to them that way). So when I create an object, I allocate memory
and call its parent's constructor. Then I change the addresses of the
virtual functions I've overloaded.
> I use:
>
> IMPLEMENT_APP(wxBasic)
>
> to setup the app, but for DLLs you have to do something else.
> There's an
> IMPLEMENT_APP_NO_MAIN macro that looks promising, but I can't
> find any
> documentation for it.
After straightening out all the imbedded macros, I think I'm doing
everything that gets done by IMPEMENT_APP(). My gut feeling is that I have
a memory allocation problem, or I'm storing something incorrectly.
Matt Lewis
|
Not Categorized, Please Help
|
|
