Your asii art is a nice solution.

And you've mentioned:

-------
        My approach is to make an 'input' class of my own
        for each of the input fields (eg. one for Fl_Input,
        Fl_Choice, etc).

        And in these classes have a 'name' field (std::string or char*)
        that is the "database name".
-------

I also have to add some extra fields/methods to other purposes.

I propose that fltk headers should have included a preprocessor directive  
to easy customizations like that by developers, something like this:

------

#include <FL/User_defined.H>

class FL_EXPORT Fl_Float_Input : public Fl_Input {
public:
   /**
       Creates a new Fl_Float_Input widget using the given position,
     size, and label string. The default boxtype is FL_DOWN_BOX.
   <P> Inherited destructor destroys the widget and any value associated  
with it
   */
   Fl_Float_Input(int X,int Y,int W,int H,const char *l = 0)
     : Fl_Input(X,Y,W,H,l) {type(FL_FLOAT_INPUT);right_to_left_=1;}

#ifdef USER_CUSTOM_DEFINED_FOR_FL_FLOAT_INPUT
        USER_CUSTOM_DEFINED_FOR_FL_FLOAT_INPUT;
#endif
};
--------

Example of a possible "<FL/User_defined.H>"
--------

#define USER_CUSTOM_DEFINED_FOR_FL_WIDGET \
        const char* field_name; \
        char* storage_space; \
        virtual bool validate_value() {return 0;};

#define USER_CUSTOM_DEFINED_FOR_FL_WIDGET_ON_CONSTRUTOR \
        const char* field_name = NULL; \
        char *storage_space = NULL;

#define USER_CUSTOM_DEFINED_FOR_FL_WIDGET_ON_DESTRUCTOR \
        if(field_name) free(field_name); \
        if(storage_space) free(storage_space);


#define USER_CUSTOM_DEFINED_FOR_FL_FLOAT_INPUT \
        bool allow_negative_values; \
        virtual bool validate_value() {return allow_negative_values ? true :  
value_float() > = 0;};

#define USER_CUSTOM_DEFINED_FOR_FL_FLOAT_INPUT_ON_CONSTRUCTOR \
         allow_negative_values = true;


--------

This way we can customize fltk for a lot of needs without having to derive  
new widgets only editing the "<FL/User_defined.H>" and include our  
definition file to the library, and we can update fltk sources without  
much worry about our customizations.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk

Reply via email to