I tried your instructions, but it is still not working for me: get index finds index and forwards it - this is ok, I see it in inspector.
Rotate list also finds that number, this is ok.
But some why it doesn’t rotate to that position.
might it be the formatting issue?
To explain: when my arrows rotate the shifter in inspector it looks like this (-1 is black color) and it works to shift whole list -1:
Thank you very much, I finally found it!
The solution for my case was to subtract the total item count - index of found item + 1, and then this leaves me always with perfect results.
If I only used index of found item + 1 it didn’t work.
Not sure how, but now it works, maybe it helps out someone.
Thank you Keith for the amazing input and plugin!
Hey @rccanlas2, well of course I didn’t change anything, but note that when you’re iterating with List Shifter, if the “Iterate” event workflow fails, List Shifter logs that to the debugger with the workflow error message. So, if you can replicate this, run your project in debug mode and or open the console and you’ll see the errors in the debugger/console.
They’ll be the same as you’re seeing in the log. So, I don’t know what remote server you’re connecting to in your workflow, but - like the message says - it could not be connected to.
Over in another thread, I posted an amusing use of List Shifter to do recursive workflows in the page using List Shifter’s Custom Value. Find that here:
I trying to solve one task.
Can someone give me a clue?
A have one row of data which I put in custom state. I need to make from them a pairs.
Example: I have a row: 1, 2, 3, 4, 5.
I need to make
1-2, 1-2, 1-3, 1-4, 1-5,
2-3, 2-4, 2-5,
3-4,
4-5.
I tryed to put one list shifter in another one, but it didn’t work well.
May be there some simple way and I overdoing it.
Help please
@rccanlas2, when Iteratiing, List Shifter gives you the Current Iteration Index as well as the value of the current item itself (Current Iteration Item).
If you’re iterating over some list (let’s call it some_list), you can refer to the current item as:
some_list :item # LS's Current Iteration Index
If you turn on parentheses (go to Settings > Versions and down under Experimental click the box for “Expression parentheses”) you’ll be able to refer to the next item in some_list as:
some_list :item # ( LS's Current Iteration Index + 1)
If you’re just trying to concatenate strings, you could do this in the PROCESS List action, most likely, but I don’t entirely understand what the pattern is (I think perhaps you have some typos there?)…
Hey @yorgio1024, I assume you’re asking about Calendar Grid Pro? I haven’t played around with it too much in the new responsive engine, and I also haven’t worked on converting it to the latest plugin API (version 3) just yet. It probably needs a few changes to move it to fully support the new responsive engine and, since someone has finally asked, I’ll look into that. CG Pro has been stable for a long time, so I’ve been fairly loath to undertake that particular project…
Hey @keith, been experiencing some unexpected messages stating ListShifter isn’t initialised when attempting a SORT - even though the SORT action is triggered inside the “ListShifter Initialized/Updated” event.
I experience this mainly after browser refreshes, and only randomly. Most the time it works fine, but on occasion I am receiving that error and it really isn’t making much sense to me, since it shouldn’t be sorting unless it was already initialized… any thoughts?
Well, keep in mind that the sort action is asynchronous with respect to non-List Shifter actions. So you could for example do something in a later workflow step that is causing this issue.
But more likely, you’re doing something that is causing List Shifter to run its update function quickly in sequence.
Like, you’re modifying the list fed to List Shifter quickly in sequence. Every time the “list to shift” changes, List Shifter runs its update function.
At the end of that function the initialized/updated event fires. Since you then sort the list on that same event, it’s possible that List Shifter is already in update mode from some other change.
There’s a lot of stuff like this that can cause what you are seeing. If you want me to look at some specific page give me editor access and I can tell you where you’re going wrong.
Edit/more: In some circumstances, certain List Shifter actions suspend the update routine (e.g., in Process List and Iterate mode), but other List Shifter actions assume that you will do the action and do nothing else that might cause an update until you receive the action’s associated “complete” event.
I think you may be right… it turns out the update function was running in quick succession - as I noted from some log entries that it was running twice rapidly.
Turns out that is because I have a “Do a search for” that includes reference to a custom state that is populated with the search location (either from the users device, or from the DB if they have specified a location previously). The delay in the browser returning the actual location meant the initial search was succeeding (as it was allowing empty values, by design) - but was shortly after updating the state when the location was available, thus triggering the search to update and LS to run the update routine.
I’m currently working around the situation by checking the initialization state of ListShifter before running the SORT, and if it’s not ready - running a “Do every x seconds” until the sort is able to run. This has resolved the issue, but it’s far from an elegant solution.
Since LS combines the Initialized & Updated functions in one event, probably not a lot of alternatives in my case?
What about a condition like, LS Initialized/Updated Only when List Shifter’s Original List Count > 0 ?
(This should handle it, I think. Also, if there’s nothing to sort you don’t need to run the sort action, which just immediately returns anyway in that case.)
I had tried setting the conditional count > 0, until I remembered the “Ignore if Empty” - so it always returns data. The issue was being caused by the delay in the location constraint being returned to the query.
I did however find a solution thanks to Floppy Expression Watcher - I basically made it perform the main query against the dataset, then trigger off the Floppy Sync and ListShifter SORT actions. If the SORT fails, I ended up adding a custom event which is triggered after a short delay of 4 seconds. This only gets run if for some reason, ListShifter isn’t ready for sort. It’s not perfect, but in testing - it was being triggered in about 2 in every 10 refreshes.
Either way, using Floppy & ListShifter together has given me a massive performance uplift in the app (it’s running 3x faster with 20x the amount of data - this was near impossible using the previous methods!). So once again, thanks @keith for both these plugins!
If you ever feel the need to release an update to ListShifter - having a separate event available for “ListShifter KW Updated” and “ListShifter KW Initialized” would would be a great addition that would probably handle this situation well. Either way, for now - it works wonders!
