Simply put, WebContainer.EmbedWithin does not work. I opened a case, 63134, where I explained what I believed was happening, because mathematically it makes sense. It was closed with some advise “To do what you want, move the LockRight and LockBottom to AFTER the call to EmbedWithin.”
I followed the instructions, and although I did find that now the location was correct, the locks were not being honored. It gets worse if we want to lock to the bottom right.
SIDE NOTE:
On a side note, I duplicated my main project that I build. It had 8k errors moving to 2.0. I spent the last week converting all of them. I got most of it running correctly. But these bugs/missing features are massive. Toolbars don’t position correctly, styles unexpectedly don’t load (random buttons will be missing their styling). Bootstrap S/M/L sizes don’t exist in Xojo. You can’t programmatically add or remove from segmented controls, tabpannels et cetera. The list goes on. I also have a WebPage that takes 3-4 actual minutes to load where on the Web 1.0 project it is instant. I had to build a custom legacy WebTextField because I have 900+ text fields (loaded onto WebContainers) and they each need to respond to the Enter key separately. I am so frustrated.
I am programmatically repositioning controls using style.value(“left”) … et cetera to make toolbars work! I have about 90 toolbars in my project.
Xojo Release 2.1; Until you said something, I had only tried it on Safari and Safari Technology Preview; so I just tried it on my iPad (latest), Big Sur (11.1), Safari and Safari Technology Preview (latest), Chrome (87.0.4280.88), Firefox (83.0) – There is an update for FireFOx haven’t tried it yet. They are still grey. On all buttons.
I wonder if Xojo has cached an old CSS file on my computer that the debug app is serving.
I also tried all the EmbedWithin Tests, all still failed on those browsers.
I have updated the case to include a new demonstrating that Example 8 works.
I also realized that EmbedWithin function assumes that the provided dimensions (in the parameters of the function) are based on the ORIGINAL size of the page. The server-side representation of the WebPage updates the dimensions based on the Browser dimensions; however, WebRectangle (and presumable other WebUIControls) do not update their server-side dimensions to match those in the web browser.
This explains why the following works (Rectangle2 is locked right and bottom)
w.embedWithin(self, Rectangle2.left, Rectangle2.top, 300, 300)
Even though in the web browser, self.width-10-300 appears to be visually equal to Rectangle2.left, the computation yields different results. WebPage has an updated with and height based on the size the actual page, but Rectangle2 does not have an updated Left and Right.
EmbedWithin seems to need assume that the page has not been resized. Which is fine? I think… But very confusing.
I do understand that not updating the Rectangle’s position just because the page is resized is probably better as it doesn’t cause a lot of small packets to be sent to the server just because the user resized the webpage window, it is inconsistent and complicated to understand the problem.
I also realize that this explanation might not quite be right, but regardless, EmbedWithin has a lot of unexpected behaviours that do not logically follow.
I have a FC open on issues with embedded controls, specifically WebRectangle. <https://xojo.com/issue/62709> All I can say is that I noticed that when embedding controls all sorts of nasty things might happen :-(. Let’s hope those will be fixed soon. To the credits of Xojo: I understand that they depend on users like us, doing “crazy, aka complex” stuff to identify such issues.
I noticed as well that Safari is far from being stable. Apple had lately some ugly bugs, for instance file uploading being broken on Safari not running on Big Sur etc. I started to define Chrome as my standard. All I’m doing must look and work on Chrome. After this has been achieved I’m starting to look at other browsers. The below article is addressing this indirectly: showing how something “simple” as the color of a button looks slightly different on all browsers.
I created a forum post just 2 days ago with the same problem. If controls are moved via code disasters happen. Plus if the controls are inside each other references are lost. I’m also glad that someone else notices the drastic reduction in performance because compared to 1.0 it is at least 10 times slower. I also opened a feedback case hoping it will be corrected as soon as possible.
