Resize Quirk - Debug vs Compiled
Quote from PaulJonestindall on December 5, 2019, 2:35 pmOk. Here's an interesting quirk I found when resizing an app AND a CustomWindow. I'm creating a camera app for a tablet with a custom window as a picture viewer. The development Pub size is 1024x768, full screen with auto-size work area and cover windows task bar. This achieves full screen no matter what resolution the tablet is. Note in Capture1.PNG and Capture2.PNG you'll see the development window and the Pub running in debug mode. Also note the PubWidth & Height vs The ScreenWidth & Height.
So, in the startup I have SetVar "[PubWidth]" "[ScreenWidth]" and SetVar "[PubHeight]" "[ScreenHeight]". With the CustomWindow action I open it at Top=10 and Left=10, SizeObject to PubWidth-20 and PubHeight-60.
You'll see in Capture3.PNG in debug mode the app and custom window work as intended. However, when compiled, you'll see in Capture4.PNG the custom window remains as if the pub were 1024x768.
I've tried many variations in coding... full screen vs standard window w/o titlebar, WindowState Maximized, changing pub width and height, etc...
And finally... as I'm writing this, I realized the very important difference between [PubWidth] & [PubHeight] vs [WindowWidth] & [WindowHeight]. By resetting my window dimensions rather than the pub dimensions the compiled version now works as intended.
BUT, the fact remains, I did get different results in Debug mode than I did when compiled.
Ok. Here's an interesting quirk I found when resizing an app AND a CustomWindow. I'm creating a camera app for a tablet with a custom window as a picture viewer. The development Pub size is 1024x768, full screen with auto-size work area and cover windows task bar. This achieves full screen no matter what resolution the tablet is. Note in Capture1.PNG and Capture2.PNG you'll see the development window and the Pub running in debug mode. Also note the PubWidth & Height vs The ScreenWidth & Height.
So, in the startup I have SetVar "[PubWidth]" "[ScreenWidth]" and SetVar "[PubHeight]" "[ScreenHeight]". With the CustomWindow action I open it at Top=10 and Left=10, SizeObject to PubWidth-20 and PubHeight-60.
You'll see in Capture3.PNG in debug mode the app and custom window work as intended. However, when compiled, you'll see in Capture4.PNG the custom window remains as if the pub were 1024x768.
I've tried many variations in coding... full screen vs standard window w/o titlebar, WindowState Maximized, changing pub width and height, etc...
And finally... as I'm writing this, I realized the very important difference between [PubWidth] & [PubHeight] vs [WindowWidth] & [WindowHeight]. By resetting my window dimensions rather than the pub dimensions the compiled version now works as intended.
BUT, the fact remains, I did get different results in Debug mode than I did when compiled.
Uploaded files:
- You need to login to have access to uploads.
Quote from PaulJonestindall on December 5, 2019, 3:27 pmI have ALSO discovered the resized CustomWindow will work fine on the tablet I compiled on, however, I'm having the same problem when I use the compiled program on another tablet.
Very strange quirks here.
I have ALSO discovered the resized CustomWindow will work fine on the tablet I compiled on, however, I'm having the same problem when I use the compiled program on another tablet.
Very strange quirks here.
Quote from Gaev on December 5, 2019, 5:47 pm@pauljonestindall
It might be because of the relative sequence of the "servicing the two sets of commands" ... in Debug Mode (with interpretation/debug delays), the resized PubWidth and PubHeight might be serviced before the CustomWindow is asked to be changed ... while in the compiled version, the sequence might be reversed.
a) Is the Custom Window on the first page of the pub ?
b) Is the Custom Window being resized within the PageEnter section of this first page ?
c) is the code to open the Custom Window just before the code to resize it ?
I faintly recall (been a decade or so) that the commands in the PageEnter section of the first page are serviced BEFORE the commands in the Startup section of the Pub ... try and place the code related to Pub resizing just before the code that resizes the Custom Window.
If (c) is true, try and introduce a delay between the two piece of code.
P.S. You mentioned Tablet ... is this device running a a Windows OS ? ... or some emulation of Windows inside an iOS or Android device ?
It might be because of the relative sequence of the "servicing the two sets of commands" ... in Debug Mode (with interpretation/debug delays), the resized PubWidth and PubHeight might be serviced before the CustomWindow is asked to be changed ... while in the compiled version, the sequence might be reversed.
a) Is the Custom Window on the first page of the pub ?
b) Is the Custom Window being resized within the PageEnter section of this first page ?
c) is the code to open the Custom Window just before the code to resize it ?
I faintly recall (been a decade or so) that the commands in the PageEnter section of the first page are serviced BEFORE the commands in the Startup section of the Pub ... try and place the code related to Pub resizing just before the code that resizes the Custom Window.
If (c) is true, try and introduce a delay between the two piece of code.
P.S. You mentioned Tablet ... is this device running a a Windows OS ? ... or some emulation of Windows inside an iOS or Android device ?
Quote from PaulJonestindall on December 5, 2019, 6:47 pm@gaev
Thanks for your response. The custom window is a container object on a separate page that's not accessed. I am resizing the object before the CustomWindow action. I try to rarely use Page Enter actions if I don't have to.
What I ended up doing is in the startup:
SetVar "[WindowState]" "Maximized"
SetVar "[WindowWidth]" "[ScreenWidth]"
SetVar "[WindowHeight]" "[ScreenHeight]"
rtWindowsTaskBar "1"This Pub is set to run full screen, auto-size work area with the task bar hidden. The reason for the WindowState Maximized is because elsewhere in the program is a feature that will cause the program to minimize while another program runs and then maximize again. I did this for consistency, whether or not it's actually necessary I'm not sure but it works. " rtWindowsTaskBar" hides the taskbar.
Then a button action:
SetVar "[NewWidth]" "[ScreenWidth]-20]"
SetVar "[NewHeight]" "[ScreenHeight]-60]"
SizeObject "Container12" "[NewWidth]" "[NewHeight]"
CustomWindow "" "10" "10" "Container12" "NoBorder+Exclusive"I originally had the SetVar and SizeObject codes in :Container12_OnOpen subroutine for a particular reason that I can't remember why now. This all worked on one tablet but not the other until I moved the subroutine code to the button. Now it all appears to be working fine.
I'm working with Microsoft Surface tablets. (For what I'm working on, I would absolutely dread working with iOS or Android.)
Thanks for your response. The custom window is a container object on a separate page that's not accessed. I am resizing the object before the CustomWindow action. I try to rarely use Page Enter actions if I don't have to.
What I ended up doing is in the startup:
SetVar "[WindowState]" "Maximized"
SetVar "[WindowWidth]" "[ScreenWidth]"
SetVar "[WindowHeight]" "[ScreenHeight]"
rtWindowsTaskBar "1"
This Pub is set to run full screen, auto-size work area with the task bar hidden. The reason for the WindowState Maximized is because elsewhere in the program is a feature that will cause the program to minimize while another program runs and then maximize again. I did this for consistency, whether or not it's actually necessary I'm not sure but it works. " rtWindowsTaskBar" hides the taskbar.
Then a button action:
SetVar "[NewWidth]" "[ScreenWidth]-20]"
SetVar "[NewHeight]" "[ScreenHeight]-60]"
SizeObject "Container12" "[NewWidth]" "[NewHeight]"
CustomWindow "" "10" "10" "Container12" "NoBorder+Exclusive"
I originally had the SetVar and SizeObject codes in :Container12_OnOpen subroutine for a particular reason that I can't remember why now. This all worked on one tablet but not the other until I moved the subroutine code to the button. Now it all appears to be working fine.
I'm working with Microsoft Surface tablets. (For what I'm working on, I would absolutely dread working with iOS or Android.)
Quote from Gaev on December 5, 2019, 11:38 pm@pauljonestindall
1) Observation...
I noticed (in the bottom band of your pub's images) that the PubWidth/PubHeight values are different (higher) in Capture4.png than in Capture3.png ... this might give you a clue as to the unexpected results.
I originally had the SetVar and SizeObject codes in :Container12_OnOpen subroutine for a particular reason that I can't remember why now. This all worked on one tablet but not the other until I moved the subroutine code to the button. Now it all appears to be working fine.
The Debug Window in Capture3.png shows that Container12_OnOpen IS STILL being called/serviced (although the MoveObject command appears to be marked as an error).
2) Suggestions ...
The custom window is a container object on a separate page that's not accessed.
See if placing Container12 on the same page (but out of sight; say at -2000,-2000) helps any.
What I ended up doing is in the startup:
SetVar "[WindowState]" "Maximized"
SetVar "[WindowWidth]" "[ScreenWidth]"
SetVar "[WindowHeight]" "[ScreenHeight]"
rtWindowsTaskBar "1"This Pub is set to run full screen, auto-size work area with the task bar hidden.
Try and set it (Book >>> Book Properties >>> Window) as a Normal Window ... with the Title Bar property set to Unchecked.
And, instead of returning from Minimized to Maximized, go from Minimized to Normal.
rtWindowsTaskBar" hides the taskbar.
I don't know about this plugin ... try and temporarily comment this command out; see if it makes a difference.
1) Observation...
I noticed (in the bottom band of your pub's images) that the PubWidth/PubHeight values are different (higher) in Capture4.png than in Capture3.png ... this might give you a clue as to the unexpected results.
I originally had the SetVar and SizeObject codes in :Container12_OnOpen subroutine for a particular reason that I can't remember why now. This all worked on one tablet but not the other until I moved the subroutine code to the button. Now it all appears to be working fine.
The Debug Window in Capture3.png shows that Container12_OnOpen IS STILL being called/serviced (although the MoveObject command appears to be marked as an error).
2) Suggestions ...
The custom window is a container object on a separate page that's not accessed.
See if placing Container12 on the same page (but out of sight; say at -2000,-2000) helps any.
What I ended up doing is in the startup:
SetVar "[WindowState]" "Maximized"
SetVar "[WindowWidth]" "[ScreenWidth]"
SetVar "[WindowHeight]" "[ScreenHeight]"
rtWindowsTaskBar "1"This Pub is set to run full screen, auto-size work area with the task bar hidden.
Try and set it (Book >>> Book Properties >>> Window) as a Normal Window ... with the Title Bar property set to Unchecked.
And, instead of returning from Minimized to Maximized, go from Minimized to Normal.
rtWindowsTaskBar" hides the taskbar.
I don't know about this plugin ... try and temporarily comment this command out; see if it makes a difference.
Quote from PaulJonestindall on December 6, 2019, 2:44 pm@gaev
Yes, I put those numbers at the bottom temporarily so that I would see the actual numbers I was getting. This was exactly my first clue that even though the pub was opened in full screen mode or standard mode and then maximized or whichever, the pub size ([PubWidth] & [PubHeight]) variables remained the same as the development window size. Capture4.PNG has higher numbers after I changed the SetVar "[PubWidth]" "[ScreenWidth]" and SetVar "[PubHeight]" "[ScreenHeight]" to SetVar "[WindowWidth]" "[ScreenWidth]" and SetVar "[WindowHeight]" "[ScreenHeight]"
As you see in Capture3.PNG, the On_Open subroutine was eliminated and moved to the Tag Photos button object that you see in the bottom left corner. This button opens the CustomWindow, and somehow oddly eliminated the problem of the compiled pub working fine on one tablet and not another.
I've found that my CustomWindow objects work just fine being called from another page. It certainly helps with editing and organizing my objects.
I think the bigger issue here is the fact that I got different results in debug mode vs the compiled pub. It might also be worth noting that I'm using NeoBook (v5.8.7) which is almost four years old and not VisualNeo where I don't know what major or minor differences there are.
This Pub appears to be working as expected now and I have to move on to the next part of my project. I may return to this at a later date if I find any other problems after it's been put to use.
Thank you for your insights. Much appreciated.
P.S. The rtWindowsTaskBar action is in the Ron Marie FileSystemManagement plugin from about a billion years ago. It has quite a lot of features that still work and are still relevant and convenient. (At least for me.) A very handy plugin.
Yes, I put those numbers at the bottom temporarily so that I would see the actual numbers I was getting. This was exactly my first clue that even though the pub was opened in full screen mode or standard mode and then maximized or whichever, the pub size ([PubWidth] & [PubHeight]) variables remained the same as the development window size. Capture4.PNG has higher numbers after I changed the SetVar "[PubWidth]" "[ScreenWidth]" and SetVar "[PubHeight]" "[ScreenHeight]" to SetVar "[WindowWidth]" "[ScreenWidth]" and SetVar "[WindowHeight]" "[ScreenHeight]"
As you see in Capture3.PNG, the On_Open subroutine was eliminated and moved to the Tag Photos button object that you see in the bottom left corner. This button opens the CustomWindow, and somehow oddly eliminated the problem of the compiled pub working fine on one tablet and not another.
I've found that my CustomWindow objects work just fine being called from another page. It certainly helps with editing and organizing my objects.
I think the bigger issue here is the fact that I got different results in debug mode vs the compiled pub. It might also be worth noting that I'm using NeoBook (v5.8.7) which is almost four years old and not VisualNeo where I don't know what major or minor differences there are.
This Pub appears to be working as expected now and I have to move on to the next part of my project. I may return to this at a later date if I find any other problems after it's been put to use.
Thank you for your insights. Much appreciated.
P.S. The rtWindowsTaskBar action is in the Ron Marie FileSystemManagement plugin from about a billion years ago. It has quite a lot of features that still work and are still relevant and convenient. (At least for me.) A very handy plugin.
Quote from Gaev on December 6, 2019, 8:03 pm@pauljonestindall
Amazing what a good night's sleep will do !!!
I just noticed that the commands related to [NewWidth] and [NewHeight] have a syntax error ... "[PubWidth]-20]" and "[PubHeight]-60]" both have an extra trailing closed bracket !!! ... can't be sure that this is the root cause of the discrepancies but I thought you might want to correct it.
As you see in Capture3.PNG, the On_Open subroutine was eliminated and moved to the Tag Photos button object that you see in the bottom left corner. This button opens the CustomWindow, and somehow oddly eliminated the problem of the compiled pub working fine on one tablet and not another.
Looking at the Debug Log in Capture3.png, it does NOT look like the Container12_onOpen subroutine was eliminated; instead, it is serviced automatically when the CustomWindow command was invoked.
Attempting to change the width/height of the underlying object in the middle of the CustomWindow command is not recommended ... instead, you might move this subroutine's commands to the Button's code (before the CustomWindow command) or even to the pub's startup section (to eliminate any possibilities of timing issues).
Amazing what a good night's sleep will do !!!
I just noticed that the commands related to [NewWidth] and [NewHeight] have a syntax error ... "[PubWidth]-20]" and "[PubHeight]-60]" both have an extra trailing closed bracket !!! ... can't be sure that this is the root cause of the discrepancies but I thought you might want to correct it.
As you see in Capture3.PNG, the On_Open subroutine was eliminated and moved to the Tag Photos button object that you see in the bottom left corner. This button opens the CustomWindow, and somehow oddly eliminated the problem of the compiled pub working fine on one tablet and not another.
Looking at the Debug Log in Capture3.png, it does NOT look like the Container12_onOpen subroutine was eliminated; instead, it is serviced automatically when the CustomWindow command was invoked.
Attempting to change the width/height of the underlying object in the middle of the CustomWindow command is not recommended ... instead, you might move this subroutine's commands to the Button's code (before the CustomWindow command) or even to the pub's startup section (to eliminate any possibilities of timing issues).
Quote from PaulJonestindall on December 6, 2019, 8:27 pmHoly Smokes! How interesting. I hadn't even noticed those extra brackets. I removed them and recompiled. Everything still works the same. The only thing I can assume is that NeoBook ignored them. (Thankfully?)
As far as the Container12_OnOpen was eliminated after the screen cap pictures were made. That coding is in the button. That was a rather poor bit of grammar in the line you quoted. Sorry for the confusion. And thanks for noticing the bracket thing.
Holy Smokes! How interesting. I hadn't even noticed those extra brackets. I removed them and recompiled. Everything still works the same. The only thing I can assume is that NeoBook ignored them. (Thankfully?)
As far as the Container12_OnOpen was eliminated after the screen cap pictures were made. That coding is in the button. That was a rather poor bit of grammar in the line you quoted. Sorry for the confusion. And thanks for noticing the bracket thing.