So in this example, the widget at hand is “BG” and you are not moving but just resizing, yes? So now the issue is that “BG” is too tall in the Base view, but is correct in the Web Desktop view, but only when it is published to Axure Cloud, and only when Adaptive Views are used, and only for the Base view, yes?
In your Page Loaded event I see you set the size of BG twice. Why? Should only be required to set the size once, but with either of your Set Size actions alone it doesn’t work. You are also using the current height of BG to calculate its new height which also shouldn’t be required (unless maybe you were changing the size by a certain value instead of to a certain value.) However, since this works for local preview I don’t think this is necessarily the root of the issue–at least not the whole story. It does make me suspect the order of operations or perhaps the timing is somehow different in the Axure Preview than AxCloud server. Curious about this, I published the HTML locally and tried that–it behaves the same as on AxCloud. This would lead me to conclude the Preview is “wrong” which led you to somehow incorrectly get the result you wanted, if that makes sense
To help me debug this, I set the Resized event of the BG panel to set the text of the BG rectangle inside it to show the height of the BG panel. This showed me the initial height is 547 px, and when globalvar = 5, the correct height should end up as 267 px, for a “shrinkage amount” of 280 px. But in the Base view on AxCloud it ends up at 407 px… Hmm… 547 - 407 = 140 and 407 - 267 = 140. The initial height of the Actions panel is 350 px and the end height is 70 px, and 350 - 70 = 280 (so that pans out.) Interestingly, 70 x 2 = 140 and 140 x 2 = 280. My guess is that either the Preview (essentially a “fake” web server that Axure sets up for the quick preview feature) skips a step or adds a step in the browser code and/or the real HTML results in some kind of optimization that breaks your second Set Size action (or rather, the published HTML “properly” executes it whereas the Preview does not, which is the way to look at it since you need to share the HTML not the Preview.)
Stepping back a bit, it looks like the result you want is for BG to always have a bottom padding margin of 24 px. Conveniently, that is also the padding (or gutter) for BG relative to the “screen boundary” such that the top or “y value” of BG is 24. This means the height algorithm in your “Set Size of BG” action can be simplified to just [[actions.bottom]]. Otherwise, the “proper” sizing algorithm in your height fx would be [[actions.bottom - This.top + padding]] (where “padding” is local or global variable with a value of “24”.
I would also recommend cutting your Set Size action from Page Loaded and pasting to the Resized event of the “Actions” panel so it gets called anytime that panel changes size, whether it is via the Page Loaded event or if user does something to cause “Actions” to change state and thus its size.
As for why any of this should be different in Preview than HTML or Axure Cloud, or for Adaptive Views vs normal, well, it shouldn’t. I’d call this a bug.
You might notice a few other changes in the updated .rp file below. These were things I was curious about but did not turn out to have anything to do with the issue here. For instance, you have a dynamic panel named “BG” that contains a rectangle widget also named “BG” which can lead to bugs if you point to the wrong “BG” (which you did not.) Also, probably no need for BG to be a dynamic panel and/or for it to have a rectangle widget. You can just use the rectangle widget alone and resize it, or an empty dynamic panel alone with a Fill color set. If you keep the rectangle within the dynamic panel (which I did for debugging purposes here) it is better to set the dynamic panel to “Fit to Content” and change the size of the rectangle widget --otherwise if the dynamic panel gets sized larger than the rectangle for any reason you won’t be able to see it and that can be hard to detect and fix later. Finally, I find it confusing to have a local variable named, “this” which points to the Target widget (which is it, “This” or “Target”? These are different concepts… and if you are pointing to the target of an action, you can just use [[Target]] without the need for a local variable --just a hint to help save you time and also frustration if you have to come back to this weeks or months later and try to figure out what you did.
tmm test - size setting not working copy V2.rp (1.8 MB)