Limitations
Limitations
One File at a Time.
BackMagic (BM) maintains one "stack" of navigation history per file. (This is because the navigation stack is stored in a global variable and such variables are scoped to the file.) So, if you have a multiple file solution, each file will have its own back stack which will work great within that file, but clicking "back" will not take you from one file to another; you'll simply empty the back stack in the current file.
All New Windows Share the same Navigation History.
BM does not maintain a separate navigation history per window. (Though I imagine that if you prefaced our variable names with the window name, it would.) So all new windows within a solution share the same back stack.
Active Tab Display.
BM records all navigation through native tabs on a layout. So if your layout has native tabs A, B, and C. If you click from tab A to tab C, clicking back will take you to tab A. However, the word "back" (and the green arrow accompanying it) don't actually know to change color just because you click from one native tab to another. In this case the display of BM's button state hasn't refreshed as you move from native tab to native tab. Most users will never notice this because there is almost always something in the back stack anyways, so "Back" is almost always lit.
If the first layout of your solution has tabs and is exhibiting this behavior have your opening script take users to another layout first (like a splash screen) and then to your first main layout so there will be something in the back stack on startup.
Adjust Window.
Less of a limitation than just something to be aware of... if you are navigating using your own scripts you'll want to be sure that you go to your destination tab before calling the Adjust Window script step. Otherwise, the Adjust Window script step will cause BM to record the current tab as a "location" and will then record a second location at the end of your script when you arrive at the right tab.
