I am still tracking the strange bug that makes all previously opened WebPages Resized event fire when the browser window is resized on the last one. And that if they are closed the Resized event of the current page no longer fires.
I installed RubberViewsWE on a WebDialog and was expecting the same phenomenon to take place, but no, web dialogs Resized event does not trigger the Resized for the previously opened WebPages.
I was wondering why RubberViewsWE did not work quite right with dialogs, until I realized that very simply, not only width and height are wrong on the first resized, but then it stops entirely working on Sheet and Modal dialogs. I have applied a workaround, but Resized seems definitely a problem in Xojo Web !
39623 - Resized event wrong size and stops firing on WebDialogs
Status: Needs Review Rank: Not Ranked Product: Xojo Category: Compiler
Michel Bujardet Today at 6:33 PM
OS: OS X 10.10.3
Xojo: Xojo 2015r2.2
Steps: Run the attached project which demonstrates the issue.
Sheet dialogs and Modal dialogs Resized event does not work properly.
Upon opening, it correctly reports the design size of the dialog.
When the user resizes it the first time around, Resized fires but self.width and self.height instead of being those of the dialog are those of the browser window.
Yeah, this is a known bug. The dialog control includes that dark overlay thing and so the browser includes that in the measurement. Add to that (another of your bug reports) the fact that the Resized event fires before the width and height properties get updated, which has turned out to be a Chicken vs Egg problem.
I may not be describing that correctly with Parent and child. Sorry.
Let us say I have a page A which shows a page B through a button. In practice, when page B is displayed, A no longer displays.
Yet, if the browser window is changed, Resized fires in both B (currently on screen) and A (not displayed). This goes on for as many pages as there maybe. If I have five pages that open new ones, the very first one will fire Resized if only the last one is on screen.
I was not expecting that behavior. Even more surprising, in the example with A and B, if I close A while B is on display, B’s Resized event stops firing altogether. I could imagine that once pages are showed they still remain in memory to display faster, but why should they fire Resized, and worse, why should Resized disappear from a page displayed subsequently if one closes one opened before ?
I filed 39536 with a project demonstrating all that.
All that surfaced when I added page selection based on browser window shape in Resized. Something like
If self.width < self.height then
That works quite fine on the first page displayed. But if several other pages have been shown after the first one, and the user rotates the device or makes the window Portrait, the vertical version of the first page will show instead of the current page. I do not think this is right. I had to implement special code to track which page was currently on screen, so I could dismiss the non displayed pages event.
Well, the reason Page A continues to fire is that it’s still there. It’s still in existence on the browser and if we DONT Fire resize events and the user closes Page B, controls manipulated in the resized event would not be where they need to be. This behavior is unlikely to change.
As for the Redized event of Page B no longer firing if page A is closed, please file a simple bug report so I can see this in action, preferably without your resizing library if you can reproduce it without.
For what its worth and from a design standpoint I find WebPage’s to be cumbersome and limited. I typically only have a couple that exist and everything else is dynamically embedded as WebContainers. Whenever I do create something as a WebPage and not a WebContainer it ends coming back to bite me later so now I strictly avoid it from the start.
I’ve also had a plethora of issues with WebDialogs and their dimensions. You’ll notice that if you try to embed a container it will be relative to the gray area - which can both be a blessing and a curse. But having to get the true dimensions via a hack-job is less than ideal.
I’ve also had issues with resizing WebDialogs where they continue to grow off into infinity… all in all WebDialog are not fun and seriously need some attention.