Stan wrote:
> First of all, I want to thank the group for being so helpful,
> and putting up with my dumb questions.
> 
> What I'm trying to do now is put together a pop-up
> calendar for date input.  The idea is that the user
> clicks a symbol to pop up a little calendar, then
> clicks a box on the calendar, causing a date to be
> transferred into a text box on the main window,
> and the popup to be dismissed.
> 
> You've seen it on a million websites, I'm sure.
> 
> I want the popup to be anchored to the main window
> at a spot of my choosing.  I'd like to be able to
> pop up more than one of these things at a time.  I'd
> like to have keyboard navigation enabled inside the
> popup.
> 
> I've got the guts of the little calendar worked out,
> but I'm having trouble with the top level design. Would
> you suggest a separate window?  A sub window?  An overlay?
> 

     There will probably be several responses, but my choice
     I think would be either a separate modal window, similar
     to a file chooser.

     If you intend to have several open, that gets messy for
     the user.

> I'd like to be able to pop up more than one of these things
> at a time.

     That might kill the modal idea.

     Most of the airline sites I just sampled (aa.com and southwest.com)
     don't let you have more than one calendar open, to prevent a shell
     game of windows.

     If you do allow several at once, be sure to label() the windows
     clearly so the user knows which is which. If you make the modal
     operation an option in your calendar widget, you can choose later.

> I'd like to have keyboard navigation enabled inside the popup.

     That should be automatic; FLTK already does keyboard nav
     for normal widgets that expect input (Fl_Input, Fl_Button, etc).
     So if all the days in your calendar are an Fl_Group of Fl_Buttons,
     that should work automatically.

> And, as the subject line suggests, what's the preferred
> way of communicating a result back to the main window

     There are many ways to do it, but the 'cleanest' is to follow
     the same techniques FLTK itself uses; use a callback() in your widget.

     So in the main window when you create an instance of your calendar
     widget, you also register a callback to the main app to handle when
     the user hits the 'OK' button. eg:

       [..]
       depart_calendar = new MyCalendar(..);
       depart_calendar->callback(DepartCalendarOK_CB, (void*)this);
       [..]

     ..and the DepartCalendarOK_CB() function expects a pointer to the
     calendar widget, and the 'user data', similar to a regular FLTK callback.
     That way your callback can access both the main window and child widget
     to move data from one to the other.

> and dismissing the child?

     Just hide() the widget.

     Either have it be automatic when the user hits OK or Cancel,
     or have it be something your 'OK Callback' has to call to hide it.
     (so as to do error checking, forcing the user to have to respecify)

_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk

Reply via email to