Re: [fltk.general] Manage focus with Suggestions popup/win/menu
On 2013.01.15, Albrecht wrote: (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. Thanks for pointing out to not use parent(Fl_Group *) directly. I haven't done that anywhere else, but at least now I know not to (!). I hacked out a solution to the z problem (remove the popup window from its parent/group, then add it to top window; this puts it last/top in sort order), but I was getting a bit frustrated with the idea altogether and digressed to some other work. I'll return to this one and try out the above. Thanks again for the continued feedback - I'll post whatever works in the end! DLT ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
[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
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
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...? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Manage focus with Suggestions popup/win/menu
Hi, all -
I am trying to create a little widget/group made of an Fl_Input (or text
editor) and a drop-down-menu-like suggestions box. The end goal is to make
something similar to an AJAX-y suggestions box found on google, or the firefox
sites suggestions, etc.
It's easy for me to create/fill/show a popup made of an Fl_Select_Browser
inside an Fl_Menu_Window. If I use an Fl_Menu_Window, though, show() steals
focus and the mouse cursor from my Fl_Input widget. I can't send back focus
because the menu is a new window ... or at least I haven't figured out how to
send it back ... ?
In short, I have something like the pseudo-code below. I'm happy to post my
full test/draft if that helps.
Maybe someone else has been through this before?
Denton
// a 'drop down or popup' box with suggested text completions
class SuggestionsBox : public Fl_Menu_Window {
Fl_Select_Browser *browser_; // ideally ...
int handle(int event) {
}
class SuggestionsInput : public Fl_Input {
..
Fl_Input *input_;
... etc etc ...
browser_cb_() {
// when user clicks a browser item, add to input_
// then, hide browser_
}
int handle(int event) {
// on keypress, take input_-value() as prefix.
// search db/tree of terms, put those into browser_.
// show browser_.
}
public:
InputWithSuggestionsBox(..) {
// always display input_
Fl_Group::end();
win_ = new Fl_Menu_Window(...)
browser_ = new Fl_Select_Browser(...)
browser_-callback(browser_cb_, this)
win_-end();
... etc
}
// etc etc
};
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
I am trying to create a little widget/group made of an Fl_Input (or text editor) and a drop-down-menu-like suggestions box. The end goal is to make something similar to an AJAX-y suggestions box found on google, or the firefox sites suggestions, etc. It's easy for me to create/fill/show a popup made of an Fl_Select_Browser inside an Fl_Menu_Window. If I use an Fl_Menu_Window, though, show() steals focus and the mouse cursor from my Fl_Input widget. I can't send back focus because the menu is a new window ... or at least I haven't figured out how to send it back ... ? In short, I have something like the pseudo-code below. I'm happy to post my full test/draft if that helps. Maybe someone else has been through this before? Without actually thinking about your problem much (or indeed at all!) my initial reaction is that Fl_Menu_Window is the wrong way to go (menu windows tend to grab, and that is *not* what you want!) I think you'd be better off just popping up a regular Fl_Double_Window with your controls in it, then setting that popup window to non-modal, which will cause it to stay on top of your main window, but *not* grab the focus (though it may take the focus when it pops up, it will not grab it, so you should be able to give it back to your main window...) Also, I think setting the popup window non-modal will usually also remove the window decorations (may depend on how your window manager behaves though I suspect!) so it will look much like a menu window would... This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
Sorry - I was a bit trigger-happy with the send button. Pseudo-code
updated/finished:
In short, I have something like the pseudo-code below. I'm happy to post my
full test/draft if that helps.
Maybe someone else has been through this before?
Denton
// a 'drop down or popup' box with suggested text completions
class SuggestionsBox : public Fl_Menu_Window {
Fl_Select_Browser *browser_; // ideally ...
public:
SuggestionsBox(...) : Fl_Menu_Window( ... ){
create browser_;
end();
}
...
etc.
}
// input box that displays suggested completions as dropdown/popup
class SuggestionsInput : public Fl_Input {
...
Fl_Input *input_;
SuggestionsBox *browser_;
... etc etc ...
browser_cb_() {
// when user clicks a browser item, add to input_
// then, hide browser_
}
int handle(int event) {
// on keypress, take input_-value() as prefix. Use client fxn
// to search db/tree of terms, send those to browser_.
// show browser_ just below this input, but keep
// focus in the text input.
}
public:
InputWithSuggestionsBox(..) {
// always display input_
Fl_Group::end();
browser_ = new SuggestionsBox(...);
browser_-callback(browser_cb_, this);
... etc
}
// etc etc
};
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
Sorry - I was a bit trigger-happy with the send button. Pseudo-code
updated/finished:
In short, I have something like the pseudo-code below. I'm happy to post my
full test/draft if that helps.
Maybe someone else has been through this before?
Denton
// a 'drop down or popup' box with suggested text completions
class SuggestionsBox : public Fl_Menu_Window {
Fl_Select_Browser *browser_; // ideally ...
public:
SuggestionsBox(...) : Fl_Menu_Window( ... ){
create browser_;
end();
}
...
etc.
}
// input box that displays suggested completions as dropdown/popup
class SuggestionsInput : public Fl_Input {
...
Fl_Input *input_;
SuggestionsBox *browser_;
... etc etc ...
browser_cb_() {
// when user clicks a browser item, add to input_
// then, hide browser_
}
int handle(int event) {
// on keypress, take input_-value() as prefix. Use client fxn
// to search db/tree of terms, send those to browser_.
// show browser_ just below this input, but keep
// focus in the text input.
}
public:
InputWithSuggestionsBox(..) {
// always display input_
Fl_Group::end();
browser_ = new SuggestionsBox(...);
browser_-callback(browser_cb_, this);
... etc
}
// etc etc
};
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
On 11.01.2013 14:27, Denton Thomas wrote: I am trying to create a little widget/group made of an Fl_Input (or text editor) and a drop-down-menu-like suggestions box. The end goal is to make something similar to an AJAX-y suggestions box found on google, or the firefox sites suggestions, etc. It's easy for me to create/fill/show a popup made of an Fl_Select_Browser inside an Fl_Menu_Window. If I use an Fl_Menu_Window, though, show() steals focus and the mouse cursor from my Fl_Input widget. I can't send back focus because the menu is a new window ... or at least I haven't figured out how to send it back ... ? As Ian wrote, I'm also not sure if Fl_Menu_Window is the best solution, but maybe this doesn't matter. I solved a similar, but different issue, and the best I can do is to describe what I've done to solve it. My problem was similar to FLTK's Fl_Choice widget. I have an input widget and another box (the usual one with the small triangle used to open that suggestion window). The user must click on the triangle box to open the suggestion window. My window is derived from Fl_Double_Window, but I also use set_override() to make it borderless, like Fl_Menu_Window. That's why I think that the window type wouldn't matter. Additionally I use Fl::grab() to make the suggestion/menu window take all events when it is opened. That's like a menu window, and steals focus from the input widget as you describe with your solution. But then, well, why would you need to give the focus back to the input widget? You don't need to do that if your handle() method of the window or its embedded browser widget has the focus (see Fl::grab()) and handles the input. It's some work, but you can do everything you like ... Add one character at a time to your input widget and update the browser widget whenever a key is pressed (FL_KEYBOARD event), put the selected value into the input widget's value() whenever a browser item is selected, and so on. The only problem I see with this approach is that the input widget indeed doesn't have the focus, and thus doesn't give much visible feedback like a cursor to show the current point of input. You may want to derive your own input class as well and make your own draw() method to show a cursor if you go that route. Maybe... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
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 ...
Denton
---
/** \file main.cpp
creating a suggestions drop-down box
CHANGES
- dentonlt, jan 2013: original version
*/
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Group.H
#include FL/Fl_Input.H
#include FL/Fl_Button.H
#include FL/Fl_Select_Browser.H
#include FL/names.h
class SuggestionBox : public Fl_Window {
Fl_Widget *anchor_;
Fl_Select_Browser *browser_;
static void static_browser_cb_(Fl_Widget *src, void *dat) {
if(!src || !dat) printf(SuggestionBox::browser_cb_ rec'd NULL arg.\n);
else ((SuggestionBox *)dat)-browser_cb_(src, dat);
}
void browser_cb_(Fl_Widget *src, void *dat) {
// hack!
printf(SuggestionBox::browser_cb_ runs\n); fflush(stdout);
set_changed();
hide();
}
int handle(int event) {
//printf(SuggestionBox::handle() ran with event %s\n,
fl_eventnames[event]);
int ret = Fl_Window::handle(event);
if(changed()) {
clear_changed();
if(callback()) do_callback();
}
return ret;
}
public:
SuggestionBox(int X, int Y, int W, int H, const char *n = NULL) :
Fl_Window(X, Y, W, H, n) {
anchor_ = NULL;
browser_ = new Fl_Select_Browser(0, 0, W, H);
browser_-callback(static_browser_cb_, this);
// mock 'selection' data
browser_-add(red);
browser_-add(read);
browser_-add(reed);
browser_-add(regurgitate);
Fl_Window::end();
//clear_border();
//set_non_modal(); // stay on top, do not capture events
}
Fl_Select_Browser *browser() { return browser_; }
void anchor(Fl_Widget *a) { anchor_ = a; }
};
class SuggestionInput : public Fl_Input {
SuggestionBox *browser_;
static void static_browser_cb_(Fl_Widget *src, void *dat) {
if(!src || !dat) printf(SuggestionInput::browser_cb_ rec'd NULL arg.\n);
else ((SuggestionInput *)dat)-browser_cb_(src, dat);
}
void browser_cb_(Fl_Widget *src, void *dat) {
// hack!
printf(SuggestionInput::browser_cb_ runs\n); fflush(stdout);
value(browser_-browser()-text(browser_-browser()-value()));
browser_-hide();
}
void post_suggestions_() {
printf(SuggestionInput::post_suggestions_() runs\n); fflush(stdout);
if(browser_-parent()) browser_-position(x(), y() + h());
//else browser_-position(Fl::first_window()-x() + x(),
Fl::first_window()-y() + y() + h());
browser_-show();
browser_-redraw();
}
int handle(int event) {
int ret = Fl_Input::handle(event);
if(changed()) {
clear_changed();
if(value()) post_suggestions_();
if(callback()) do_callback();
}
return ret;
}
public:
SuggestionInput(int X, int Y, int W, int H, const char *n = NULL) :
Fl_Input(X, Y, W, H, n) {
browser_ = new SuggestionBox(0, 0, W, 80);
browser_-callback(static_browser_cb_, this);
browser_-hide();
browser_-anchor(this);
// try both with without ...
//if(browser_-parent()) browser_-parent(NULL);
}
~SuggestionInput() {
printf(SuggestionInput::dtor runs\n); fflush(stdout);
delete browser_;
}
};
void button_cb_(Fl_Widget *, void *) {
printf(button_cb_ ran.\n); fflush(stdout);
}
int main (int argc, char ** argv)
{
Fl_Window *window;
Fl_Input *input;
Fl_Button *button;
window = new Fl_Window (600, 300);
// if I create 'button' here, then it is 'under' the popup.
input = new SuggestionInput(10, 10, 200, 35);
// creating button here hides input from previously inserted widgets
button = new Fl_Button(10, 45, 200, 35, nothing); // this masks input
into the popup ...
button-callback(button_cb_, NULL);
window-resizable(NULL);
window-end ();
window-show (argc, argv);
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
