1. wxWindows DLLs
A short time back someone posted something about wrapping wxWindows in a =
DLL.=20
I've been looking for an example of how to do this for some time.
If I could get an example of how this could be done, I'd appreciate it.
Thanks!
-- David Cuny
2. Re: wxWindows DLLs
On Mon, Feb 03, 2003 at 11:03:48PM -0800, David Cuny wrote:
>
> A short time back someone posted something about wrapping wxWindows in a DLL.
> I've been looking for an example of how to do this for some time.
>
> If I could get an example of how this could be done, I'd appreciate it.
>
> Thanks!
>
> -- David Cuny
Matt Lewis mentioned trying to wrap C++, and wxWindows, in Euphoria,
I also mentioned that I would be trying to wrap wxWindows, but in my case
it was by providing an interface lib which exposed the interface as C instead
of C++. (I'm looking at using SWIG to do this btw.)
jbrown
>
> ==^^===============================================================
> This email was sent to: jbrown1050 at hotpop.com
>
>
> TOPICA - Start your own email discussion group. FREE!
--
/"\ ASCII ribbon |
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME |
3. Re: wxWindows DLLs
Matthew wrote:
> I think it was me. I simply compiled wxWindows with MSVC, using the
> project/workspace files that came with the source. I haven't tried it,=
but
> I think that there's a Borland makefile for making a dll.
The include makefile apparently builds a DLL, but it's apparently for the=
=20
libraries that wxWindows uses, as opposed to the wxWindows functions. I c=
ould=20
be wrong about this.
> In any case, I use Dependency Walker to get a listing of all the=20
> exports--undecorated--and I've been importing them by ordinal, and=20
> calling by pointer.
If you've got a trivial example you could send me, I'd appreciate it.
> 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 cle=
ar=20
how things should be set up. Working with DLLs makes it doubly so.
> 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 z=
ips
> 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 o=
f the=20
callback is stored in the m_callbackUserData of the event:
void wRunCallback(wxEvent *event)
{
int id, eventObject, e;
WXTYPE eventType;
id =3D ((wxEvent *)event)->GetId();
eventObject =3D (int)((wxEvent *)event)->GetEventObject();
eventType =3D ((wxEvent *)event)->GetEventType();
// wrap the event
classIndex =3D wClassifyEvent( eventType );
if (classIndex =3D=3D -1) {
classIndex =3D _wxEvent;
}
e =3D (int)wAddObject( classIndex, (int)(wxEvent *)event );
// get the callback
wCallback *theCallback =3D (wCallback *)event->m_callbackUserData;
// and so on...
}
The m_callbackUserData has to be a wxObject. My data is a pointer to my s=
ymbol=20
table. It looks like this:
class wCallback: public wxObject {
public:
wCallback( wSymbol *theRoutine ) { routine =3D theRoutine; }
wSymbol *routine;
};
Pretty trivial. All events are handled by the same routine, defined in wx=
App.=20
There are only three classes in my wxApp:
class wxBasic : public wxApp
{
public:
virtual bool OnInit();
virtual int OnExit();
void HandleEvent(wxEvent& event);
};
Here's the ::HandleEvent routine, which calls wRunCallback (see above):
// event handler
void wxBasic::HandleEvent(wxEvent& event)
{
wRunCallback( &event );
}
All that's left is to connect a handler to an event. That's also pretty=20
trivial:
handler->Connect( id,=20
(wxEventType) theEvent,
(wxObjectEventFunction) (wxEventFunction) &wxBasic::HandleEven=
t,
new wCallback( routine ) );
So when an event triggers, it calls wxBasic::HandleEvent. That in turn ca=
lls=20
wRunCallback, which extracts the identity of the callback from the event'=
s=20
user data (m_callbackUserData). In your case, you probably want to store =
a=20
routine id or something...
I was thinking the way that it should work is there be a routine like=20
set_callback() in the DLL that you could pass a pointer to, and it would =
set=20
up the pointer back to Euphoria (or whatever language was calling). Getti=
ng=20
the DLL to call back was something I never quite figured out - the syntax=
to=20
pointers to functions gives me a headache.
> 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=20
vtable. DLL magic?
I use:
IMPLEMENT_APP(wxBasic)
to setup the app, but for DLLs you have to do something else. There's an=20
IMPLEMENT_APP_NO_MAIN macro that looks promising, but I can't find any=20
documentation for it.
> I've been trying to translate the Fractal demo that comes with the sour=
ce,
> so MyApp::OnInit calls code that creates a Frame.
Sounds about right...
> And then it breaks...
Argh.
-- David Cuny
4. Re: wxWindows DLLs
I wrote:
> There are only three classes in my wxApp:
Make that "three methods", sorry.
-- David
