Your comments
Okay. I looked at your code. You had a text tag that wasn't formatted correctly, so I fixed that and you are now returning "page-[param:id]" on every page of your list.
11 years ago
Unfortunately the sync tag will not wait for the play to finish its run. This is because once the play tag initiates another action block, the sync has no way of knowing how deep the play tag could go. The play tag could trigger another action through an additional play tag and etc.
Sync will only track the trigger of a play action and then move to the next action tag in the sync.
Sync will only track the trigger of a play action and then move to the next action tag in the sync.
It looks like you are using a class within a class, which is causing your _alias to get lost since you are moving it from one class to another class and then to an action. You can only move an object variable (underscore) from one object to another, not through a third. So you need to move _alias to your listL class for starters.
Also your loadPage1 action doesn't seem to be targeting any objects that are defined in the main.wire. I am not seeing that.
Start there and then we will see where you are at.
Thanks.
Also your loadPage1 action doesn't seem to be targeting any objects that are defined in the main.wire. I am not seeing that.
Start there and then we will see where you are at.
Thanks.
This is currently a feature request in our system to support all remaining keyboard types that we are not. I will see if I can't target this for our next fusebox release.
In our next WIRE engine release (1.5) we have implemented a pixel attribute for the scroll action. It honors the animated attribute just like the page attribute would.
https://studio.rarewire.com/wordpress...
In the meantime you will have to rely on using scroll to trigger on a specific page inside of a pager.
https://studio.rarewire.com/wordpress...
In the meantime you will have to rely on using scroll to trigger on a specific page inside of a pager.
Jenifer,
We do have a bug logged for this already. I will put it on the list of tickets to discuss in our next dev meeting. Hopefully it will be an easy fix.
Thanks!
We do have a bug logged for this already. I will put it on the list of tickets to discuss in our next dev meeting. Hopefully it will be an easy fix.
Thanks!
Ah. If you are using the download action to grab assets AND using fusebox, then those assets are getting stored inside fusebox's applications folder. The only way you can clear those out is to run a delete action inside your wire for those image files....or delete and reinstall fusebox. The test environment is a balance as you are working inside fusebox, which in reality the actual app that is driving the wires in your projects.
This is an interesting concept. I can see how that would make sense if you were primarily developing your app inside of our provided WIRE editor. In some cases if you are working in another IDE, you would save there and then use the snapshot button either in fusebox or inside of the browser editor, which is part of the reason why we separated the two.
I will work on writing up all the different scenarios and see if this makes sense inside our browser editor.
Thanks.
I will work on writing up all the different scenarios and see if this makes sense inside our browser editor.
Thanks.
Obviously depending on the device you are running on, RareWire apps run at around 5% of the device memory.
Customer support service by UserEcho