Making generic dialogs available on non-generic build. Topic is solved

[Belgabor]

Is it somehow possible to compile/link the generic dialog classes into a non-generic wxWidgets build? I usually prefer the platform specific dialogs but I'd need one of the generics for subclassing.

[tierra]

As far as I can tell, not without modifying wxWidgets source...

In your applications code, it looks like you might be able to just explicitly define wxUSE_GENERIC_FILEDIALOG and include "wx/generic/filedlgg.h" and go from there, but you'd need to actually edit wxWidgets source to force building the generic dialog source as opposed to the platform specific one when you build the library.

[Belgabor]

The problem is that the code (in my case generic/filedlgg.cpp) is not compiled and linked into the wxWidgets library. I don't need wxUSE_GENERIC_FILEDIALOG set as I want to subclass wxGenericFileDialog directly which is not under an #ifdef.
There are some other troubles which will need a fix in wxWidgets (namely a global variable that manages updates between the dialog and the file control), but if I can't get it compiled into the lib, I won't address this and stick to my current workaround (coping the files form wxWidgets to my app sources and hacking them directly )

[tierra]

but if I can't get it compiled into the lib, I won't address this and stick to my current workaround (coping the files form wxWidgets to my app sources and hacking them directly )

I hope you understand that means releasing either that module of code or your application under the wxWindows Library Licence along with source. It really doesn't look like it'd be too hard to just edit "include/wx/filedlg.h" to force including the generic header, and modifying the wxWidgets bakefile/makefile/vcproj file (grep for "filedlg") to build the generic file dialog as opposed to the platform specific one, then posting a patch to SF.net (fulfilling your obligation to contribute modifications/fixes back to wxWidgets even if your patch isn't used). It is built to be interchangable like that.

[Belgabor]

My app will be GPL'd.
I will see how hard it is to patch wxWidget's generic filedlgg to a version that both fits my needs and will be accepted by the devs. I already have an idea how to do that. Unfortunately I have no idea how to make the autoconf/automake framework link the generic filedlgg into the platform specific build which would make the patch complete.

[ABX]

Is it somehow possible to compile/link the generic dialog classes into a non-generic wxWidgets build? I usually prefer the platform specific dialogs but I'd need one of the generics for subclassing.

Did you tried 'dialogs' sample? AFAIU your question that's exactly what is shown there - how to use generic dialogs in one build with native ones. You can perfectly derive from generic dialog.

ABX

[Belgabor]

The sample was what got me started =)
The problem is that it links the generic dialogs directly, something that works well for a sample that lives within the same source tree, but seems kind of hacky for your own apps whose source is usually located somewhere else.
I had hoped for a somewhat cleaner solution that puts it in the wx libraries (I have that currently, but it requires hacking the makefile which is ugly in its own manner...)

[tiwag]

The sample was what got me started =)
The problem is that it links the generic dialogs directly, something that works well for a sample that lives within the same source tree, but seems kind of hacky for your own apps whose source is usually located somewhere else...

what bars you to copy the necessary sourcecode from the wanted control to your own source code ?

[Belgabor]

Nothing big. That was my first implementation. But I'd prefer to keep the wxWidgets stuff in the respective lib to prevent having two licenses in my code.
I already modified the generic dialog to make it more subclassing friendly, but I currently don't have the time to work on it to put it in a state where I could submit it as a patch.