Re: [fltk.general] getting parent class
As Edzard says, you can use RTTI with fltk just fine (though for backward compatibility reasons fltk does not use it itself.) So that may well work out as the best way for you - see Edzard's example. Though I'd only use it (myself) if my code was statically linked, and I'd built my copy of the fltk libs with RTTI enabled, just to be on the safe side. The behaviour (though things may be better these days!) of RTTI was often "unexpected", so if you are using dynamically linked code, potentially pulling in "unknown" fltk libs from the system, then I'd veer towards Greg's suggestion. That is, is it feasible to put some well-known string into (for example) the label() or user_data() field of your light_xyPad() class and just test for that string to ascertain if the parent group is a light_xyPad() or a "plain" Fl_Group...? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] getting parent class
On 01/16/12 23:42, Edzard Egberts wrote:
> Greg Ercolano schrieb:
>> AFAIK, FLTK doesn't use RTTI;
>
> But most of the modern compilers use RTTI as default (and even the older
> ones can activate it) and so it works, when regarding classes, derived
> from FLTK.
Neat, thanks Edzard!
So here's a simple little example that defines different widgets
so when you push the button, it walks the window's child() array,
printing the different types of classes:
// DEMONSTRATE USING RTTI IN FLTK - erco 01/17/12
// As suggested by Edzard on fltk.general
//
#include
#include
#include
#include
#include
#include
// SIMPLE DERIVED WIDGET
class MyClass : public Fl_Widget {
public:
MyClass(int X, int Y, int W, int H, const char*L=0) : Fl_Widget(X,Y,W,H,L)
{ }
void draw() { fl_color(FL_BLACK); fl_rectf(x(),y(),w(),h()); }
};
// CALLBACK INVOKED BY "Show" BUTTON
void ShowWidgets_CB(Fl_Widget *w, void*) {
Fl_Window *win = w->window(); // get button's parent window
for ( int i=0; ichildren(); i++ ) { // walk all window's children
const char *classname = "?";
Fl_Widget *w = win->child(i);
// Determine the class name of each widget
if ( dynamic_cast< Fl_Button* >(w) ) { classname = "Fl_Button"; }
else if ( dynamic_cast< Fl_Box*>(w) ) { classname = "Fl_Box"; }
else if ( dynamic_cast< Fl_Input* >(w) ) { classname = "Fl_Input"; }
else if ( dynamic_cast< MyClass* >(w) ) { classname = "MyClass"; }
printf("child #%d: %s\n", i, classname);
}
}
int main() {
Fl_Double_Window win(200,200,"RTTI Test");
// Make a bunch of children
Fl_Button but(10,10,140,25,"Show"); but.callback(ShowWidgets_CB);
Fl_Input inp(10,45,140,25);
Fl_Boxbox(10,80,10,10); box.color(45); box.box(FL_BORDER_BOX);
MyClass my1(10,100,10,10);
MyClass my2(10,120,10,10);
win.end();
win.show();
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] fltk 1.1.X to 1.3.0
I have developed an application using v 1.1.X series of fltk over many years, which places many sub windows at the same place inside the main app, only one at at time though. I have experimented using it with v1.3.0 and it compiles out of the box, but when it comes to running it the windows now appear as dialogs, i.e. not attached to the main app, i.e. somehow the current parent window has been set 0 at creation time. I will have to step through this under dbx and try to understand what is happening, but just wondered if there are differences between 1.1.X and 1.3.0 that to the developers would obviously account for this change in behaviour. Cheers in advance. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk 1.1.X to 1.3.0
On 17 Jan 2012, at 22:16, andy.pa...@baesystems.com wrote: > I have developed an application using v 1.1.X series of fltk over many years, > which places many sub windows at the same place inside the main app, only one > at at time though. > > I have experimented using it with v1.3.0 and it compiles out of the box, > but when it comes to running it the windows now appear as dialogs, > i.e. not attached to the main app, i.e. somehow the current parent window has > been set 0 at creation time. > > I will have to step through this under dbx and try to understand what is > happening, but just wondered if there are differences between 1.1.X and 1.3.0 > that to the developers would obviously account for this change in behaviour. I don't think so - not intentionally anyway... I've done this and it seemed to work "the same" with 1.1 and 1.3. I wonder what is different about your usage? Though, that said, using actual Fl_Windows as subwindows may not be optimal anyway; you might do better using Fl_Groups with a flat boxtype instead (though the co-ordinate frames will be different, of course...) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] getting parent class
Greg Ercolano schrieb:
> void ShowWidgets_CB(Fl_Widget *w, void*) {
> Fl_Window *win = w->window(); // get button's parent window
> for ( int i=0; ichildren(); i++ ) { // walk all window's children
> const char *classname = "?";
> Fl_Widget *w = win->child(i);
> // Determine the class name of each widget
> if ( dynamic_cast< Fl_Button*>(w) ) { classname = "Fl_Button";
> }
> else if ( dynamic_cast< Fl_Box*>(w) ) { classname = "Fl_Box"; }
> else if ( dynamic_cast< Fl_Input*>(w) ) { classname = "Fl_Input"; }
> else if ( dynamic_cast< MyClass*>(w) ) { classname = "MyClass"; }
> printf("child #%d: %s\n", i, classname);
> }
> }
You forgot, that programmers *love* recursions!
void Recur(Fl_Group *pG)
{
for ( int i=0; ichildren(); i++ )
{ // walk all groups children
const char *classname = "?";
Fl_Widget *w = win->child(i);
if (Fl_Group* pR= dynamic_cast< Fl_Group* >(w)) Recur(pR);
// Yes, that's it! :O)
else
{
> // Determine the class name of each widget
> if ( dynamic_cast< Fl_Button*>(w) ) { classname =
"Fl_Button"; }
> else if ( dynamic_cast< Fl_Box*>(w) ) { classname = "Fl_Box"; }
> else if ( dynamic_cast< Fl_Input*>(w) ) { classname =
"Fl_Input"; }
> else if ( dynamic_cast< MyClass*>(w) ) { classname =
"MyClass"; }
> printf("child #%d: %s\n", i, classname);
> }
> }
}
I'm not sure, wether all the brackets are right, but even if not
compilable this should show the idea.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
