STR #650

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.1 ]

STR #650

Application:FLTK Library
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
Subsystem:Core Library
Summary:Suggested new widget: Fl_Input_Choice
Created By:greg.ercolano
Assigned To:mike
Fix Version:1.1.7 (SVN: v4050)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 greg.ercolano
15:11 Dec 13, 2004
#2 mike
14:18 Feb 06, 2005
#3 mike
14:19 Feb 06, 2005
#4 greg.ercolano
15:03 Feb 17, 2005
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#1 greg.ercolano
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.

#2 greg.ercolano
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.
#3 mike
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.
#4 greg.ercolano
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?
#5 mike
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.

#6 mike
14:19 Feb 06, 2005
Let's try that again...  
#7 greg.ercolano
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.
#8 greg.ercolano
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.
#9 mike
13:15 Feb 24, 2005
Fixed in Subversion repository.

Also added to FLUID,, and documentation...
bottom left image   bottom right image

Return to Bugs & Features ]


Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.