Wx lib GUI App: build it static or dynamic? Topic is solved

[maxbld]

Dear all,

I've made an app that has GUI objects that are used as base classes to show a wxGrid and they're derived each time the contents of the wxGrid are different. The approach makes easier to link the wxGrid to different database tables, since each time I just have to initialize a derived class and let the base class do all the hard work. Now I'd like to take the base classes collection, make a library out of it and use it in another application.

The question is should I link my library against a static or a dynamic version of wxWidgets? My concern is If I do it static, it will be possible then to use it in apps that link other wxWidgets versions, so I'd have a thing compiled once and for all, but what about wasting memory? I mean my lib will have to include yet another wxWidgets lib for database that links against wxWidgets and so I'll have to have two libs with two static builds of wxWidgets, plus the wxWidgets library of the .exe that includes it all, meaning at runtime I end with 3 separate wxWidgets threads all of them loaded in memory. Am I right, first of all, that I'll have 3 separate threads? And if yes, would that be wise, or can I count on the fact that nowadays PCs have 8GB RAM, so who cares 'bout wasting memory?

Thanks a lot to anybody who'll take the time to answer, BR,
Max.

[doublemax]

Regardless of the memory consumption, linker issues, etc, having multiple instances of wxWidgets in the same executable is a recipe for disaster and just won't work 99% of the time unless you know exactly what you're doing.

Don't do this

[maxbld]

Regardless of the memory consumption, linker issues, etc, having multiple instances of wxWidgets in the same executable is a recipe for disaster and just won't work 99% of the time unless you know exactly what you're doing.

Don't do this

Ok, I see what you mean, but when all the libs have their own wxWidgets built in statically all should be well, shouldn't it? And have a look at this text:

This Windows-specific sample demonstrates how to use wxWidgets-based UI from
within a foreign host application that may be written in any toolkit
(including wxWidgets).

For this to work, you have to overcome two obstacles:

(1) wx's event loop in the DLL must not conflict with the host app's loop
(2) if the host app is written in wx, its copy of wx must not conflict
with the DLL's one

Number (1) is dealt with by running DLL's event loop in a thread of its own.
DLL's wx library will consider this thread to be the "main thread".

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).

This is from D:\wxWidgets-3.0.2\samples\dll\README.txt, and it looks like it's suggesting to really use static links when making DLLs. Or did you just mean don't include into a wxWidgets app any DLL compiled against a different wxWidgets version, regardless static or dynamic?

Thank you, BR,
Max.

[doublemax]

The only situation where it makes sense to link the DLL statically to wxWidgets is when the DLL should also work with non-wxWidgets host applications.

But if both the host application and the DLL link statically to wxWidgets, there are some limitations:
Both wxWidgets instances need to run in their own thread in order for the event loops to work. These two wxWidgets instances don't "know" anything about each other. E.g. you can't pass a wxWindow * pointer from the host to the DLL and use it as a parent for a window in the DLL.

And there will probably me more problems along the way. I just don't think it's worth the effort.

[maxbld]

you can't pass a wxWindow * pointer from the host to the DLL and use it as a parent for a window in the DLL.

And that is exactly what I wanted to do... No way, then! Thanks!!

BR,
Max.