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
Can we patch to free these two char ** malloc'd by Xlib? About a year or so
ago, Ian (?) had suggested I just not worry too much about any unfree'd buffers
in this particular area.
This is not a serious problem, but now I'm back to using Valgrind to track some
of my own code. Patching would
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
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
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
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
No, sorry for being unclear. It's solely to detect that the current
focus_tracker_ variable value is invalid. This would enable you to
see when the current focus widget (inside your group) loses focus
and gets it again. Otherwise you wouldn't scroll the widget back
into the visible area in
Albrecht wrote:
What about adding here:
if (!contains(f_new)) focus_tracker_ = 0; // focus in another group
if(f_new (f_new != focus_tracker_) contains(f_new)) {
focus_tracker_ = f_new; // focus_tracker_ = NULL in ctor
scroll_to(scroll_to_focus_x_(),
All,
I'd like to know if there are more FLTK users who have the need
to track the widget that currently has the focus. If this was a
common problem, we could probably add something to FLTK to make
this easier. It's not easy with current FLTK methods, as can be
seen in the current discussion
Albrecht wrote:
Oh, yes, that's certainly true. If navigation happens to
succeed in a subgroup, then this subgroup does it all. No
parent group will notice. You could maybe derive an own
Fl_Group class to do this in conjunction with its parent
YourScroll class, but this could be a never
Albrecht wrote:
It's not perfect, and maybe some of the changes would turn out
to be useless... just take it as a base for more own experiments.
Thanks for all this, Albrecht. I'll certainly use those immediately. I
appreciate it, as this is part of a current project.
I'll keep testing re
On 02.01.2013 13:14, Albrecht Schlosser wrote:
..
Fl_Widget *fw = Fl::focus(); // save focus widget
int ret = Fl_Scroll::handle(event);
if (ret fw != Fl::focus) { // event used and focus changed
..
Albrecht
Thanks for all this, Albrecht. I started mucking with an Fl_Scroll
Ian wrote:
Ah, but there's a thought... If Denton has already modified his widgets =
to handle the focus differently, then they may perhaps be eating the =
nav events, thus preventing them from propagating to the container =
scroll widget at all?
I may have done that, yes. Have to go back
Thanks for that, Ian.
My thinking is that this *should* work and would mean that only one special
derived widget is needed, rather than having to make every contained widget
be a special widget.
Yep, I agree. I've just made a template to add the handlers to any old widget,
but it seems
Hi, All -
Perhaps this has been asked before, but I couldn't find it in the forums. A RTM
link would be great ... !
I have an Fl_Scroll with many widgets (buttons, text displays, etc). If I tab
through those widgets, I will eventually change focus to a widget that is in
the scroll group but
Fl_Text_Editor normally accepts the tab key. I think there's a way to allow tab
navigation (not ctrl-tab; I'd really like just tab to navigate) but I can't
find that in the docs.
Eventually, I'll also like to modify how the editor handles the return/enter
key.
For these problems, I need to
undefined reference to `Fl_PNG_Image::Fl_PNG_Image(char const*, unsigned char
const*, int)'
I checked the Fl_PNG_Image source file and it's not there. I'd be very
surprised if it were elsewhere in the code.
In r8507, I have that at line 105 in Fl_PNG_Image.cxx.
Perhaps a linker error - is
Ok - word wrap works, just not in the way I expected.
If there are spaces in a line, then word wrap will break the line at a space
(insert a newline at a space). If there are no spaces in a line, however,
word wrap will not insert a newline, even if the text length is longer than
the
I am having trouble wrapping in a multiline input. The stock test/input program
does not wrap, and my test doesn't either (below).
I need to create a multiline input, set its type() to FL_MULTILINE_INPUT and
wrap(1), right?
I'm wondering if there is something not working in
about, reading manuals. Suggestions still welcome.
DLT
On 08.04.2011 15:38, Denton Thomas wrote:
I am having trouble wrapping in a multiline input. The stock test/input
program does not wrap,
it does for me
and my test doesn't either (below).
It does for me, too.
I need to create
On 08.04.2011 16:34, Denton Thomas wrote:
Sorry: 1.3, r8570; and yep - just includes as you listed.
Thanks for the confirmation. I must be doing something in my library build
that breaks this, then. I've tried re-enabling xft, but no good.
FYI, I am using:
GCC 4.4.3
Autoconf
On 08.04.2011 16:34, Denton Thomas wrote:
Sorry: 1.3, r8570; and yep - just includes as you listed.
Thanks for the confirmation. I must be doing something in my library
build that breaks this, then. I've tried re-enabling xft, but no good.
FYI, I am using:
GCC 4.4.3
On 15/01/11 09:50, Denton Thomas wrote:
I should have suggested removing a couple lines, however -
XFree() must happen at the end of fl_init_xim() whether or not the
if condition fails at 564, so the new/final XFree() call is basically
replacing line 567. I suggest we cut the XFree
On 17.01.2011 11:42, Denton Thomas wrote:
Will do. I can't get the weekly (8276) for a test right now, though - looks
like the domain is in transition ... and caught due to MLK day.
It's working (again) for me. There were DNS problems last Saturday,
but they are fixed at least since
On 14/01/11 13:22, Denton Thomas wrote:
Agreed, setting to NULL at declaration is pointless! Line 546 is
fine.
Also agreed that it is smart to check xim_styles before use, and to
set it to NULL after. The xlib doc does not specify whether XFree
will or won't set incoming values
Sorry - Neglected to mention:
FLTK 1.3.0rc3-8207 (current)
gcc 4.4.3
Linux (tinycore 3.4.1)
Valgrind-ing, I believe I found the source of a leak in Fl_x.cxx.
fl_get_font_xfld() malloc's and returns a char * to fl_new_ic(), but the
latter does not free this space. From what I can tell,
Using: fltk-1.3.x-r8276 / Linux 2.6.33.3 (tinycore) on i686 / gcc 4.4.3
Found via Valgrind and a one-button hello program. In Fl_x.cxx, fl_init_xim()
allocates an XIM object using a call to libx11. fl_init_xim() only deallocates
that object in some cases, rather than in all. It looks like the
fltk-1.3.x-r8276 / Linux 2.6.33.3 (tinycore) on i686 / gcc 4.4.3
find_best_font() keeps a static pointer to the list of font names provided by
libx11. find_best_font() frees and then re-queries that list from libx11 every
time find_best_font() is run. At program termination, that list cannot be
Found via Valgrind and a one-button hello program. In=20
Fl_x.cxx, fl_init_xim() allocates an XIM object using a call=20
to libx11. fl_init_xim() only deallocates that object in some=20
cases, rather than in all. It looks like the object is not=20
needed after fl_ini_xim(), so it should
Hmm, you have turned off XFT in your build, then? You get much nicer
looking text display if you leave XFT enabled in 1.3...
find_best_font() keeps a static pointer to the list of font=20
names provided by libx11. find_best_font() frees and then=20
re-queries that list from libx11 every
30 matches
Mail list logo
