| |
27.03.2007 imm <ian-U2aaWHWG7rTnLLbYC8q3ug@public.gmane.org> 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.
[ Direct Link to Message ] | |
