Ah... wow, Tabs vs Toolbars... hee hee. Ok, in addition to what AB had to say - I think responding to your first post since my last reply should answer all the question, first - re-iterating my previous statement that toolbar on/off state is not something that is "saved" in ANY "lister".
Also, reading a bit ahead into this post, I think we need to distinguish some terminology between creating, changing, and turning toolbars on/off... When you "create" a toolbar while in Customize mode, it also turns that new toolbar "on"... "globally". A "global" toolbar means that it's turned "on" for any lister that you open, and that "on" state again is not tied to a specific lister (and again, I'm assuming each time you refer to a "named" lister - that you mean a saved lister "layout"). This is what's driving the effect you're seeing that AB has described to you...
Again, I think maybe a terminology goof here... "changing" toolbar Chev means you've "modified" that toolbar... added/removed/modified a button or menu item on that toolbar. So if you make a "change" to a toolbar (different than turning it on or off) then any time you turn that toolbar back "on" the "change" should remain...
Now you're saying "added"... which I assume to mean you created or turned "on" other toolbars. Whether they should "appear in the next lister" you open or not depends on how you turn it on. I mentioned above that when you "create" a new toolbar in Customize mode, that it get's turned on "globally", and will re-appear with every lister you open after. That said, you can also turn a toolbar on "locally" instead of "globally". "Local" toolbars only appear in the lister that is active when you run the related "Toolbar LOCAL" command from a button, hotkey, etc... That means if you have multiple listers open at the moment, the "local" toolbar only appears in currently "active" lister, and also won't appear in any new listers that you open.
[quote="amerifax"]Also is there a dedicated file that hold's the Lister's not that this could be the issue - I'm just thinking of other possibility.
"ToolBar" can be used in many listers . I would think that the name of a "ToolBar" is unique.[/quote]
Again... assuming that by "Listers" you mean saved Lister "Layouts"... yes, lister "Layouts" are saved in layout specific "files" in the /dopusdata\Layouts folder... but also again, lister layouts do not include toolbar on/off state. The differences mentioned above between "global" vs "local" toolbars only affect either "ALL" listers or the "currently active" lister. This is different than saving a lister layout that includes specific toolbars being turned on or off for and having that take effect when you go to load that particular layout again.
What I "think" you're looking for there has been requested by some of us for awhile, and would be useful in cases where the reason you save a particular "layout" is to perform work of a certain type where you might want specific buttons available (and not others) for the work and tasks you're creating the layout for... but we don't have that functionality yet. To your "bewilderment" at layouts not currently working this way... well, they just don't - . Layouts currently store other types of info... folder/tab positions... single/dual pane file displays, folder format (view mode, columns displayed, etc) of folders/tabs saved in the layout, and other things. If I'm interpreting what I "think" you want, then I generally agree with you... as I suggested above, I think it'd be VERY nice to have specific toolbars saved in layouts that you define for specific tasks and workflows.
However, I think some changes were made in v10 (maybe before then, can't remember) that make it a little easier to achieve a similar affect. You can create a button or hotkey, or tray icon item or whatever to load a layout, and then "locally" turn on toolbars in that new layout you're opening. Here's an example using a bunch of my toolbars:
Prefs LAYOUT=Tutorial
Toolbar LOCAL NAME=my.MediaTools
Toolbar LOCAL NAME=my.DiffTools
Toolbar LOCAL NAME=my.eBooks
Toolbar LOCAL NAME=v10.Drives
Toolbar LOCAL NAME=my.Comics
What I think used to happen if you tried a command like this in older version of Opus is that maybe the extra toolbars got opened in the "current" lister instead of the new lister layout you were opening with the first command. At any rate, this method still has some drawbacks...
a.) It can only be used by some manual mechanism... since it's not truly saving the toolbar state "in" the layout itself, this means you can't get this to work using the built-in methods to load lister layouts - like the menu when right-clicking on the desktop, or elsewhere in Opus where the list of layouts is automatically generated. You have to create specific buttons/hotkeys/etc with the necessary commands like those above.
b.) You can't "locally" turn "off" any toolbars in just the new lister layout you're loading that are currently turned on "globally"...
This may be my longest reply yet ... Does any of this help close the loop? Are we talking all the same thing now ...?