Bug: Local variables do not work on cloud

#1

I am using local variables to calculate values for Move and Set Size events and it appears they only calculate locally.

So when I “Preview” locally, everything works as intended. When I publish to the Axure cloud team project and view the link in my browser, Move and Set Size events do not work because the math does not run, so nothing moves and nothing changes sizes.

I confirmed this by putting in static numbers in-place of the calculated numbers and the move’s and set size’s work just fine. This appears to be a bug.

For example, I’m using this event:

Works on local, does not work on cloud:
Move: Dynamic Panel
To: __ x, [[667 - target.height - 10 ]] y
(ƒ Local Variable “target” = widget, Target)
Animate: Ease Out Cubic, 340ms

Works on local, works on cloud:
Move: Dynamic Panel
To: __ x, 304 y
Animate: Ease Out Cubic, 340ms

I cannot share my project or link because I’m working under a NDA. If anyone has a similar issue or a workaround that would be great. I haven’t tested whether the animations play a role.

#2

Hmm, that shouldn’t be happening… Not sure why. Just to be sure, are you testing local and Axure Cloud on the same system in the same browser? You should. Also, since you mention you are using a Team Project, ensure that you first “Get all changes from team directory” and then check in your page before viewing prototype on Axure Cloud --maybe things got out of sync? And/Or save your project as a local .rp file, verify your code for the moves, and then post that to Axure Cloud.

Not sure what that last line means, but I wonder if the lower-case “target” is messing up the way the code is interpreted on the Axure Cloud server. So maybe try using a capital ‘T’ instead? Or perhaps if you are using a Local Variable named “target” (instead of the default, “LVAR1”) that is the issue. You should not use “reserved” names (such as “target” or “this” or “width”) for local variables. So if this is the case, try a unique variable name like “MyTargetVar”. (Also, if you are setting up a local variable to point to the target widget, you don’t need to–just use the built-in variable, “Target” as in, [[Target.width]].)

Here is a demo file that moves a dynamic panel around in various ways, using various local variables, just to prove that it works identically when viewed locally or on Axure Cloud:

move panel.rp (66.2 KB)

https://tzmoth.axshare.com

If the above doesn’t help, you could perhaps:

  • Create a copy, strip out any confidential material and post.

  • Apply your code to my demo above and post that so forum users can inspect and fix.

  • Send an email to support@axure.com and attach your file.

#3

Thank you for your reply! I have created an axure file you can test with. I have attached it below.

In doing so, I was able to do more testing on this bug. It appears Adaptive Views have something to do with it. On a screen without adaptive views, my variables worked fine, even named “target” and “this”. With adaptive views, only the biggest adaptive view would work (in my case, Big Desktop, 1440x800). If I selected my Base size (375x667) or any other size, the sizing would not be correct.

Comparing the final result of the two tests, it appears when it’s incorrect, it’s off by double the size of the element I’m trying to measure. So it appears something is getting measured twice? Not sure. See for yourself.

To test yourself:

  1. Visit the prototype’s flow: https://j62ylt.axshare.com/

  2. Click on the top right flow box labeled “Account Actions Modal - With Vars”. globalvar=5 should be underneath that.

  3. Set the adaptive view to the biggest option.

  4. Go back to the flow, click the box again to now visit the page with the biggest adaptive size selected. The Modal window should sit nicely underneath the “View statements” option.

  5. Now select “Base” from the Adaptive view option and go back to the flow, select the same Flow box to return to the page with the correct globalvar loaded and adaptive view selected. This time, the modal window has a lot of extra space below the View Statements option. This is the bug I’m referring to.

(or you can try resizing your browser on this page and refreshing https://j62ylt.axshare.com/account_actions_modal_-_using_vars.html#globalvar=5)

You can click around the other pages to explore and test. Underneath the first page are “part 1” and “part 2”. These execute the first part and the second part of the sizing actions only, respectively.

The next main page (suffixed with “Using Different Vars”) is where I use MyTarget instead of target and this. Another page has no adaptive views, which performs correctly. And the last page has static numbers instead of dynamic, which also works perfectly.

You have to click from the flow to get the right state to load. I’ve kept this functionality since it may come into play and it reflects how we do states in our project.

tmm test - size setting not working copy.rp (1.8 MB)

#4

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 :exploding_head:

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)

https://4zlova.axshare.com

#5

Awesome – very very helpful! I’m going to have some time later today that I will attempt to implement this in our team project.

Interesting that Axure Preview is what is showing the incorrect version. I’ve contacted support and I’ll point them to your response as well in hopes they can debug that issue.

Thanks again and I’ll report back soon.