I have a project set up that can open multiple desktops to be open on different monitors, etc.
Most things work great, I can open new desktops, place them, put them in fullscreen mode etc.
However, my navigation is behaving oddly. I have navigation set up with tab strips to use the swap-window method. With a single desktop, everything works as expected. After launching new desktops, the new desktops behave correctly as well, swapping windows for only their desktop. The issue is when I try to use the navigation on the main desktop (the one that initially opened with the project). It will change the window for all open desktops.
Is this a bug? Is there a workaround?
This same behavior is observed on a 8.1.35 and a 8.1.38 gateway.
I'm guessing you're using the [System]Client/User/CurrentWindow tag for your tab strips which in my testing only follows the main desktop. I don't use tab strips on my larger projects but I do track what screen is open on each desktop to remember where the user left off the next time they launch the client, so you could probably do something similar.
Just create a string array or dataset client tag and use it instead by putting a script on each main window used in the tab navigation to update the client tag using the screen index.
That tag is read-only, so the other desktops can't write to it if I understand correctly, but they can read from it. So the tag changes with the main desktop screen navigation changes, but others work because it swaps the window, but the CurrentWindow tag doesn't change, but when it does change, it triggers all the other desktops that are bound to it to swap tabs on the datachange event essentially.
Edit: Ideally, it would be nice if this were a string array instead of a single string tag that way it would work perfectly with multi-monitor setups.
That doesn't make sense either because the way the tab strips work, they only highlight the tab who's window name matches the selectedTab property, which in this case is bound to currentWindow. So, if the secondary desktops were only swapping windows the highlighted tab wouldn't change, but it does.
It does because that property changes, but the bidirectional binding won't work because that tag is driven by the Vision application, not the bi-directional binding on the tab strip. My guess (I haven't tried this) is that if you change the tab strip selectedTab property to not be bidirectional, it will still work on your main desktop.
I would think that the tab strip in swap window would work correctly on multiple desktops (as long as there's no bindings to the current window tab causing problems).
I think the issue arises when you're using other navigation in addition to the tab strip. I typically have arrows/chevrons on my flow diagrams to navigate to the appropriate screen, and if you're doing something similar or have any other navigation outside the tab strip, then you'll have to work around it by using your own client tags (like I said, a client string array tag) that you use instead of the currentWindow since it won't work with multiple desktops.
If using only the tab strip, the tabs will highlight just fine without any bindings. It's only when using other navigation methods that it won't follow. Maybe @PGriffith has some other suggestions, but I don't know that it's as much of a bug compared to a missing feature for multiple desktop navigation and only having a single string tag for currentWindow when in reality you can have multiple "currentWindows".
I too use (context) buttons like this. The context buttons have the same issue. They work just fine on the secondary desktops, but swap windows for all desktops if clicked from the primary desktop.
These tab strips that I use for navigation are actually sub-strips and I've also found that my script for displaying the appropriate sub-strip is not working on the secondary desktops. It also relies on the selectedTab property (which is bound to currentWindow). I'm guessing it's related.
Hm. This is a bit of a tangent, but I'm curious about how we could best represent the same information in a multi-desktop environment. Maybe a document tag, of { handleName: currentWindow}? A string array feels insufficient, since you wouldn't be able to tell which index correlates to your given desktop (necessarily).
Very true, I have a project coming up where instead of multiple monitors, I'll have a 4K monitor split into 4 virtual 1080p desktops, and in this case the screenIndex would be insufficient and would have to use the desktop handles instead. I haven't thought it all through yet since I haven't started on it yet, but it's been on my mind.
So ya, the first thing support said to do was to remove the binding between the currentWindow client tag and the selectedTab property. That makes the tab strip navigation now work as expected, but of course now my window-level navigation buttons don't update the tab strips.
That's quite the workaround to now try and go back and change all of my on-screen buttons and figure out a new way to display the correct sub-tabstrip.
Funny enough, I was using client tags to keep track of windows and active tab strips before but it became too maintenance-heavy and I did a bunch of rework to get to the point where everything was working with the simple window swapping scripts. Of course, now I run into this. Considering that you're even able to create new desktops, this definitely seems like an oversight and is definitely a feature that should be added.