#553 Dialog boxes appear in strange places when commander is minimized/hidden

[Manfred Zindel]

Hello, when using the 8pre version I found that modal dialogs like FileRequest are arranged in an unpredictable way, while I expected to see them in the middle of the screen. Very often they appear in the left lower or left upper corner. Is there a way to chose their position on the screen programmatically?
Manfred

[David Costanzo]

This might be a bug. I rarely use Windows 10, but the last time I did, I noticed that the file picker dialog boxes were full screen. They don't look that way on Windows XP. Did you only notice this for the modal file pickers or for all pop-up windows?

Is there a way to chose their position on the screen programmatically?

No, but I suspect you don't really care to position them, you just don't want them to be in weird positions.

[Manfred Zindel]

Exactly! For many years I could rely on my FMSLogo modal windows to appear constantly in the middle of the screen. They could be dragged away from there but returned at the next call. Now all my modal windows - not only the file picker, but even the message box - go mad and appear in an unpredictable position. Has it somthing to do with 8pre? Well - I could try working non-modal with parents and children. But so far I felt comfortable with the easy model bunch. What can I do?

[David Costanzo]

I cannot reproduce this on Windows 10 with 8.0.0pre. The only strangeness that I see is that the file picker is nearly full screen and not resizable. All other dialog boxes appear about 100 pixels down and to the right of the upper-left corner of the screen window.

Can you attach a screenshot of the problem?

Can you try to install FMSLogo 7.7.0 and see if the problem is, indeed, related to 8.0.0pre? The link goes to a ZIP file so "installing" it won't disrupt your 8.0.0pre installation.

I suspect that rebooting would fix your problem but its worth trying to investigate the cause before doing that.

[Manfred Zindel]

Fact is that all my modal widgets in FMSLogo behaved friendly by sitting in the middle of the screen for nearly a decade. All of a sudden they seem to no longer like me. Nevertheless they do their work, but look ugly. Look at the attached messagebox and combobox. As soon as I find time for it I shall dig deeper into the problem and as soon as I have new insights, you will hear from me.

[David Costanzo]

The pictures help. I misunderstood two things:

First, I read "modal dialogs like FileRequest", I thought you were referring to ones that the GUI shows, like the About FMSLogo dialog, not the ones you show programmatically, like MESSAGEBOX or SELECTBOX.

Second, even though you said you wanted them "in the middle of the screen" I instead focused on "in an unpredictable position". To me, 100 pixels offset from the upper-left of the parent window is predictable. Many Windows applications do this (for example, notepad). The important thing is that, when a tiny dialog box pops up that is not self-descriptive, that it be placed on top of the application to which it refers to so that the user can connect the message in the dialog box with the correct application. This is especially important for computers with multiple monitors because you wouldn't want a "Error|Bad Input" message box to appear on a different monitor over a different application. That's what used to happen.

Now that I understand your complaint, I can explain the behavior. When a dialog box like MESSAGEBOX or SELECTBOX is displayed, the parent window is always whatever window draws the frame of the Commander and its position is whatever wxWidgets selects as the default position (100 pixels offset from upper-left). When the Commander is docked (SPLITSCREEN), it's 100x100 pixels offset from the upper left of the Screen Window. When the Commander is undocked (TEXTSCREEN), the parent is the Commander. In the screenshots you provided, I suspect the Commander is minimized. For the position, there's one special case: MESSAGEBOX is always centered on the parent window (as defined above).

I definitely made a change to make an FMSLogo window be the parent window, instead of the desktop. I'd have to dig through some history to figure out when I made it. Even with the screenshots you provide, I still think this is the right thing to do. I chose the Commander instead of the Screen Window because the Commander is where the user is typing so it's where their mind is (consider that the Screen Window could be on a different monitor). I didn't consider the case when the Commander is minimized/hidden. That is clearly the wrong thing.

I don't mind updating SELECTBOX to be centered in the parent's window (to fix your SELECTBOX behavior) instead of 100x100 pixels offset from the upper-left. I don't mind choosing the Screen Window as the parent when the Commander is minimized or hidden (to fix your MESSAGEBOX behavior). However, I will not go back to centering it on the "desktop". That's just wrong.

For reference, I can reproduce your screenshots with

FULLSCREEN
ICON "Commander
WINDOWSET "FMSLogo 3
IGNORE SELECTBOX [Make Your Choice] [Run Fight]

FULLSCREEN
ICON "Commander
WINDOWSET "FMSLogo 3
MESSAGEBOX [body] [title]

[Manfred Zindel]

Thank you for your thorough analysis of the problems. We can understand now how it works.

