En 16/11/2010 01:03:17, Greg Ercolano <[email protected]> escribió:
> Hmm, but isn't that the same as deriving a MyIntInput class
> from Fl_Float_Input, and then referencing it inside fluid
> by dropping an Fl_Int_Input widget into the fluid form and
> setting the "Class:" field in the C++ properties to MyIntInput?
>
On the original specific question yes it's the same but as a generic
broader solution it isn't, for some things it's easier to have extra
fields/methods from the base classes.
Like for the "const char* field_name;" if we set it on FL_Input_ we have
it for all it's derived classes with less code and everywhere we use our
customized fltk.
>
> Domingo Alvarez Duarte wrote:
>> 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.
--
Usando el revolucionario cliente de correo de Opera:
http://www.opera.com/mail/
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
