[sorry, if this is a double post - I clicked the wrong send button]
On 13.01.2013 19:22, Ian MacArthur wrote:
>
> On 12 Jan 2013, at 03:17, Denton Thomas wrote:
>
>> Using Fl_Window (Fl_Double_Window) + set_non_modal() is definitely easier,
>> and does not hog input. Thanks for mentioning that, Ian.
>>
>> New problem, though. Test code is below.
>>
>> Regardless of what group/win type I use, mouse input will pass through the
>> popup to the window/widgets below. This acts like an insertion-order thing.
>> So, widget is drawn z-top, but it is z-below for input. I can "fix" the
>> input order by making sure the other widget additions occur before the
>> suggestion box.
>>
>> In my project, though, I can't control/guarantee the insertion order of the
>> widget into the parent group ... so I'm a bit stumped.
>>
>> Ideas? I'll keep reading docs/threads ...
>
> (Without studying the sample code in all that much detail..) my initial
> reaction is that the creation of the Fl_Window based SuggestionBox widget as
> a member of your SuggestionInput widget, is causing it to be created as a
> sub-window of the main window, rather than a window "in its own right" and
> this is messing with the behaviour of the other widgets.
>
> If you can put the SuggestionBox browser in a pop-up window, rather than
> putting the pop-up windows inside the SuggestionBox, things might be simpler
> and make it easier to control the ordering of windows / events / etc...?
Yes, I agree that the code seems to arrange the suggestion window as
a subwindow, since there is a parent group existing *at the time of
window creation*. Maybe there are also platform-dependent differences
concerning the arrangement of windows at the time of the window's first
show(), but anyway - keeping it clean is the best.
@Denton:
It can be done easily in the current SuggestionInput constructor, if
you don't want to change much code, like this (see comments below):
public:
SuggestionInput(int X, int Y, int W, int H, const char *n = NULL) :
Fl_Input(X, Y, W, H, n) {
Fl_Group *current_group = Fl_Group::current(); // add (1)
Fl_Group::current(0); // add (2)
browser_ = new SuggestionBox(0, 0, W, 80);
Fl_Group::current(current_group); // add (3)
browser_->callback(static_browser_cb_, this);
browser_->hide();
browser_->anchor(this);
// try both with & without ...
//if(browser_->parent()) browser_->parent(NULL);
}
(1) saves the current group, which would otherwise become the window's
parent group.
(2) resets the current group before window creation
(3) reverts (2).
Sorry, I don't have the time to do my own tests, so please try this
and tell us, if it changes the behavior.
Note that simply setting "browser_->parent(NULL);" is a *really BAD*
idea, since this MUST NOT BE USED in user code (see the docs).
Unfortunately this method exists, although it really should not exist
at all, but it's used for some special internal "hacks".
<http://www.fltk.org/doc-1.3/classFl__Widget.html#a6b57ff665a0e988064cb42d742668566>
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
