|
|
Post by George on Feb 6, 2021 12:38:34 GMT -5
Robert: I tried a full screen shutdown and then a restart. Yes, I think I can see an almost un-noticeable flicker just as the full-screen opens. Never noticed it before, let alone have time to see how big it was. Maybe my system and graphics card are a lot faster than yours?? Anyway, checked the code. The screen is built as follows: - A dummy screen is built, in DISABLED mode and never displayed.
- A graphic window is built, and the default font is loaded and attached to the graphic window.
- The Height/Width of the font is fetched from the Graphic window. (Yes, this is the only ugly way to get H/W)
- Based on the previous session ScrWidth/ScrHeight values the Window is resized to the correct H/W.
- The rest of the window is created (Tabs, StatusBar, etc)
- If formerly full-screen, another resize is done to full-screen mode.
- And finally, only after all that is done, the screen is ENABLED and displayed.
All that internal manipulation is done in DISABLED mode and should be invisible, the screen is not displayed in normal mode and then switched to full-screen.
So what are you seeing? What am I seeing? I have no idea.
Now there are calls to special Windows APIs (GetWindowPlacement/SetWindowPlacement) that only occurs when doing that switch to full-screen mode, so maybe this is a side-effect of that. I'm not going down that rabbit-hole to try and understand it, I probably just copied this code from some PB Forum posting.
As to the overhead? Well next time you stretch a normal screen, everyone of those refreshes you see as the screen is stretched is about twice as much code as the initial startup.
George |
|
|
|
Post by George on Feb 6, 2021 16:52:17 GMT -5
OK, did your test. But all I see is a 'blink', no way I could even guess how big it might have been (or even if it was an SPFLite screen).
Yes, the window is DISABLED, that's done as one of the parameters when the window is created. The ENABLED is not set until just before the screen is actually activated.
I do the switch to full-screen after all the normal screen sizing is done for simple programming convenience. When I added the 'Restore to Full-screen' it was simpler to add a simple IF FullScreen then Call SetFullscreen statement than to figure out how to adapt the previous 'figure out the screen size' routine. But mainly, just setting X/Y to full screen is not sufficient. Going full-screen is NOT SIMPLY setting X/Y to the screen dimensions, it is a whole different screen MODE in Windows, and has to be done correctly.
I have no ideas how to prevent what you're seeing.
George
|
|
|
|
Post by Jo on Feb 11, 2021 6:41:34 GMT -5
There should be another stype-option besides DISABLED/ENABLED: HIDDEN/VISIBLE
Jo
|
|
|
|
Post by George on Feb 11, 2021 12:44:03 GMT -5
Jo: I don't see Hidden as an attribute I can specify on creation, I believe they can be used after DIALOG DISPLAY.
I can try issuing a HIDE right after creation and a SHOW before the DISPLAY.
Q: Do you see the same effect as Robert? My problem is that if I make this change, I can't tell if it's doing anything.
George
|
|
|
|
Post by Jo on Feb 11, 2021 17:16:37 GMT -5
George: I do not program any native Windows API, I just use ooRexx/ooDialog. But they say "the ooDialog framework simply provides the Rexx programmer with an interface to the Windows API". Therefore, sorry, I'm not familiar with the Windows functions.
I used Roberts sample: With all my open tabs I maximize the display, then do EXIT. On reopen is see SPFLITE an the same position and size as before maximize, then I see flashing header-lines (filenames) while all my files are reopened and read, then the screen is maximized. This is done in just 1 second. My sytem is not highend, just an average dualcore Pentium 3 GHz 8 GB and Win10.
I usually have some files open when I EXIT, so the reopening and reading the files takes some time. When not maximized there is no flashing, just one second wait before the display comes up.
Jo
|
|
|
|
Post by George on Feb 12, 2021 11:50:49 GMT -5
Jo: OK, I tried with your example. I opened a whole bunch of tabs in full-screen and then shut down and restarted. I can see it now, not for long, but it's there. Now I can see about trying to remove it. George [UPDATE] OK, I moved some Init code around, it seems a lot better. Even with 10-12 tabs opening on restart, I can't honestly detect a sign of the small screen. Next release Here's a trial version to test, let me know the results SPFLite23.exe (483.5 KB) [\UPDATE] |
|
|
|
Post by Jo on Feb 13, 2021 5:28:34 GMT -5
George: Yes, just a very short display (subsecond) of the aktive tab in non-full-screen mode, then fullscreen.
|
|
|
|
Post by George on Feb 13, 2021 10:13:48 GMT -5
Good. I wish I could figure out how it's being displayed at all. It's now flagged as Disabled and Hidden, and those are not removed until immediately before final activation.
Weird.
George
|
|
|
|
Post by mueh on Feb 14, 2021 2:36:32 GMT -5
George: When i tested the 21043 Version and Clicked on the icon twice nothing happened ( due to 20-30 open files and some on slow USB drive) .
So i clicked on the icon twice again and got a window with no open file and after that the window from first start .
Closing now the first window and the second causes loss of files in open file list .
What i would suggest is not hiding the window but set it to full screen if required before reopening the files .
If you have a window immediatly started you have no chance to start it a second time and see how the files are opened one after the other .
If i'm alone with this suggestion i can live with it .
Maybe you can avoid creation of second window .
Thanks
|
|
|
|
Post by Jo on Feb 14, 2021 3:53:12 GMT -5
mueh: Is your "Only 1 SPFLite running?" option checked?
And yes, when I started 21043 the first time, there was a delay of 5+ seconds. Maybe due to some upgrade-check routines running? The second and subsequent starts all were quite faster (under 1 second).
Jo
|
|
|
|
Post by George on Feb 14, 2021 10:35:28 GMT -5
Jo: MUEH: There are no upgrade type routines, not sure why the 1st open would be slower.
MUEH: I really don't want to muck about with the startup sequence. It's a bit of a bootstrap operation, and the timing is sensitive as to what functions need to be done before other functions.
Getting a Window out early to help prevent the 1SPFLite running option also makes the 'seeing a window before full-screen' worse.
Maybe I could save the pixel x/y size for the default font and avoid having to create windows just to obtain those values. When I have time (sure) I'll try that.
George
|
|
