Trouble Resizing Container Controls

I’ve got a situation that I’m rather stumped about. Turning here for some help and let me do my best to explain.

The main page of my web app has a container control that can contain a number of controls. The number of controls may vary from installation to installation. If there are more controls than available space, the container control scrolls. And as the window size is adjusted, the container control adjusts. This works fine and great on the desktop and even the iPad.

iPhone is where I get into trouble.

So on the iPhone, the size is much smaller. I have things set up so that when in portrait mode, I get basically two controls per row and multiple rows and they scroll fine. Landscape is where the problem occurs. In Landscape mode, I can get about 4 controls in a row. If I have more than about 3 rows, the container control scrolls fine. If I have say two rows, it’s problematic. The container control will scroll fine if the page is opened in landscape mode. However, if I rotate to portrait (it works just fine) and then back to landscape, I lose the ability to scroll. It just doesn’t work. If I completely refresh the page again, then scrolling comes back.

I’m using the same methods to calculate where the controls go and how large/small to make the container control in both instances of creating a brand new page (i.e. startup or a manual page refresh) and in simple rotating/resizing the page. But I lose the scrolling.

If I look at all the values, everything looks fine like it should work. The container control is smaller than the coordinates of the second row of controls. The second row of controls is there with the right coordinates. I can manually make the container control larger and show parts of the second row of controls. But I cannot get it to scroll. It just won’t do it.

It seems like it has something to do with the size of the container when the page is constructed in the browser vs. when the code finally executes and the browser just doesn’t update itself. I’ve tried making container control size adjustments with timers, etc. I cannot figure this out.

It’s quirks like this that just get me really frustrated when working with Xojo Web projects. It seems like everything you have to do is almost a work-around. You can’t just simply code and have it work right.

Anyhow, off that rant and back to the topic at hand - Anyone have any ideas for me here? I’ve thought about using the container control as an embedded container control and simply removing it and re-embedding it on any rotation. But that’s kind of a mess and a headache for a LOT of other reasons that I won’t go into here.

And it’s frustrating because with enough controls on the container control - things work just fine. It’s this in-between never-never land that is the issue.

It’s also frustrating because the usage of my web app with an iPhone with this specific number of controls in landscape orientation is a corner case. It may never really be needed. But I’m anal enough that this drives me nuts and I don’t want the product to have this bug. But I’ve spent the last 5 days or so trying different things to figure it out but I can’t. So help! :slight_smile:

Thanks,

Jon

Well, since no one responded, I continued trying to figure out what was going on and what was happening.

I have had my container control locked to the width of the page.

I have discovered that what looks to be happening when rotating a phone is that the width and the height of the page are being swapped (of course) and when you have the container control width locked to the width of the page, it seems it gets confused during the rotation and if you don’t have enough controls to build out, things get set in the browser in a funky way.

So I have now unlocked the width of the container control and set the width of the control entirely in code. Now, things work quite well and I get my scrolling regardless of the number of rows of controls (with the exception of one row).

So it’s another quirk in Web Edition when using container controls and having to deal with how things are built and delivered to the browser, etc. Seems like if enough controls need to be built the locked sizing catches up to what it should be, but if you don’t have enough, the locked sizing gets all buggered. I should probably file a feedback report on this but then again, I have some WebContainerControl feedbacks that are nearly 3 years old now! :o