wxW plugin (dll) used by wxW app, both using wxW static libs

Are you writing your own components and need help with how to set them up or have questions about the components you are deriving from ? Ask them here.
Post Reply
catalin
Moderator
Moderator
Posts: 1618
Joined: Wed Nov 12, 2008 7:23 am
Location: Romania

wxW plugin (dll) used by wxW app, both using wxW static libs

Post by catalin »

Hi,

This issue was addressed many times but I could not find a generic implementation for it.

The issue: creating a dll (call it "plugin") that holds GUI elements, and use it into an application, both using wxW built as static libs (so no wxW built as dll(s)).
I understand that there will be some limitations for wxWindow derived widgets. So I'll go with the approach that the plugin's entire GUI is in a separate frame, and it will only exchange non-wxW related data with the app.

Does anyone have a tutorial or a good example?
The wxW version is 2.8.10
The OS is MSW, but I'd like that to be irrelevant (can it?).

Few guidelines that I've found:
- use IMPLEMENT_APP_NO_MAIN (and wxEntryStart / wxEntryCleanup ?);
- create an entry point for the plugin (i.e. dllMain);
- setup the plugin's event loop in a separate thread (?);

I just don't know how to peace everything together, and whatever is still missing.

Thank you,
C
tan
wxWorld Domination!
wxWorld Domination!
Posts: 1471
Joined: Tue Nov 14, 2006 7:58 am
Location: Saint-Petersburg, Russia

Post by tan »

Hi,

there is a good sample for that in incoming 2.9 version. Look at WX_ROOT/samples/dll. That implements exactly what do you want.
Don't sure though about 2.8.X.
OS: Windows XP Pro
Compiler: MSVC++ 7.1
wxWidgets: 2.8.10
catalin
Moderator
Moderator
Posts: 1618
Joined: Wed Nov 12, 2008 7:23 am
Location: Romania

Post by catalin »

Thanks, I know the sample but I'm not sure it is what I need. AFAIU it would work if wxW libs used for the app are built as dll, but I want both to be as static libs.
Further more, it is for 2.9 and it doesn't say how/what would be different in 2.8; and it is msw dependent, something I'd like to avoid.
tan
wxWorld Domination!
wxWorld Domination!
Posts: 1471
Joined: Tue Nov 14, 2006 7:58 am
Location: Saint-Petersburg, Russia

Post by tan »

catalin wrote:Thanks, I know the sample but I'm not sure it is what I need. AFAIU it would work if wxW libs used for the app are built as dll, but I want both to be as static libs.
No, very much the other way. For the first case (dll) problems in general are not present at all. From readme.txt:
...
The simplest way to solve number (2) is to share the wxWidgets library between
the DLL and the host, in the form of wxWidgets DLLs build. But this requires
both the host and the DLL to be compiled against exactly same wx version,
which is often impractical.

So we do something else here: the DLL is compiled against *static* build of
wx. This way none of its symbols or variables will leak into the host app.
Win32 runtime conflicts are eliminated by using DLL's HINSTANCE instead of
host app's one and by using unique window class names (automatically done
since wx-2.9).
catalin wrote: Further more, it is for 2.9 and it doesn't say how/what would be different in 2.8; and it is msw dependent, something I'd like to avoid.
Yes, here you are right. Apparently it will not work with 2.8 :( but it isn't so big problem, move to 2.9 :)
I have no ideas about msw dependent though. May be dev mail-list will help you?
OS: Windows XP Pro
Compiler: MSVC++ 7.1
wxWidgets: 2.8.10
catalin
Moderator
Moderator
Posts: 1618
Joined: Wed Nov 12, 2008 7:23 am
Location: Romania

Post by catalin »

tan wrote:
catalin wrote:AFAIU it would work if wxW libs used for the app are built as dll, but I want both to be as static libs.
No, very much the other way. For the first case (dll) problems in general are not present at all. From readme.txt:
...
The simplest way to solve number (2) is to share the wxWidgets library between
the DLL and the host, in the form of wxWidgets DLLs build. But this requires
both the host and the DLL to be compiled against exactly same wx version,
which is often impractical.

So we do something else here: the DLL is compiled against *static* build of
wx. This way none of its symbols or variables will leak into the host app.
Win32 runtime conflicts are eliminated by using DLL's HINSTANCE instead of
host app's one and by using unique window class names (automatically done
since wx-2.9).
Yup, read it some while ago, tried and failed.
I was under the impression that the app must be compiled against dynamic wxW. But just tried again and it worked even with mingw. So there is hope. Do you have any idea what is different from 2.8?
tan wrote:
catalin wrote:Further more, it is for 2.9 and it doesn't say how/what would be different in 2.8; and it is msw dependent, something I'd like to avoid.
Yes, here you are right. Apparently it will not work with 2.8 :( but it isn't so big problem, move to 2.9 :)
This is something I personally agree with but not applicable this time :)
tan wrote:I have no ideas about msw dependent though. May be dev mail-list will help you?
I might find some answers there.
OTOH people here were talking on similar subjects and I did hope... :|

Anyway, thanks for your time, and please send any other idea if you happen to get some more :P
User avatar
evstevemd
Part Of The Furniture
Part Of The Furniture
Posts: 2409
Joined: Wed Jan 28, 2009 11:57 am
Location: United Republic of Tanzania

Post by evstevemd »

tan wrote: Apparently it will not work with 2.8 :( but it isn't so big problem, move to 2.9 :)

I second that, but I would also suggest you use the non SVN as there are major changes taking place there. I use the official download and have problems in compiling samples (wxConsole and wxSTC) but apart from that I have little problem
Chief Justice: We have trouble dear citizens!
Citizens: What it is his honor?
Chief Justice:Our president is an atheist, who will he swear to?
Post Reply