For us it doesn't matter, whether the left upper edge of the widget sits at (100, 100) or the widget is centered - as long the behaviour is predictable. We agree that it is not a good idea to use the desktop as reference like a parent window. The widget should be where the project is. And in our opinion your solution, to keep the widget near the left upper corner of the parent window, is the most convincing one.

The only problem is the case of a minimized or hidden controller, like it appears in some of our applications.

Your proposal, to bind the widget to the Screen Window, if the Controller is minimized or hidden, seems a good solution for us and solves the only problem we really have. We'd be very grateful if this could be implemented.

By the way, we'd like to draw your attention to the ideas behind our efforts:

At pbreport we consider to insert FMSLogo as a basic introduction into a teaching stack which proceeds to HTML/JS/CSS in a later stage and finally to a framework like Vue together with Node.js and Express.

This means that we have to leave the command line as dominating conversational tool sooner or later, hide the controller and use widgets instead - like forms in HTML. Therefore wxWidgets is good for us. Still we have the task to implement some kind of input-widget for strings and numbers, but there should be a way to do that.

While there is no sharp distinction between a user and a developer as long as the command line is the leading tool, we'd like to get closer to such a distinction rather early in the learning process. Moreover we consider to use Notepad++ to replace the FMSLogo editor. This has proven to be efficient.

As we see it, FMSLogo has the advantage that is combines algorithms like in LISP or Scheme with a programmable GUI, very convincing graphics, media, and - last not least - a proper file handling. More than that it seems pretty stable and provides fun while learning it. And it is extendable by itself and not so far from (modern) JavaScript, HTML-widgets, and CSS-styling. There are good other Logos, Basics aso. , Scratch and Snap!, and there are Python, Java, C# and others, but FMSLogo seems for us to offer the best combination for the learning environment we envision.

If a student cuts the stack after having learned FMSLogo, he or she still has a very complete tool for medium projects or fun apps, even if he stops learning more informatics.

Therefore we are looking for a chance to introduce FMSLogo into the curricula of schools in NRW and other German states. We can't promise to be successful, and probably it needs some struggle, but it seems to be worthwile.

[David Costanzo]

Ticket moved from /p/fmslogo/support-requests/11/

[David Costanzo]

I converted this ticket from a support request into a bug.

[Manfred Zindel]

Sorry for the duplicate - so I'll patiently wait for version 8 to be released.

[David Costanzo]

While writing regression tests for this bug, I found that the impact can be worse than originally report. The following instructions causes FMSLogo to crash and disappear:

ICON "Commander MESSAGEBOX [] []

The crash is due to mutually recursive calls in the wxWidgets that cause a stack overflow. However, on Windows 10, the messagebox is merely placed in a bad location. I think this is partly due to how I compile the wxWidgets library, removing features that are not used by FMSLogo to reduce its memory footprint. If I link to a "full" wxWidgets, it does not crash.

For reference, here's part of the stack:

