Here is a capx with just the button... since it will be easier to look at I guess: dl.dropbox.com/u/604141/Public%20CAP/UpdatePositionBug-ButtonOnly.capx

I put a text box in there for positioning reference.

~Sol

Artwork looks really cool. I'd like to see more :D

~Sol

CAPX: dl.dropbox.com/u/604141/Public%20CAP/UpdatePositionBug.capx

It also uses JesseJoh's HTML Elements Pack: scirra.com/forum/plugin-jessejohs-html-elements-pack_topic47084.html

The problem only exists when two conditions are met;

• Fullscreen in browser is set to SCALE
• Unbounded Scrolling is set to ENABLED/TRUE

Only when these two options are enabled, the iFrame object specifically, seems to be bound to the coordinates of the browser window itself rather than the layout/canvas. Using any means to move the object results in additional problems, causing the object to move unpredictably around the browser window (or even outside of it!) while using the mouse to resize the browser window at runtime.

Using events to "create iFrame at X,Y" will also result in the object not appearing in the correct position.

The problem is more obvious on a layout that is portrait in orientation rather than a perfect aspect landscape layout.

After talking with Kyat and Newt in chat... we have all deduced there is a problem here somewhere. Kyat suggests it may be in the code from your button object, as JesseJoh seems to have used that portion of code in the iframe positioning. Come to think of it, I believe the buttons also suffer this same problem so it could indeed be related.

If you need any more info, let me know. Thanks Ashley :D

*EDIT*

Added a button to the layout as well, and yes... it's the same problem with the button as well!

~Sol

In future please be more specific with your requests. Not only will it help you get an answer faster, it saves on needless replies and further questions being asked.

Other than that, glad you found what you needed... whatever that was.

~Sol

This is working fine in construct 2?

Works perfectly, unless you use "stretch to fit" AND "unbounded scrolling" at the same time.

At least, that's the only problem so far that I have found.

~Sol

Hate to sound like a rush, but... any news on finding this bug so far?

~Sol

Murkat, try to reverse your picking.

If you are picking table vs. scientist, with the scientist as the condition... try making the table the condition instead. Get what I mean?

That will probably fix your issue :)

~Sol

Hi JesseJoh.

So far I have only test the iFrame. You can also see it in the example you provided if you change the full screen mode to stretch, then drag the size of the window around... the buttons as well as the frame "slide" out of position.

If you can eliminate this bug, it would be super cool since I am working on a website now in HTML5 using C2. The deadline is soon, and your iFrame saved my *** basically. This bug is holding it back however, and I would love to use this in the final product!

I appreciate the time you have spent on this, and any future updates. Awesome plugin mate :D

~Sol

I found a bug.

When using an iframe object, the coordinates for the object seem relative to the browsers window width and height rather than the application window (the canvas) itself. It seems to take the "margin" into computation.

This is fine for applications that are not using the full screen stretch/resize feature I believe... however when using the full screen auto resize, it throws the coordinates out.

Any chance of a fix? :D

*EDIT*

It seems to happen specifically when "unbounded scrolling" as well as "full screen (scale)" are both enabled. If I turn off unbound scrolling, then it works as expected but my application is no longer dynamically centered in the browser window.

~Sol