I have a window with a DesktopHTMLViewer in it, with all locking buttons set, so it resizes if the user resizes the window. Underneath it are two buttons which are locked to bottom/right of the window. A user has sent me a screenshot saying that these buttons are missing when he runs my app under Sequoia, but in fact the screenshot just shows that the DesktopHTMLViewer has pushed both buttons down the window so that only a couple of the top pixels of each button is visible.
A complication here: there was the recent feature addition of a Window menu managed by Xojo. Just before that, I had implemented my own Window menu so that the user could more easily find a window that had become hidden behind the main window (complete with checkmark for the frontmost window). This all works nicely but I worry that these two systems may be interfering with each other.
Do you use a ToolBar? I remember an issue on macOS where changing the Toolbar moved the window contents down. I thought it had been fixed many months ago.
If you use declares to modify the window, it could cause this behavior. Also hiding and showing the toolbar could do that (it appears to be the right distance for that)
Oh!! Make sure the user isn’t using tabbed windows. That could account for this too.
Neither toolbar nor declares for this window, in fact (I should have added that the HTML content for the Viewer would have been different in the two images). I was just surprised that a Viewer could decide to change its size within a fixed window, or that by doing so it might change the location of other controls within the window.
It didn’t do all that. The Xojo framework thinks the window is a different size than it really is.
I would give your user a test version where you put the window size in the toolbar and update it whenever the window is resized. Then have them take a screenshot that shows the whole window. That will tell you if the window is sized or proportioned incorrectly… and if they are running any special additions (like Tinkertool) that adjusts how windows render.
Yeah, I can do that. Additionally, I now think that there is no conflict between my Window menu mechanism and the new, automatic one, of Xojo’s. This is because mine is called windowMenu and not WindowMenu. Renaming it to have the case as shown in the docs, causes 36 compile time errors.
I think the odds here are (a) finger trouble at the remote end, (b) that I wasn’t ensuring that the window would fit entirely on the user’s screen (I’ve changed that now).
