Funny behaviour of file_chooser

[szuk...@arcor.de]

I have written an FLTK program that shows a JPM file using Fl_Button
widgets to navigate.

This program I have changed now: it uses an Fl_Tree to navigate.

With WIN7 using VS Community 2015 that program works as expected.
With LINUX it does not.

The FLTK version is fltk-1.4.x-r12283. I use CMAKE to compile the
library and the program.

The tree window is shown on the left, the image window is shown
on the right.

On start the tree is shown. Clicking on a leaf of the tree shows
the respective image in the image window.

But when I open the Fl_Native_File_Chooser (or an fl_file_chooser)
a puzzling event happens with LINUX. The chooser window does not
appear but an 'image' of the window with no window borders.

Clicking on a widget is useless. But the files shown can be scrolled.
When I press the RETURN button the ('image' of the) file_chooser
disappears. Sometimes - after pressing the RETURN button - the normal
file_chooser appears.

I have never seen such a funny behaviour with LINUX and FLTK.

winfried

[szuk...@arcor.de]

 With fltk-1.4.x-r12292 the behaviour is more funny. With WIN7 using VS Community 2015
I get the following: when I open the file the Fl_Tree is seen and can be selected; but when
I now open the file_chooser window and cancel it, the tree is blocked.

I would say that there is broken something with the library.

winfried

[szuk...@arcor.de]

The Fl_Tree is broken in fltk-1.4. I have now compiled the image program with fltk-1.3: no problem with LINUX.

winfried

[imm]

Winfried,

Can you post a minimal, compileable, example showing what you are
doing that triggers the failing behaviour, please?

I'm not clear, from your description, where you are showing the file
chooser from, or what the widget hierarchy is at the point of failure,
and I think that may be critical to this bug.

Cheers,
--
Ian

[Albrecht Schlosser]

On 09.07.2017 08:44 Winfried (szukw000@...) wrote:

> The Fl_Tree is broken in fltk-1.4. I have now compiled the image program
> with fltk-1.3: no problem with LINUX.

I think your conclusion is not entirely clear. There may well be a bug
in your program (e.g. writing to released memory) that can manifest
differently (or not at all) on different platforms or with different
FLTK versions.

I suggest to run your program on Linux with valgrind to see if there are
some useful warnings or valgrind detects illegal memory access or such.

The main reason why I suspect the bug in your program is that you wrote
there's a behavior difference between fltk-1.4.x-r12283 and
fltk-1.4.x-r12292. I checked the commit diffs between these versions and
I can't find any clue as to what may have caused different behavior in
the way described by you.

If you can't find a bug with valgrind, please try to reduce you program
to a minimal example as Ian suggested already.

[szuk...@arcor.de]

 In the meantime I have installed VS Community 2017.

C:\Users\szukw000\APP\FLIMAGE\flimage-fltk13-source-1.13.0-tree\READ_JPM.cxx:4210: JPM_read_file jpm(0000000000000000)

The tree of the JPM files is built and is visible.
I click on a tree leaf, an image is shown.

When I now open the file_chooser:

free_jpm jpm(000000013F23B6F0)
free_jpm jpm->pcol_table(00000000003F1E50)
free_pagt_table ne(5)
free_pagt_table sec_jpm(00000000003F2650)
free_jpm jpm(00000000003F2650)
free_jpm jpm->pcol_table(00000000003F25B0)
free_pagt_table ne(6)
free_pagt_table sec_jpm(00000000003F5080)
free_jpm jpm(00000000003F5080)
free_jpm jpm->pcol_table(00000000003F4FE0)
free_pagt_table ne(8)
free_pagt_table sec_jpm(00000000003FA8C0)
free_jpm jpm(00000000003FA8C0)
free_jpm jpm->pcol_table(00000000003F88F0)
free_pagt_table ne(5)
free_pagt_table sec_jpm(0000000000405750)
free_jpm jpm(0000000000405750)
free_jpm jpm->pcol_table(00000000003F8990)
free_pagt_table ne(9)
free_jpm jpm(0000000000000000)

Result:Opening the file_chooser clears the tree.

Using fltk-1.4.x-r1229 with LINUX does not (always) work.

Using fltk-1.3.4-1 with LINUX does always work:

READ_JPM.cxx:4210: JPM_read_file jpm((nil))

The tree of the JPM files is built and is visible.
I click on a tree leaf, an image is shown.

Nothing happens when I open the file_chooser.

winfried

[szuk...@arcor.de]

The problem with WIN7 has been solved. The browse_cb, that opens
the file_chooser, contained the lines:

#ifdef _WIN32
    if(canvas->cleanup)
   {
    canvas->cleanup();
    canvas->cleanup = NULL;
   }
#endif //_WIN32

The cleanup() always clears the tree :-(
I have removed that code for WIN32. With WIN32 the program does work
now with fltk-1.3.4-1 and fltk-1.4.x-r12292.

LINUX does work with fltk-1.3.4-1 but not (always) with fltk-1.4.x-r12292.

The main window is an Fl_Overlay_Window containing the Fl_Tree on the left
and an Fl_Scroll on the right. On the Fl_Scroll I can draw a frame. When
I press the CROP button, an Fl_Double_Window opens and shows that image
within the drawn frame.

With fltk-1.4.x-r12292 I have found that the first cropped image is
shown in a frameless window. Exiting that window and immediately pressing
the CROP button again then shows the cropped image in a window with frame.

After the first frameless window or the second framed window I can press
the BROWSE button and the file_chooser shows up in a framed window.

But without a CROP window the file_chooser remains broken on LINUX with
fltk-1.4.x-r12292.

What is wrong here?

winfried

[Greg Ercolano]

On 07/13/17 09:35, szuk...@arcor.de wrote:
> The problem with WIN7 has been solved. The browse_cb, that opens
> the file_chooser, contained the lines:
>
> #ifdef _WIN32
> if(canvas->cleanup)
> {
> canvas->cleanup();
> canvas->cleanup = NULL;
> }
> #endif //_WIN32

Hmm, where is this code, exactly?

I can't see it in 1.4.x, and I haven't seen any replication
code here, so I can't follow.

> The cleanup() always clears the tree :-(

What is 'canvas'? What code is in 'cleanup()'?

I don't think in fltk we have a method called cleanup(),
so this must be in your own code which I don't think has been posted.
(Or at least not in this thread? Or am I missing a post somehow?)

> I have removed that code for WIN32. With WIN32 the program does work
> now with fltk-1.3.4-1 and fltk-1.4.x-r12292.
>
> LINUX does work with fltk-1.3.4-1 but not (always) with fltk-1.4.x-r12292.
>
> The main window is an Fl_Overlay_Window containing the Fl_Tree on the left
> and an Fl_Scroll on the right. On the Fl_Scroll I can draw a frame. When
> I press the CROP button, an Fl_Double_Window opens and shows that image

> within the drawn frame. [..]
>
> What is wrong here?

This all seems to describe a program I haven't seen..
was code posted in some other thread?

I must be missing something; can't weigh in on a program
whose code I haven't seen.

I believe Ian requested this, and I concur; you'd have to
post a small compilable program, and describe how to run
it to replicate.

[szuk...@arcor.de]

@greg, @ian, @albrecht,
it is impossible to offer 'a small compilable program':

 91398 Jul 13 16:28 READ_JPM.cxx
 27762 Jul  6 18:30 JP2.cxx

But the difference between 1.3.4-1  and 1.4.x-r12292 is obvious: each library creates a program
that is different from the other.

The program with fltk-1.3.4-1 works as expected with LINUX.

The program with fltk-1.4.x-r12292 does not work as expected. I suppose the Fl_Overlay_Window
to be the reason. When I call ' flimage file.jpm' the tree is shown. The program has a Popup Menu.
When I activate the popup menu, the menu 'touches' the main window that is an Fl_Overlay_Window.
When I click the popup menu away the program from now on works as expected.

This trick is not necessary for fltk-1.3.4-1 with LINUX.

winfried

[Greg Ercolano]

On 07/13/17 21:20, szuk...@arcor.de wrote:
> @greg, @ian, @albrecht,
> it is impossible to offer 'a small compilable program':
>
> 91398 Jul 13 16:28 READ_JPM.cxx
> 27762 Jul 6 18:30 JP2.cxx

I don't see how the size of your application prevents you from
creating a simpler compilable program that demonstrates the problem.

What you describe is an app that has a tree and an image viewer,
clicking each item on the tree shows a different image in the viewer.

Here's a small program (you could have written) that does that
to get you started.

I don't know what a JPM file is, so I've substituted a JPEG reader
in its place.

This assumes 3 files named a.jpg, b.jpg and c.jpg exist,
and are around 300x150 or so in size. It can be compiled with:

fltk-config --use-images --compile foo.cxx

Click on the 3 different items in the tree to show the 3 images.

What I'm not sure about is how you're bringing up a file browser,
as the tree is kind of being a browser.

So I leave it to you to add that code to this program, and try to
demonstrate the problem with this reduced code. Perhaps in doing
so you can solve the problem you're having.

[Albrecht Schlosser]

On 14.07.2017 06:20 szuk...@arcor.de wrote:
> @greg, @ian, @albrecht,
> it is impossible to offer 'a small compilable program':

You mentioned 'flimage' and I found this link (and article) posted by you:

http://www.fltk.org/links.php?V396

Is your program open source?

If yes: you could try to post the link to the current code. Maybe
someone might try to test, but it's unlikely that one of us would
inspect code that is too long to view and understand in a short time.

If no: how can the license mentioned in the above article be "FLTK
license". FLTK's license is LGPL with exceptions, which is an open
source license. Please fix the License entry in the listing.

> But the difference between 1.3.4-1 and 1.4.x-r12292 is obvious: each
> library creates a program that is different from the other.

That alone does not mean that it's FLTK's fault. Some time ago I found a
bug (faulty static initialization) in an open source program that worked
with FLTK 1.3 but not with FLTK 1.4. There can be lots of other reasons
that a (faulty) program works with one version of a library and not the
next one because of different memory layout and pointers pointing at
different locations so the program overwrites more or less important
data in random memory and so on...

> The program with fltk-1.3.4-1 works as expected with LINUX.
>
> The program with fltk-1.4.x-r12292 does not work as expected. I suppose
> the Fl_Overlay_Window to be the reason.

Well, although your simple conclusion (above) is not conclusive per se,
this may be the case. Please try the test/overlay program and report
what you see. Is this different in FLTK 1.3 and 1.4? What do you see?

If you see any differences, please tell us which Linux version and which
Window Manager you are using. The WM is an important info in this case.

Note: I *see* some differences (faulty behavior) with different WM's in
my Virtualbox VM setup, but please tell us what you see.

> When I call ' flimage file.jpm' the tree is shown. The
> program has a Popup Menu.
> When I activate the popup menu, the menu 'touches' the main window that
> is an Fl_Overlay_Window.
> When I click the popup menu away the program from now on works as expected.
>
> This trick is not necessary for fltk-1.3.4-1 with LINUX.

I don't think that this description is sufficient for us to test and
find a bug. Please try to work on Greg's demo code and make it more
similar to your program environment until you find some faulty behavior
you can describe and then post that code.


PS: (unrelated) can you please also check and confirm the fix of STR
#3389 that is now in svn r12313 so we can close the STR?
http://www.fltk.org/str.php?L3389

[Albrecht Schlosser]

On 14.07.2017 13:23 Albrecht Schlosser wrote:

> Please try the test/overlay program and report
> what you see. Is this different in FLTK 1.3 and 1.4? What do you see?
>
> If you see any differences, please tell us which Linux version and which
> Window Manager you are using. The WM is an important info in this case.
>
> Note: I *see* some differences (faulty behavior) with different WM's in
> my Virtualbox VM setup, but please tell us what you see.

Meanwhile I tested test/overlay with different WM's, and indeed there
seems to be a bug somewhere related to Fl_Overlay_Window's. What I found
so far:

(1) When the program is started, the small (10x10 px) overlay rectangle
should be visible in the middle of the window. Sometimes (with some
WM's) it is not visible.

(2) When the window is resized, the overlay is redrawn (okay). But I
have seen cases where it disappears when the mouse is released.

(3) When one of the buttons is clicked, the overlay is changed
accordingly (+/- 20 px in the indicated direction) and redrawn. In most
cases it is correctly visible after the mouse is released.

(4) If I type one of the button shortcuts (a, b, c, or d) instead, the
overlay appears shortly, but disappears mostly except where it is drawn
over the button that was clicked. You must enlarge the overlay so it
overlaps the buttons before you can see this. Otherwise it disappears
completely.

Further tests with potentially different/wrong behavior:

(5) hide the window with the window hide (iconify) button and show it
again by clicking on the task bar or whatever.

(6) use ctrl/+/-/0 to change the scaling factor which implicitly does
hide and show.

I didn't see any faulty behavior in FLTK 1.3.4 (Linux) nor in FLTK 1.4.0
under Windows.

So yes, I think there's a problem with Fl_Overlay_Window in FLTK 1.4.0
(svn) under Linux.

[Manolo]

Yes, indeed. Line 49 in function Fl_Overlay_Window::flush()
of file src/Fl_Overlay_Window.cxx in branch 1.3 was not reproduced
completely in branch 1.4. That line is
    int erase_overlay = (damage()&FL_DAMAGE_OVERLAY) | (overlay_ == this);
and its second part   '| (overlay_ == this)' had no equivalent in branch 1.4.
That is now repaired at r.12320 of the repository.
The bug (4) mentionned above disappears.

Albrecht: do you still see other problems?

[Albrecht Schlosser]

Great! Thanks.

> The bug (4) mentionned above disappears.
>
> Albrecht: do you still see other problems?

No, everything seems to be okay now! I tested all points (1-6).

I double checked both old (svn r12319) and new (r12320) executables side
by side with my standard Ubuntu desktop and the Cygwin X server. In both
cases I could see the faulty behavior in the old program, but correct
behavior with the modified code.

I didn't check other WM's though since I could definitely see that the
new code works.

So, if this was the cause of Winfried's observed "funny behaviour" it
might be fixed now.

Winfried, can you test svn r12320 and report whether this solved your
issues?

If you can't access the svn server you can also use our git mirror [1]
or download the entire modified file
src/drivers/X11/Fl_X11_Window_Driver.cxx from [2] or [3]. Use an empty
username and password for the svn server when requested. You can also
download the entire current svn/git distro from [4] as a zip archive.

[1] <https://github.com/fltk/test-only>
[2]
<http://seriss.com/public/fltk/fltk/branches/branch-1.4/src/drivers/X11/Fl_X11_Window_Driver.cxx>
[3]
<https://github.com/fltk/test-only/blob/branch-1.4/src/drivers/X11/Fl_X11_Window_Driver.cxx>
[4] <https://github.com/fltk/test-only/archive/branch-1.4.zip>

[Greg Ercolano]

On 07/14/17 05:24, Albrecht Schlosser wrote:
> (1) When the program is started, the small (10x10 px) overlay rectangle
> should be visible in the middle of the window. Sometimes (with some
> WM's) it is not visible.

For me on linux with flwm + centos 6.x, the red rectangle is visible..
sometimes.

When I run the app, the rect appears.

If I move the mouse out of the window (I use focus-follows-mouse, so window
goes out of focus), the red rectangle disappears. It doesn't return when the
mouse returns. Red rect appears again only if I hit one of the buttons
or resize the window.

But hmm, would these issues be causing the problems the OP described?

That sounded more like the chooser was captured within the window or
some such, as if the new dialog window was opening as a subwindow
instead of a separate top level window. Quoting the OP:

"""
But when I open the Fl_Native_File_Chooser (or an fl_file_chooser)
a puzzling event happens with LINUX. The chooser window does not
appear but an 'image' of the window with no window borders.
"""

But perhaps the file chooser is getting sucked into the overlay
window due to the issue described.

I can't tell anything without replication code; too many missing
pieces from the OP description.

[Albrecht Schlosser]

On 17.07.2017 04:28 Greg Ercolano wrote:
> On 07/14/17 05:24, Albrecht Schlosser wrote:
>> (1) When the program is started, the small (10x10 px) overlay rectangle
>> should be visible in the middle of the window. Sometimes (with some
>> WM's) it is not visible.
>
>
> For me on linux with flwm + centos 6.x, the red rectangle is visible..
> sometimes.
>
> When I run the app, the rect appears.
>
> If I move the mouse out of the window (I use focus-follows-mouse, so window
> goes out of focus), the red rectangle disappears. It doesn't return when the
> mouse returns. Red rect appears again only if I hit one of the buttons
> or resize the window.

I could also see the red rectangle disappear when the window lost focus.
I don't use focus-follows-mouse, but when I clicked on another window
the rectangle disappeared (maybe except where it overlapped the button
that was clicked last). But this was all fixed (for me, i.e. in my
tests) in svn r12320. Greg, did you update your working copy with the
latest svn, or was your report pre-r12320?

> But hmm, would these issues be causing the problems the OP described?

I don't know. I saw similar effects when a window was missing a flush,
and this seemed to be similar to what I saw in the overlay demo - and,
according to Manolo's fix, this was the case here.

> That sounded more like the chooser was captured within the window or
> some such, as if the new dialog window was opening as a subwindow
> instead of a separate top level window. Quoting the OP:
>
> """
> But when I open the Fl_Native_File_Chooser (or an fl_file_chooser)
> a puzzling event happens with LINUX. The chooser window does not
> appear but an 'image' of the window with no window borders.
> """
>
> But perhaps the file chooser is getting sucked into the overlay
> window due to the issue described.

Maybe it's a bit of both? I'm curious what Winfried reports when he
tries the new code...

[Greg Ercolano]

On 07/17/17 08:48, Albrecht Schlosser wrote:
> I could also see the red rectangle disappear when the window lost focus.
> I don't use focus-follows-mouse, but when I clicked on another window
> the rectangle disappeared (maybe except where it overlapped the button
> that was clicked last). But this was all fixed (for me, i.e. in my
> tests) in svn r12320. Greg, did you update your working copy with the
> latest svn, or was your report pre-r12320?

The 1.4.x I have is before your commit (12315).

If I update to latest svn (12322), the problem goes away;
I can't get the red box to disappear unless I make it
too "narrow" or too "short".

[szuk...@arcor.de]

On Wed Jul 19 06:29:16 CEST 2017, I downloaded the test-only-branch-1.4.zip archive.

The 'test/overlay' is OK now.

My program fails as before for 1.4. It succeeds as before after popping up and clicking
away the PopupMenu.

winfried

[Greg Ercolano]

On 07/18/17 21:58, szuk...@arcor.de wrote:
> The 'test/overlay' is OK now.
> My program fails as before for 1.4.

Maybe a screenshot of the bad behavior of your program would be revealing.

Can you provide that, if not a modified version of the small
program I posted?

[szuk...@arcor.de]

I had forgotten to mention the failing WM:

fvwm-2.6
twm
xfce4
fluxbox
mwm with the following message:
 X_GetProperty: BadWindow (invalid Window parameter) 0x40001a

winfried

[Ian MacArthur]

All,

I’m not sure what to look for in the screenshot that Winfried posted, I’m not sure what the failure looks like (and the resolution looks a bit off? At least when I view it here it looks fairly pixelated, like it’s been resampled down at some point...)

Anyway, what I wanted to say was: That clown thing is pretty scary, gave me a fright! What is it?

[chris]

> My program fails as before for 1.4. It succeeds as before after
> popping up and clicking
> away the PopupMenu.

Don't know which popup menu is meant here, I don't see one on the
screenshot. But at least I found a was to produce a situation that is
similar to what can be seen on the screenshot:

When the main window has a pending begin() the file chooser integrates
into the window. But only with FLTK 1.4, not with 1.3!

I just changed Greg's example program for that.

[chris]

Attaching my screenshot.
This is Ubuntu 14.04 with Metacity.

[Albrecht Schlosser]

On 19.07.2017 17:22 chris wrote:
>> My program fails as before for 1.4. It succeeds as before after
>> popping up and clicking
>> away the PopupMenu.
> Don't know which popup menu is meant here, I don't see one on the
> screenshot. But at least I found a was to produce a situation that is
> similar to what can be seen on the screenshot:
>
> When the main window has a pending begin() the file chooser integrates
> into the window. But only with FLTK 1.4, not with 1.3!

Great findings!

> I just changed Greg's example program for that.

Sorry, I don't have time to test right now, but your observation makes
perfectly sense (AFAICT) together with Winfried's statement "It succeeds

as before after popping up and clicking away the PopupMenu."

I *know* that there are some _attempts_ to "repair" missing end()
statements in the code. I *guess* that the menu code has such code that
it uses Fl_Group::current(0) before creating the menu window to avoid
being "sucked into the window" that was missing the end() statement.
After clicking away the menu, there's no "open" Fl_Window anymore, and
the file chooser opens its own stand-alone window.

BTW: this is almost exactly the same effect I mentioned before that made
a program fail (even crash) with FLTK 1.4, whereas it kind "worked" with
FLTK 1.3.4.

@Winfried: please check that your window classes use end(), or -
sometimes even better - use Fl_Group::current(0) at the end of their
c'tors or in the user code after creating the window. [1]

If you can't find such a missing end() [1], please "fix" the issue by
calling Fl_Group::current(0); before starting the file chooser. This
should give a clear indication it Chris' observation applies to your
program as well.


[1] Note that end() maybe doesn't do what one expects. It does the same
as Fl_Group::current(parent()) which "opens" the parent of the group as
the "current" group:
void Fl_Group::end() {current_ = parent();}

[Manolo]

There was indeed an unwanted difference between branches 1.3 and 1.4 in
an Fl_Double_Window constructor, that prevented file choosers
from being constructed as a separate window if a current group was active.

This unwanted diffference is removed with r.12339 of the svn repository.

Does this fixes the "Funny behaviour of file_chooser"?

[Greg Ercolano]

On 07/19/17 07:36, Ian MacArthur wrote:
> I’m not sure what to look for in the screenshot that Winfried posted,
> I’m not sure what the failure looks like

At the right of the image, the file chooser appears to be a subwindow
of his main window.

So instead of the file browser being a dialog in a separate window,
it's become part of the main window.

Sure sounds like the dialog getting absorbed due to make_current()
or a missing end() or some such.

I would focus on making sure the window's current() is set to NULL
before creating the file chooser, to ensure it opens in a
separate window, and doesn't get absorbed by the parent app window.

[szuk...@arcor.de]

You won't believe it.

The original code that did and does not work:

static void browse_cb(Fl_Widget *wid, void *v)
{
    Fl_Native_File_Chooser native;

    native.title("Select Image File");
    native.type(Fl_Native_File_Chooser::BROWSE_FILE);
    native.filter(IMG_PATTERN);
    native.preset_file((read_idf?read_idf:""));

    switch(native.show())
   {
    case -1:
        fprintf(stderr, "FILE_CHOOSER_ERROR: %s\n", native.errmsg());
        break;

    case  1: /* Cancel */
        break;

    default:
        if(native.filename())
       {
        Fl::wait(1);
        chooser_cb(native.filename());
       }
        break;
   }

}

The new code:

static Fl_Native_File_Chooser native;

static void browse_cb(Fl_Widget *wid, void *v)
{
//    Fl_Native_File_Chooser native;

(...)
}

Now I must do something to get rid of the FLTK thing.

winfried

[Greg Ercolano]

On 07/20/17 08:08, szuk...@arcor.de wrote:
> You won't believe it.
>
> The original code that did and does not work:
>
> static void browse_cb(Fl_Widget *wid, void *v)
> {
> Fl_Native_File_Chooser native;
>
> native.title("Select Image File");
> native.type(Fl_Native_File_Chooser::BROWSE_FILE);
> native.filter(IMG_PATTERN);
> native.preset_file((read_idf?read_idf:""));

Going with the idea of a window definition
that didn't include an end(), try keeping the above code,
but adding these two lines at the top of browse_cb:

static void browse_cb(Fl_Widget *wid, void *v)
{

wid->top_window()->begin(); // ADD
wid->top_window()->end(); // ADD

Fl_Native_File_Chooser native;
:

You may only need the end().

Anyway, curious if that helps.

If it does, check the creation of all your windows
and make sure each window definition is end()'ed.
When you create windows, normally you:

win = new Fl_Window(..);
win->begin();
// define other widgets
win->end(); // important

[Albrecht Schlosser]

On 20.07.2017 18:07 Greg Ercolano wrote:
> On 07/20/17 08:08, szuk...@arcor.de wrote:
>> You won't believe it.
>>
>> The original code that did and does not work:
>>
>> static void browse_cb(Fl_Widget *wid, void *v)
>> {
>> Fl_Native_File_Chooser native;
>>
>> native.title("Select Image File");
>> native.type(Fl_Native_File_Chooser::BROWSE_FILE);
>> native.filter(IMG_PATTERN);
>> native.preset_file((read_idf?read_idf:""));
>
> Going with the idea of a window definition
> that didn't include an end(), try keeping the above code,
> but adding these two lines at the top of browse_cb:
>
>
> static void browse_cb(Fl_Widget *wid, void *v)
> {
> wid->top_window()->begin(); // ADD
> wid->top_window()->end(); // ADD

.. or add only this single line instead:

Fl_Group::current(0); // ADD

> Fl_Native_File_Chooser native;
> :
>
> You may only need the end().
>
> Anyway, curious if that helps.

So am I.

> If it does, check the creation of all your windows
> and make sure each window definition is end()'ed.
> When you create windows, normally you:
>
> win = new Fl_Window(..);
> win->begin();
> // define other widgets
> win->end(); // important

@Winfried: I agree with Greg's instructions and you should try to fix
the issue this way to be sure you got everything (i.e. not end()ed top
level windows). This is a chance to fix your program. If you do it, it
should work with FLTK 1.3 as well.

However, you could help the FLTK developers if you *also* updated to
current svn (at least r12339) that *should* fix the issue in FLTK 1.4
and try with your *OLD* code. Note that it's still a bug in your
program, but FLTK 1.4 should behave in the same way as FLTK 1.3 with
this new svn version. Your feedback would be very much appreciated.

TIA

[szuk...@arcor.de]

The following code worked for fltk-1.3.4-1 and for test-only-branch-1.4.zip (Jul 19 23:59) with LINUX:

#ifdef USE_NATIVE_CHOOSER

static void browse_cb(Fl_Widget *wid, void *v)
{
    wid->top_window()->begin();

    wid->top_window()->end();

    Fl_Native_File_Chooser native;
    native.title("Select Image File");
    native.type(Fl_Native_File_Chooser::BROWSE_FILE);
    native.filter(IMG_PATTERN);
    native.preset_file((read_idf?read_idf:""));

    switch(native.show())
   {
    case -1:
        fprintf(stderr, "FILE_CHOOSER_ERROR: %s\n", native.errmsg());
        break;

    case  1: /* Cancel */
        break;

    default:
        if(native.filename())
       {

        chooser_cb(native.filename());
       }
        break;
   }

}
#else

static void browse_cb(Fl_Widget *wid, void *v)
{
    wid->top_window()->begin();

    wid->top_window()->end();

    fl_file_chooser_callback(chooser_cb);

    fl_file_chooser("Select Image File", IMG_PATTERN, read_idf);

    fl_file_chooser_callback(NULL);
}

#endif //USE_NATIVE_CHOOSER

On Friday this week I do tests on the next fltk-1.4.x with LINUX and with WIN7.

winfried

[Albrecht Schlosser]

On 21.07.2017 00:10 szukw000@... wrote:
> The following code worked for fltk-1.3.4-1 and for
> test-only-branch-1.4.zip (Jul 19 23:59) with LINUX:
>
> #ifdef USE_NATIVE_CHOOSER
>
> static void browse_cb(Fl_Widget *wid, void *v)
> {
> wid->top_window()->begin();
> wid->top_window()->end();

Okay, if you downloaded test-only-branch-1.4.zip on Jul 19 at 23:59 from
GitHub, then it should already contain Manolo's fix, and your original
program should work without these two statements. Can you comment them
out and try again, please?

> On Friday this week I do tests on the next fltk-1.4.x with LINUX and
> with WIN7.

The next weekly snapshot fltk-1.4.x-rXXXXX.tar.gz with XXXXX >= 12345
(yes, really: current svn rev. = 12345) will also contain Manolo's fix
and should work with your original program (hopefully). Looking forward
to your test results. Thanks.

[szuk...@arcor.de]

I tested my program with fltk-1.3.4-1 and fltk-1.4.x-r12345 on the
following machines:

LINUX                                  : OK
WIN7 (+ VS Community 2017): OK
RasPi 2 B                             : OK
PPC 64                                : OK

Thank you very much indeed for your help.

winfried