WatchTab and values returned by Msg.data

Help & Support
1

Greetings. A video demonstrating what i'm trying to acomplish:

To achieve that (disable when changing to other tabs, autoupdate when lister refresh, close when changing tab path), it is necessary to use tab.Update after each tab event. I don't know the impact this may have on performance, but for ease of use and tracking, as it seems that in those cases msg.data has no use (always returns 0) could you please consider adding:

For activate :
It would be great if msg.data would return the ID (as text) of the active tab. Then you could compare msg.control with msg.data to know if the watched tab is active or not.

For navigate:
msg.data could return the value of the current path in text form. Then you could compare a previous initial saved path (or tab.path as string) with msg.data to know if the path has been changed or if it is only the tab refreshing.

Thank you!

2

A separate property - e.g. msg.tabid - would be useful. The way I currently track tab changes is:

DOpus.Listers.Update(); // Lister(s) might have been added or deleted
var cur_lst = DOpus.Listers.lastactive;
cur_lst.Update(); // Tab(s) might have been added or deleted
var cur_tab = cur_lst.activetab;
3

Performance looks fine in the video. Creating/updating the tab object on folder change or tab activation shouldn't be a big problem. The overhead of that will probably be dwarfed by other processing the script has to do.

Not sure I understand the rest. The Msg object gives you both the tab ID and the tab object already. You can get the tab path from the object.

As long as you avoid accessing the tab object until you know the event is one you want to handle, it shouldn't be a problem to use that directly. If you need to access it multiple times, store it in a variable to prevent it being created more than once. (Not 100% sure if that's necessary, but the documentation seems to say so.)

4

Thank you Leo. I haven't noticed that either. My concern was more towards the cases where they use it with 200k+ files, and the impact it could cause on the usage (I imagine that the more files, the longer it takes to update the tab object data), just to know if the tab is still the active one or in the same path. But if it is infimum, then I think there would be no problem.

That's what I'm doing at the moment. And of course you can access that data via the tab object, but first, always (talking about the cases of activate and navigate) one must use tab.Update, otherwise the changes are not reflected. And that was my suggestion, if msg.data would expose the above mentioned data, there would be no need to update the object first.

5

So Msg.tab is stale data on entry to the event/function? Or is the script making changes which it then needs reflected in Msg.tab within the same event/function?

Is there a small example script that shows the issue?

6

I had not considered using msg.tab, since according to the manual it says:

Calling this repeatedly may be inefficient.

But, between msg.tab and having to use tab.update, which of the 2 is the most suitable/efficient or is there no appreciable difference?

I just want to get :

For navigate : the current path after the event (currently I use tab.update and then tab.path to compare with a previously saved initial path)

For activate : If the active tab is the watched tab (I use tab.update and then compare tab.lister.activetab with the watched tab).

(When I refer to tab, it is the one obtained by scriptcommanddata.func, not msg.tab)

7

I'd expect them to be about the same.

The main thing is to store msg.tab in a variable the first time you need it, then access it via that while processing the msg/event, rather than access it via the msg object repeatedly during the msg/event processing.

Ah, now it makes sense why it needs updating. It will be a snapshot made when the script command started.