#586 Items 12,13,14,15 in MACHINE's output don't look right

[Manfred Zindel]

I'd like to send you a zipped standalone FMSLogo demo.
It is very simplified and doesn't yet contain Little Helper
(which is meant to be the next step). I hope you can open and run it.
Our problem is that we do not understand the status of MACHINE at the end
from Item 8 on. We discussed it while reading the documentation,
but cannot explain the values we see - some of them exceed the desktop, but shouldn't.

[Manfred Zindel]

... Sorry, I should have written: We understand MACHINE until ITEM 11, but not the remaining 6 items.

[Manfred Zindel]

Here is another clyrifying remark: What we cannot explain are the values of Item 12 to Item 15 in our example (all the others are allright) - and these four are of minor importance for our use cases.

[David Costanzo]

I think you understand the MACHINE documentation just fine; 12/13 are the dimensions of the overall window and14/15 are the dimensions of the screen's client area. However, 12, 13, 14, 15 all look wrong to me, so I can see why you'd think you didn't understand it.

The intention is clear from the source code. I don't know why the numbers in the attached screenshot don't match up what I measure in gimp, but I suspect that this is a bug that I introduced when porting FMSLogo to use wxWidgets.

I confirmed that 12,13 match expectation in MSWLogo 6.5b, so the problem was introduced in FMSLogo. I think I added 14,15 when I added SPLITSCREEN functionality (docking the commander by default).

[David Costanzo]

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

[David Costanzo]

I looked into this a bit more and concluded that FMSLogo correctly reports what Windows thinks is the size of the window (at least for ITEM 12,13). It doesn't look right to me when I count pixels, but there might be some invisible padding that recent versions of Windows adds to top-level windows to work better with touch screens.

When I first tried to run your sample program, it created a window that was too big for my laptop, then ran FULLSCREEN and minimized the commander. I wonder if the problem that I saw isn't the one that you saw. If you use smaller values for the -W and -H command line parameters, does your problem go away? Specifically, I'm wondering if the -W and -H don't work as you expect when the dimensions you choose are close to the size of the windows desktop.

[Manfred Zindel]

Yes, I think it's helpful to investigate this further. First of all: The most important problem seems to me that -F doesn't work properly. But let me explain it from the start:

My discolight-program indeed runs FULLSCREEN with a maximized FMSLogo-screen as long as the "discolights" are flickering and then returns to SPLITSCREEN. This is correct. But why creates your laptop a graphics screen larger than the dispay? Perhaps there is a simple reason:

When using -W 1536 -H 864 I did this as a result of the following calculation: My display settings were 1920 x 1080 as resolution (full HD) and a scale of 125. That means I have to reduce the pixel numbers by the factor 1.25. The result is just 1536 x 864 and this is exactly what MACHINE items 10 and 11 say. This means that the machine used exactly the screen resolution I had chosen in the launcher.

Is it possible that your laptop used either a smaller screen resolution than full HD or a greater scale factor than 1.25? The problem is that for each personal computer the values of -W and -H have to be recalculated, and this is the reason why I added PRIVATE to the name of the launcher.

Now it is not comfortable that in principle -W and -H have to be recalculated for each new computer. So all my hopes rest in -F which should do the work for the user. So I wrote an alternate launcher which uses -F instead of -W and -H. But this doesn't work properly.

I wrote the following auxiliary procedure and integrated it into the program:

TO present_machine
  CATCH "Error [
    MESSAGEBOX [INFO] 
      (SENTENCE
        [MACHINE ITEM # -> CURRENT VALUE \n\n]
        [01 Is Windows 1, otherwise 0 ->] ITEM 1 MACHINE [\n]
        [02 Machine word size 32 or 64 ->] ITEM 2 MACHINE [\n]  
        [03 Pixel width of drawing surface in screen window ->] ITEM 3 MACHINE [\n] 
        [04 Pixel Height of drawing surface in screen window ->] ITEM 4 MACHINE [\n] 
        [05 Always 0 (no palette possible) ->] ITEM 5 MACHINE [\n] 
        [06 Major version of Windows. ->] ITEM 6 MACHINE [\n] 
        [07 Minor version of Windows. ->] ITEM 7 MACHINE [\n] 
        [08 Pixel width of desktop not obscured by taskbar ->] ITEM 8 MACHINE [\n] 
        [09 Pixel height of desktop not obscured by taskbar ->] ITEM 9 MACHINE [\n] 
        [10 Pixel width of whole desktop ->] ITEM 10 MACHINE [\n] 
        [11 Pixel height of whole desktop ->] ITEM 11 MACHINE [\n] 
        [12 Pixel width of screen with frame, scollbar, etc. ->] ITEM 12 MACHINE [\n]  
        [13 Pixel height of screen with frame, bars, commander ->] ITEM 13 MACHINE [\n] 
        [14 Pixel width of visible inner drawing surface ->] ITEM 14 MACHINE [\n]
        [15 Pixel height of visible inner drawing surface ->] ITEM 15 MACHINE [\n]
        [16 Pixels scrolled out of view to the left ->] ITEM 16 MACHINE [\n]  
        [17 Pixels scrolled out of view to the top ->] ITEM 17 MACHINE [\n]  
      )
  ]
  IGNORE ERROR
END

The subroutine is activated at the end of the run and so you can look up all the current values in MACHINE.

I took two display snips and send them as PNGs attached to this post.

The results lead to the following questions:

Why do the values 12 and 13 exceed the corresponding values of 10 and 11 which means that they exceed width and height of the display? (minor importance)

Why choses F a screen height which is much smaller than the display height???

The latter result seems to be an important bug which makes it impossible to build a full-dispay-launcher independantly instead of one for each individual computer with its own dispay settings.

Matching the display size exactly is only one of the most important use cases. Others benefit from FMSLogo's rare capacity of allowing graphic screens larger than the display or viewport. One example is our very successful program for creating individualized documents in high quality printing. Another example is our copter-project which is still in the pipeline but regretably will still have to wait for a while.

So it is of great importance for us to have a -F that does its job perfectly.

Please look at the attechments.