#427 0x004da903 in wxTopLevelWindowMSW::DoGetPosition (this=0x60e38a8, x=0x3ae90, y=0x3ae8c)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/msw/toplevel.cpp:848
#428 0x00948302 in wxTopLevelWindowBase::DoGetScreenPosition (this=0x60e38a8, x=0x3ae90, y=0x3ae8c)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/toplevel.h:319
#429 0x009363ae in wxWindowBase::GetScreenPosition (this=0x60e38a8, x=0x3ae90, y=0x3ae8c)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/window.h:306
#430 0x00935f04 in wxWindowBase::GetScreenRect (this=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/window.h:346
#431 0x00538558 in wxDisplayFactory::GetFromWindow (this=0x5e16178, window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:260
#432 0x00537fae in wxDisplay::GetFromWindow (window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:113
#433 0x00537ebb in wxDisplay::wxDisplay (this=0x3afcc, window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:90
#434 0x004da903 in wxTopLevelWindowMSW::DoGetPosition (this=0x60e38a8, x=0x3b0a0, y=0x3b09c)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/msw/toplevel.cpp:848
#435 0x00948302 in wxTopLevelWindowBase::DoGetScreenPosition (this=0x60e38a8, x=0x3b0a0, y=0x3b09c)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/toplevel.h:319
#436 0x009363ae in wxWindowBase::GetScreenPosition (this=0x60e38a8, x=0x3b0a0, y=0x3b09c)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/window.h:306
#437 0x00935f04 in wxWindowBase::GetScreenRect (this=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/window.h:346
#438 0x00538558 in wxDisplayFactory::GetFromWindow (this=0x5e16178, window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:260
#439 0x00537fae in wxDisplay::GetFromWindow (window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:113
#440 0x00537ebb in wxDisplay::wxDisplay (this=0x3b1dc, window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:90
---Type <return> to continue, or q <return> to quit---
#441 0x004da903 in wxTopLevelWindowMSW::DoGetPosition (this=0x60e38a8, x=0x3b2b0, y=0x3b2ac)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/msw/toplevel.cpp:848
#442 0x00948302 in wxTopLevelWindowBase::DoGetScreenPosition (this=0x60e38a8, x=0x3b2b0, y=0x3b2ac)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/toplevel.h:319
#443 0x009363ae in wxWindowBase::GetScreenPosition (this=0x60e38a8, x=0x3b2b0, y=0x3b2ac)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/window.h:306
#444 0x00935f04 in wxWindowBase::GetScreenRect (this=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/window.h:346
#445 0x00538558 in wxDisplayFactory::GetFromWindow (this=0x5e16178, window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:260
#446 0x00537fae in wxDisplay::GetFromWindow (window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:113
#447 0x00537ebb in wxDisplay::wxDisplay (this=0x3b3ec, window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:90
#448 0x004da903 in wxTopLevelWindowMSW::DoGetPosition (this=0x60e38a8, x=0x3b4c0, y=0x3b4bc)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/msw/toplevel.cpp:848
#449 0x00948302 in wxTopLevelWindowBase::DoGetScreenPosition (this=0x60e38a8, x=0x3b4c0, y=0x3b4bc)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/toplevel.h:319
#450 0x009363ae in wxWindowBase::GetScreenPosition (this=0x60e38a8, x=0x3b4c0, y=0x3b4bc)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/window.h:306
#451 0x00935f04 in wxWindowBase::GetScreenRect (this=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/window.h:346
#452 0x00538558 in wxDisplayFactory::GetFromWindow (this=0x5e16178, window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:260
#453 0x00537fae in wxDisplay::GetFromWindow (window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:113
#454 0x00537ebb in wxDisplay::wxDisplay (this=0x3b5fc, window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:90
#455 0x004da903 in wxTopLevelWindowMSW::DoGetPosition (this=0x60e38a8, x=0x3b6d0, y=0x3b6cc)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/msw/toplevel.cpp:848
#456 0x00948302 in wxTopLevelWindowBase::DoGetScreenPosition (this=0x60e38a8, x=0x3b6d0, y=0x3b6cc)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/toplevel.h:319
#457 0x009363ae in wxWindowBase::GetScreenPosition (this=0x60e38a8, x=0x3b6d0, y=0x3b6cc)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/window.h:306
#458 0x00935f04 in wxWindowBase::GetScreenRect (this=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/include/wx/window.h:346
#459 0x00538558 in wxDisplayFactory::GetFromWindow (this=0x5e16178, window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:260
#460 0x00537fae in wxDisplay::GetFromWindow (window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:113
#461 0x00537ebb in wxDisplay::wxDisplay (this=0x3b80c, window=0x60e38a8)
    at /cygdrive/e/wxWidgets-3.1.3-src/src/common/dpycmn.cpp:90

The wxWidgets code seems to be struggling to center the message box within a window that has no size.

Also for reference, I have attached the source code for a simple program that demonstrates the problem (messageboxcrash.cpp). I am currently trying to identify which of the wxWidgets features which I removed is needed to avoid the crash.

[Manfred Zindel]

Well, I always got at least some functional appearance of the widgets without any crash in Windows 10. Now this sounds worse - but you found the reason, at least a part of it.

I just completed a deadline-driven project in FMSLogo with more than 2000 lines of code. I was very satisfied with the result, with stable and easy to read code and pretty fast..
But the often used messagebox crawled to the left lower corner and also the file open modal dialog went this way. Please see attachments.

[Manfred Zindel]

Thanks a lot for this wonderful amendment!

Everything works fine.

Still there is the menu from the development stage at the top. If this
could be hidden one day the program would look more independent.

Attached you find 4 typical examples from the huge program which now
works perfectly. Neverteless it will still have to be extended.

Note that all the data are fictitious, and the image is that of a model.

[David Costanzo]

This is fixed by [r5525]. The fix will be available in FMSLogo 8.0.0.

I have attached a pre-release version of 8.0.0 which has the fix. You may test it out to ensure that my fix works for you.

For reference:

1. The crashing problem with fixes by enabling the "display" feature in wxWidgets.
2. wxWidgets cannot, in general, determine if a window is shown. To account for this, I had to modify WINDOWSET to re-direct SW_HIDE and SW_SHOW calls to wxWidgets. If you hide the commander by other means, this fix won't work.