27.03.2007 imm <[EMAIL PROTECTED]> wrote: > Please, if you are going to post examples, make sure they are > complete enough to be compilable... There are too many bits missing > >from your example. I could guess, of course, but that might > inadvertently alter what you are trying to achieve, or otherwise mask > the issues you have... > > Can you post a small, complete, example somewhere? Then people might > be able to advise you further?
Excuse me, but I really don't think there is a need for such tone in your message. Code snippet which I've sent earlier contains all that is related to this particular issue, in fact that's almost all that has to do with GUI. The whole program, that is the rest of the program, which *only* gets data from input and *only* displays output in browser, contains more than several thousands of code lines, so even if it was open source, it wouldn't be practical to post it somewhere, not to mention that it *really* wouldn't help at all with this particular issue. I've partially solved this problem I've had with focus. The problem now is that main window's input box now on start has no focus, but at least once it is focused, focus remains on it. Everything till now confirms that no matter how things are arranged (please look my previous messages on what all have I tried), first call to "browserWindow->show()" makes that (second) window to "steal" focus from main window. Subsequent calls to "browserWindow->show()" (after each "browserWindow->hide()) doesn't "steal" it anymore. So I'll repost *again* that code snippet with some further explanations, so it could hopefully help developers if this is a bug, and if it's not then maybe someone can tell me what the heck is wrong here, but honestly I doubt that mistake is on my side after all I've tried. Once more, everything else, that is omitted from the following code, has no relations to FLTK, graphics and/or this issue: --- Start --- const int WINDOW_WIDTH = 233; const int WINDOW_HEIGHT = 26; const int INPUT_X_POS = 0; const int INPUT_Y_POS = 0; const int INPUT_WIDTH = 170; const int INPUT_HEIGHT = WINDOW_HEIGHT; const int INPUT_COLOR = 79; const char *const INPUT_TOOLTIP = "Some tooltip"; const int BROWSER_WND_WIDTH = 400; const int BROWSER_WND_HEIGHT = 200; const int BROWSER_X_POS = 0; const int BROWSER_Y_POS = 0; const int BROWSER_WIDTH = BROWSER_WND_WIDTH; const int BROWSER_HEIGHT = BROWSER_WND_HEIGHT; class MainWindow : public Window { public: MainWindow(int w, int h, const char *ime, int argv, char **argv, SPI& spi); // spi is some external non-graphical class ~MainWindow() {} // Here are some external non-graphical methods which also // have nothing to do with FLTK private: Input *wordInput; HighlightButton *optButton; Window *browserWindow; Browser *browser; static void cb_mainWindow(Widget *w, void *v) { ((MainWindow *)v)->cb_mainWindow_i(); } inline void cb_mainWindow_i(); static void cb_wordInput(Widget *w, void *v) { ((MainWindow *)v)->cb_wordInput_i(); } inline void cb_wordInput_i(); // ... }; MainWindow::MainWindow(int w, int h, const char *ime, int argc, char **argv, SPI& s): Window(w, h, ime), spi(s) { begin(); wordInput = new Input(INPUT_X_POS, INPUT_Y_POS, INPUT_WIDTH, INPUT_HEIGHT); wordInput->callback(cb_wordInput, this); wordInput->when(WHEN_CHANGED); wordInput->color(INPUT_COLOR); wordInput->tooltip(INPUT_TOOLTIP); optButton = new HighlightButton(OPTION_BTN_X_POS, OPTION_BTN_Y_POS, OPTION_BTN_WIDTH, OPTION_BTN_HEIGHT, ""); optButton->callback(cb_optButton, this); optButton->tooltip(OPT_BUTTON_TOOLTIP); optButton->image(pngImage::get("option_icon.png")); browserWindow = new Window(BROWSER_WND_WIDTH, BROWSER_WND_HEIGHT); browserWindow->begin(); browser = new Browser(BROWSER_X_POS, BROWSER_Y_POS, BROWSER_WIDTH, BROWSER_HEIGHT); browser->column_labels(BROWSER_LABELS); browser->column_widths(BROWSER_COL_WIDTHS); browser->deselect(); browser->color(BROWSER_COLOR); browserWindow->end(); browserWindow->border(false); browserWindow->set_non_modal(); end(); callback(cb_mainWindow); show(argc, argv); // If I don't call show here, with passed "argc" and "argv" from // "main()", then once the "browserWindow" is gone that is when // "wordInput->size() == 0", then it just prints message about // mentioned bug in FLTK and doesn't come back. // This way it still prints message about the bug, but continues to // behave as it should that is "browserWindow" does come back // (gets shown)when "wordInput->size() != 0". browserWindow->child_of(this); browserWindow->resize(0, 0); browserWindow->show(); take_focus(); wordInput->take_focus(); } void MainWindow::cb_mainWindow_i() { exit(0); } void MainWindow::cb_wordInput_i() { int bx, by; by = (y() - BROWSER_WND_HEIGHT > 0 ? y() - BROWSER_WND_HEIGHT : y() + h()); browserWindow->position(x(), by); if (wordInput->size() > 0) { browser->clear(); if (spi.method1(wordInput->value()) == 0) spi.method2(browser); // if previous comparison is true then "browser" widget gets // passed by reference and in with function "method2" by some // criteria calls "browser->add(someCharBuf);" browserWindow->resize(x(), by, BROWSER_WND_WIDTH, BROWSER_WND_HEIGHT); } else { browser->clear(); browserWindow->resize(0, 0); } } int main(int argc, char **argv) { SPI spi; MainWindow win(WINDOW_WIDTH, WINDOW_HEIGHT, "TEST", argc, argv, spi); // ... return run(); } // --- End --- This is really all there is to it. > Anyway, some comments... > > I had the impression from your earlier description that the browser > window was a free floating dialog - yet you seem to be creating it as > a child of your main window? If the browser is entirely within your > main window then surely the separate browserWindow that encloses it > is redundant? No, main window has only input widget, and "browserWindow" holds "browser" widget. Yes, "browserWindow" is floating dialog (separate window, without borders) and yes it is created as main window's child, further more, as you can see in above snippet code, function "browserWindow->child_of(this)" is called to ensure that "browserWindow" is child of main window. Why? Because I would like if for example, main window gets minimized ("browserWindow" has no, title bar and cannot be minimized manually) then also will "browserWindow" get minimized. > If it is intended to be a free floating window in its own right, I > would be inclined to create it as such, and not as a child of the > main window - perhaps that is why you are having issues with handling > the focus? No it's not the reason for such behaviour. Sorry, but it seems that you haven't read my previous messages. Michael Sephton already tried to help by posting demo program similar to what I intend to do, but using FLTK 1.1.x. It was simple enough so I could convert it almost line to line, to FLTK 2.x program and here it is, again: --- Start --- #include <fltk/run.h> #include <fltk/Window.h> #include <fltk/Input.h> #include <fltk/Button.h> using namespace fltk; Window *win; Input *in; Window *ext_win; Input *ext_in; Button *hide_button; void hide_cb(Widget *w,void *d){ if(ext_win->visible()) ext_win->hide(); } void in_cb(Widget *w,void *d){ if(!ext_win->visible()) ext_win->show(); ext_in->value(in->value()); in->take_focus(); }//in_cb int main(void) { win=new Window(0,100,100,30,"window"); win->begin(); in=new Input(0,0,100,30); in->callback(in_cb,0); in->when(WHEN_CHANGED); win->end(); win->show(); ext_win=new Window(0,0,300,50,"extended window"); ext_win->begin(); ext_in=new Input(0,0,300,30); hide_button=new Button(5,35,45,15,"Hide"); hide_button->callback(hide_cb); ext_win->end(); ext_win->hide();//see comment below return run(); } --- End --- Notice that now "floating" window, which in this case has borders but what isn't so important, has been created outside main window, and still it suffers the same issue as mine (previous), that is, after first typed character, and "browserWindow" calls method "show()" for the first time, no matter what is used, focus is on the second window, but if I after that refocus main window and continue typing then focus remains on main window and input in it. > > If there was any doubt about this issue, I hope this will clarify it. > > Not entirely! :-) I really don't mean to be rude or ungrateful, and I appreciate your effort for writing your (constructive) comments, but I simply don't know what more can I say on this matter and thus clarify it further. > I'd guess it will be fixed when it is fixed. If you really need > something that's stable, using s/w that's still in alpha development > may not be your best choice - I suggest fltk-1.1 is a very robust > option for you. If I'm not mistaking, FLTK 2.x branch exists several years now, so it's hardly in ALPHA stage of development. I also must say, without trying to be negative or minimizing the effort developers invest in it, that I really don't understand how after all this time it still hasn't some stable version!? Aside from that, even though FLTK 2.x has better look, more C++ oriented approach (for example all its classes and functions putted in "fltk" namespace)... I still might use FLTK 1.1.x and possibly avoid many issues because after all it is stable, but only if it supported UTF8. Yes I now, that somewhere out there, someone has made some UTF8 patch for FLTK 1.1.6 but I really don't want to rely on that uncertain and outdated work. _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk