[ Return to Bugs & Features | Roadmap 1.1 ]
|Status:||1 - Closed w/Resolution|
|Priority:||2 - Low, e.g. a documentation error or undocumented side-effect|
|Scope:||3 - Applies to all machines and operating systems|
|Summary:||Suggested new widget: Fl_Input_Choice|
|Fix Version:||1.1.7 (SVN: v4050)|
Trouble Report Files:
Trouble Report Comments:
15:11 Dec 13, 2004
|This is basically a single .H file that combines the |
Fl_Input and Fl_Choice widgets in such a way that the
user can either type in a value, or choose values from a menu.
Source and docs are here:
Core folks may want to modify the API, feel free to do so,
or I can make them for you if you have suggestions.
15:47 Dec 13, 2004
|Followup: Use the Fl_Choice_Input.H at the URL, |
instead of the attached file which had leftover #includes,
and some non-fltk indents.
16:28 Dec 13, 2004
|Shouldn't the resize() method be public? |
Also, I think some more inline methods might be useful:
value(int) (to replace menuvalue)
But it looks promising, and I have no objections to adding this to 1.1.x whenever I do 1.1.7.
02:47 Dec 15, 2004
|> resize() public? |
> add(), size(), value(int) (to replace menuvalue) clear()
I wasn't sure where to draw the line as to which methods
to implement, and which to just leave to the user to get
via the internal widget accessors "menubutton()" and "input()".
Seems like there are three ways to approach the API
of this widget:
1) Supply *only* the methods whose internal logic is unique
2) Supply #1, plus anything 'convenient' to average use
3) Supply all methods from all widgets, except any that
overlap. eg. implement wrappers for methods like popup(),
I opted for #1, because it was clear when to stop
writing methods. (It was also easiest to stop there ;)
But sounds like you think #2 is the best way to go..?
If so, how do I know when to stop writing methods?
eg. do I stop at clear/add/size/value, or should I
also do popup(), textfont(), etc?
In other words, not sure where to draw the line between
what is a 'convenience method', and what is 'too specific
or obscure to bother with'.
I can make guesses, but I suppose I'd always be wrong
to somebody ;)
Is there a clear way to decide what to implement and what not?
14:18 Feb 06, 2005
I've made changes to your implementation and would like you to approve them before I add it to FLTK proper; aside from adding methods to allow manipulation of the value and menu and renaming things, I also changed the input field box type to always be FL_FLAT_BOX and updated the header to conform to the current CMP documentation and coding standards.
If you approve of the changes, I'll add it to the 1.1.7 release.
14:19 Feb 06, 2005
|Let's try that again... ||
14:27 Feb 17, 2005
|> I've made changes to your implementation and would like you to approve |
> them before I add it to FLTK proper
Just getting to this now.. will check.
15:02 Feb 17, 2005
|I like your mods -- good changes I think. |
I've attached a modified test program (input_choice.cxx)
which I used to verify its operation. This might be useful
to include in the test directory, or some modified version thereof.
13:15 Feb 24, 2005
|Fixed in Subversion repository. |
Also added to FLUID, demo.menu, and documentation...
[ Return to Bugs & Features ]