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

Do you have a typical platform dependent issue you're battling with ? Ask it here. Make sure you mention your platform, compiler, and wxWidgets version.
Post Reply
Belgabor
I live to help wx-kind
I live to help wx-kind
Posts: 173
Joined: Mon Sep 25, 2006 1:12 pm

Making generic dialogs available on non-generic build.

Post by Belgabor » Fri Sep 29, 2006 1:19 am

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.

User avatar
tierra
Site Admin
Site Admin
Posts: 1343
Joined: Sun Aug 29, 2004 7:14 pm
Location: Salt Lake City, Utah, USA
Contact:

Post by tierra » Fri Sep 29, 2006 2:56 am

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
I live to help wx-kind
I live to help wx-kind
Posts: 173
Joined: Mon Sep 25, 2006 1:12 pm

Post by Belgabor » Fri Sep 29, 2006 3:16 am

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 :D )

User avatar
tierra
Site Admin
Site Admin
Posts: 1343
Joined: Sun Aug 29, 2004 7:14 pm
Location: Salt Lake City, Utah, USA
Contact:

Post by tierra » Fri Sep 29, 2006 8:21 pm

Belgabor wrote: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 :D )
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
I live to help wx-kind
I live to help wx-kind
Posts: 173
Joined: Mon Sep 25, 2006 1:12 pm

Post by Belgabor » Sat Sep 30, 2006 3:53 am

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.

User avatar
ABX
Can't get richer than this
Can't get richer than this
Posts: 810
Joined: Mon Sep 06, 2004 1:43 pm
Location: Poznan, Poland
Contact:

Re: Making generic dialogs available on non-generic build.

Post by ABX » Thu Oct 12, 2006 6:48 am

Belgabor wrote: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
CVS Head, 2.8.X
wxMSW, wxWinCE, wxPalmOS, wxOS2, wxMGL, bakefile
gcc 3.2.3, bcc 5.51, dmc 8.48, ow 1.6, vc 7.1, evc 3/4, pods 1.2

Belgabor
I live to help wx-kind
I live to help wx-kind
Posts: 173
Joined: Mon Sep 25, 2006 1:12 pm

Post by Belgabor » Fri Oct 13, 2006 3:47 pm

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
Earned some good credits
Earned some good credits
Posts: 123
Joined: Tue Dec 21, 2004 8:51 pm
Location: Austria

Post by tiwag » Fri Oct 13, 2006 6:45 pm

Belgabor wrote: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 ?
-tiwag

Belgabor
I live to help wx-kind
I live to help wx-kind
Posts: 173
Joined: Mon Sep 25, 2006 1:12 pm

Post by Belgabor » Fri Oct 13, 2006 7:53 pm

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.

Post Reply