I have been trying to use dopusrt.exe in order to get or set the lister by using for example the command C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe /acmd Go TABCLOSE PATH=c:* or another command like "c:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /info %A_Temp%\pathlist.txt`,paths
but it seems that it actually doing it only when the lister is actively open or visible. When the lister is hidden after I close it and Directory Opus is running in the background it does nothing by executing those commands. Is there anything I can do in order to execute successfully those commands even when the lister is hidden?
When I say hidden, the icon on the Task bar is not present, but the icon on the System tray is present. The lister is not minimized it is closed therefore it is not available on the task bar. If I double click on the desktop I can bring it back into focus. Since it is said in the help file that it is possible to manipulate Directory opus using the dopusrt.exe I would think that it should be possible to run internal commands even when the lister is not shown.
Launching Opus -> Default Lister -> Update Default Lister automatically when closing a Lister
Launching Opus -> From the desktop.. Bring the last active lister to the front
So if I close a lister it is automatically saved, and when I double click on the desktop I get the last lister that I have just closed. This last lister is not destroyed it is the current one but it is hidden. What is the use of external manipulation of Directory Opus if you can't manipulate it when it is closed but still exists?
No, it is destroyed. If you close the window, the window is not hidden, it is gone. Commands that act on a window have nothing to act on if no windows exist.
Just because you can make a new window, that uses the same settings as the old one, does not mean the window still exists after it is closed.
Each window is independent. You can have zero windows open, or one window, or you can open more windows. There isn't a single "always in existence" window that all commands operate on; there are as many windows as you have open, or none of you don't have any windows open.
You need to leave the window open if you want to be able to run commands on it. If you don't want to see it on screen, minimize it rather than closing it.
(You can run lots of other commands when there are no windows open which will work fine, e.g. commands to open new windows or to do things like, say, copy files from A to B, which work whether or not there is a window open. But you cannot run commands that modify a window when there isn't a window in existence to modify.)
This is semantics. Since when I double click on the desktop I can still get the last lister back. The window is gone but there are variables in your program that still holds the lister including all the tabs in this lister. So if you are referring to the last lister it is still exists.
Anyhow I have just found a solution... If I wanted to close all the tabs on the C: Drive by using external manipulation of the lister although the window does not exists anymore, what I did is running this command: C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe /cmd Go NEW ,min . It opens the lister with it's tabs but minimized to the Taskbar. I then run C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe /cmd Go TABCLOSE PATH=c:* and after that closed the lister. I have used Autohotkey to run those commands.
I think it is semantics. Because for the end user, when he closes the lister he knows that if he double click on the desktop he will get it back with all it's tabs. He does not care if internally the program is terminating the window. If he runs the command externally to close all the tabs that have the C: drive he is referring to this lister that he just close. For his point of view if he makes a button on the lister that close all the tabs that have the c: drive, when he press this button when the lister is opened it will close those tabs. There should be no difference if the lister is closed or opened. If he for example make a GLOBAL hotkey in Directory Opus that close those tabs, if he use this hotkey when the lister is open it will close those tabs so why when the lister is hidden (the window is gone) the hotkey will not work? The application still know everything about the lister although physically the window does not exist anymore.
If you close a Lister it no longer exists. I'm not sure how else to explain it. Just because you believe that it works differently doesn't change how it actually works.
I don't believe in anything. I am a software engineer also. If the lister does not exist then why it come alive with all it's tabs and tool bars after you double click on the desktop? The current configuration of the lister does exist inside the application although the window is gone. It's because of how you design your UI not because that the lister configuration can't be recalled. I call it "Hidden Lister" and for the end user the current lister is hidden but comes back after he double click on the desktop. Thats why I say that external manipulation of a lister should be available to the user even when the lister is hidden. If he wants to be able to manipulate it's tabs he should be able doing so when the lister is active or hidden. It is just less restrictive and more natural for the user than the current design.
Another Lister gets recreated using the same configuration.
I was running Microsoft Word earlier today, and then I closed it. If I start it again, it comes back looking exactly the same as it did before. This doesn't mean that it was just hidden, waiting for me to reactivate it.
One default, potential, configuration exists inside the application. When a new Lister is opened it can use that configuration or it can use a different configuration.
Actually, your "design" is more restrictive, because it presupposes that there is only one single Lister, whereas in fact Opus allows you to open as many Listers as you like, and they can all be different. What would happen in your design if you opened two Listers, with different tabs, and then closed them both. Which one would your commands operate on? Which one would be the "Hidden Lister" ?
Call it whatever you like, it won't change the fact that it doesn't actually work as you seem to think it does.
Consider the case where you have two windows, both open at once:
[ul][li] Clearly, they are not both the same window, even though they may both have been created from the same stored settings.[/li]
[li] You can open one tab in the first window and close another tab in the second window, and changes in one window do not affect the other (nor would anyone want them to).[/li]
[li] If you keep the two windows open and open a third window, that new window is not the same window as the other two.[/li]
[li] If you close the three open windows and open a fourth window, that new window is not the same window as any of the previous windows. There also are not now three "hidden windows" sitting around waiting to be re-opened; the closed windows are gone.[/li]
[li] If you close that window, there now are no windows left, and no "hidden windows".[/li][/ul]
It's that simple.
Yes, it would be possible to have commands which directly modify the "default lister" settings which are (normally) used as the basis for new windows, but that is not what the commands do. It is not what they were designed to do and it is not what they are documented as doing. It is not what anyone else has ever expected or asked for them to do, either.
The commands in question modify the active (or most recently active) window, and if there is no window then they don't do anything.
That is how the program and commands work. If you can't accept that and think the problem is in the semantics of how we are describing things then I don't know what to say.
I am sorry but I don't understand you. If you open multiple listers the last lister that was closed it's layout is remembered and when you double click on the desktop you get that last one back. It was the last active lister. So why you think that closing some tabs using an external command on the last active lister hidden or not is restrictive?
Actually one of the reasons that I need to close tabs are because that after an extensive use of a lister by opening many tabs it gets cluttered by the same tabs (there are multiple tabs with the same path). I am trying to make a scheduler and make it as transparent as I can and not to show or restore the lister window while it is hidden in order to cleanup those multiple tabs and leave only one instance per one path. I guess that you could have done that as well. I am sure that I am not the only one who faces this problem.
Maybe what you want is to set up the defaults with a minimum number of tabs, then turn off Preferences / Launching Opus / Default Lister / Update Default Lister automatically when closing a Lister so that the defaults stay that way and do not get overwritten when windows are closed.
...I don't think anybody is criticizing your goal here. The goal itself makes sense, but you're trying to reinterpret how the program actually works in order to make your choice of trying to use this feature to help you achieve your goal make sense, and it just doesn't. By now, I think its been made abundantly clear that except for some exceptions (like trying to open a new folder which would necessitate a new window having to be opened if none are currently open), the dopusrt /acmd command actually operates on an open lister 'window' and not against the saved configuration file that remembers the last closed listers settings.
I actually agree with your response to Leo about if you had multiple listers open, that the last one you close would be remembered in the 'default' lister config if you have the auto update option set, so I think that was a poor example with which to try and explain the principals at play here. I think the help manual content on the dopusrt /acmd command option is helpful here though:
With this description - I would suggest that the PRIMARY intent of providing a command to let us operate on the 'last active lister' was to allow us to run Opus commands from an external app against the intended lister window IN THE CASE WHERE MULTIPLE LISTER WINDOWS ARE CURRENTLY OPEN. I'm not shouting ... just using caps for emphasis.
Compare what happens when you run something (even an external app) from a button on a toolbar in a lister. Which lister window context to run that action on or within isn't ambiguous in this case, as you're initiating it from an Opus lister window to begin with. As an opposite example, say you set up a hotkey or Windows shortcut or something else completely external to Opus (AHK being a good example) and you do in fact have multiple listers open. The external app itself will certainly have no way of knowing on it's own which Opus window to send it's dopusrt commands to, so GPSoft gave us this command to allow Opus to figure out which window to run the command against, which very often might in fact be the 'currently' active lister window.
On a related point, I myself don't really use the 'Default Lister' very often... I use my own saved lister Layout for double-click on both the desktop and tray icon in order to open new lister windows. I sometimes still leave the auto-update default lister option turned on, but for a specific purpose. That being, while I normally want a static lister config every time I open a new lister - I do sometimes unintentionally close a lister with a bunch of tabs open that I still needed to work in. In that case, I then go ahead and open the 'default' lister which was just auto-updated when I mistakenly closed the lister. But again, I don't normally use it to launch new lister windows.
The only reason I'm mentioning MY particular use-case to you is to illustrate that even if we all get past the terminology and disagreements over semantics vs not-semantics, in my use case - your assertion would result in a situation that would be confusing to say how it should work. If I had no lister windows open, which lister configuration should be operated on by the type of commands you're trying to run? The 'default' lister or my 'custom defined layout' which is what I primarily use to open windows, and why would one be right and the other wrong? This relates back to both Jon and Leo mentioning that there are multiple listers configurations (layouts) that people can load to open new lister windows, as well as Leo mentioning that they could indeed potentially offer 'another' command which could modify or update a saved lister configuration (layout). The scenario I've just described where someone intentionally uses MULTIPLE layouts (the default, and user-defined 'saved layouts') would then necessitate the ability for users to specify exactly which layout to update in order to be useful.
The bottom line is that I think you ARE in fact one of the only people to consider this a problem. The command you're trying to use wasn't intended for the purpose you're trying to use it, and I don't think there's a way to MAKE it work the way you want without there being some ambiguity in use-cases like my own. That it doesn't work the way you wish it did doesn't negate the use of the feature to enable "external manipulation of Directory Opus" across the board like you've questioned... it's just your one use-case so far that isn't satisfied by how it was implemented. And it was implemented based on specific user requests, and those users are happily using the feature for the purposes that drove them to request it.
But there's always room for refinement and change as new use-cases present themselves. Hopefully GPsoft will consider adding yet another command - say an /updatelayout="Default" argument to do what you want. Then you could run BOTH the /acmd command (in case there is in fact an open window you want to operate against) as well as this type of potential new command (for your current case).
FWIW: your example of running TABCLOSE PATH=c:* is different than your stated goal of cleaning up "those multiple tabs and leave only one instance per one path". The TABCLOSE PATH=c:* command will remove any and all tabs that start with the c:\ path... not "just" duplicate tabs. What you've suggested here is something I think is a good case for yet ADDITIONAL enhancements though. Perhaps a TABCLOSE=dupes option to clean up any duplicate tabs, so you don't need to use an external tool to find and remove duplicates - which is maybe what you were trying to do with the /info, paths stuff? Anyway, in the meantime, you might be interested in ways of preventing opening duplicate tabs in the first place. Take a peek at the help manual on the "TABFINDEXISTING" and NEWTAB=findexisting options... and open a new thread if you have questions on them and how they might help you a bit in a different way.
It's not a poor example at all. The command works on a window, but if you have closed all your windows then there is no window for it to work on, so it does nothing.
The stored configuration data, which may be used to create a window in the future, is not a window itself.
It's like confusing a cake recipe with the cake you might make by following the recipe. You can eat the cake but you can't eat the recipe (unless you like eating paper ).
For a guy who is hung up on an auto-updated default lister layout still being equivilant to a 'hidden' lister window which he thinks the command should be able to operate on... I thought it was better as an example of the need to differentiate between multiple open windows, but that your comments about how the windows were related to the stored configuration data likely fell on deaf ears. And from his response to your example, it certainly seemed like he just read the 'multiple open windows' part and jumped right back to his situation of not having any windows open .
You've both very clearly stated numerous times that the dopusrt /acmd command doesn't operate against the stored configuration data for the 'default' lister layout, and the ongoing and usual good-hearted attempts to educate and explain seem to be going in circles.
So, I thought it would still be useful to provide an example that had nothing to do with any open windows at all, and instead focused on Jons earlier comments about the 'default' lister layout being only one of potentially multiple layout configurations one might use to open a new lister window. My own use-case is a very good example of that, and shows that expecting the dopusrt /acmd command to affect the stored configuration data for the 'default' lister just doesn't make sense once you understand that people can use configurations 'other' than the 'default'. If nothing else, I figured that line of conversation would get us away from the seemingly endless debate over his belief that an auto-updated stored lister configuration should be equivilant to the last active lister window. I think the possibility of having multiple configurations to open listers from is a much better rationalization to why what he's trying to do wouldn't make sense... even if you decided to change it to work how he wanted. Why would such a command operate on one layout configuration vs another?
Well, your personal default lister may come from a layout, but there is the concept of the Default Lister and an option to update it automatically when closing a lister.
I never thought about this before, but I believe that that option must actually update the definition (the recipe) since the lister (cake) may not exist anymore. That option doesn't, I don't think, update your layout (personal recipe?) which apparently defines your personal default lister. So a potential command to update a saved configuration could be designed to update the configuration for the Default Lister, the same one apparently updated my the mentioned option.
I'm not necessarily arguing that there should be such a command, but if there were the seemingly well defined concept of Default Lister could be used to determine what would be updated.
... just using caps for emphasis.
.