Re: [fltk.development] [RFE] STR #2040: Deriving from Fl_Choice

[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2040 Version: 1.3-feature Fix Version: Will Not Fix As requested by the OP. Link: http://www.fltk.org/str.php?L2040 Version: 1.3-feature Fix Version: Will Not Fix ___ fltk-dev mailing l

Re: [fltk.development] [RFE] STR #2040: Deriving from Fl_Choice

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2040 Version: 1.3-feature You make a good point! Feel free to close this STR. If I could, I would revoke it. Perhaps that would be a good feature to the STR tracking syste

Re: [fltk.development] [RFE] STR #2040: Deriving from Fl_Choice

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2040 Version: 1.3-feature FLTK, like many other toolkits and GUI's , is an event driven interface. In the GUI SoA, events are dispatched and treated by what we called refl

Re: [fltk.development] [RFE] STR #2040: Deriving from Fl_Choice

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2040 Version: 1.3-feature To be honest, my rationale was two-fold for this STR. (1) Minimising the amount of work a caller would need to do to intercept when the FL_Choice

Re: [fltk.development] [RFE] STR #2040: Deriving from Fl_Choice

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2040 Version: 1.3-feature Overriding the handle() method and treating the FL_WHEN_RELEASE event isn't enough? Why the need of overriding another method here ? Link: http

Re: [fltk.development] [RFE] STR #2040: Deriving from Fl_Choice

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2040 Version: 1.3-feature Um, I beleive that this is not a pretty patch. Overriding the Fl_Menu_ method with the same function, but this time virtual, is not a good idea.

Re: [fltk.development] [RFE] STR #2040: Deriving from Fl_Choice

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2040 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2040 Version: 1.3-feature--- FL/Fl_Choice.H.original 2005-04-15 21:13:17.0 -0300 +++ FL/Fl_Choic

[fltk.development] [RFE] STR #2040: Deriving from Fl_Choice

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2040 Version: 1.3-feature When trying to derive from Fl_Choice, I noticed that it is impossible for a derived class to intercept when an item has been selected. I propose