AHK-script for MiniTree - automatic expanding and collapsing

[binocular222]

This is the way Minitree should be

[autocart]

This is the way Minitree should be

Thx, bino.
I will try to implement your wishes, SF.
But if you, bino, or anyone else has any further suggestions, please do not hold back. Thx again.

[SkyFrontier]

So far the point was about expandability.
All things considered, tracking history would be a nice addition as it seems to me that adding the possibility (ie, ON or OFF) to add each visited location to a per-tab MiniTree could turn this the ultimate MiniTree concept.
Summarizing, current folder would have all expandability the script delivers, plus each visited branch could be there for easy navigation - the purpose of the original MiniTree. Switching this On or Off is desired as according to the task it may be distracting to have history listed, or a plain time saver.

Thanks for the effort put into this, Stephan - nice re-feature!

[autocart]

...tracking history would be a nice addition ...

I was thinking about this for the last couple of days myself.
However, a history with the tree structure seems to me to risky of cluttering the tree again. But I would like to have it in the tree, always visible, since the Toolbar is too much mouse movement and clicking away.

Therefore I have the following idea:
1) I define a max. count of folders in the history, so it does not get too big and stealing space again.
2) I designate a special folder, where I want to store the history (why -> see below)
3) For each folder that should be safed in the history (filter-algorithm can be thought of), I create a symlink in the special folder (naming-algorithm can be thought of)
4) I "subst" (DOS command) this special folder with it's own drive letter, thus it is shown in the tree in its own "space" (like a drive) and has as direct subfolders (w/o a cluttering tree-structure) the symlinks to the history-folders (all in the tree!)
5) With the script I will redirect browsing one of these symlinks to its actual target folder.

Pros: History in the tree (always immediately easily available), that does not use up "much" space (depending) and by way of the custom drive letter it would also be "positionable" in the tree.
Cons: Only limited space for name of symlink (to describe the path) and of course maybe the fact itself that symlinks are used (only for Windows Vista and later; also depends on whether the user likes it or not?)

Does anything else speak against using symlinks in this limited usage-environment (besides that it will only work for Windows Vista and later)?

Or is this anyway a totally misplaced idea for you, SF and other guys, to combine the tree with such a "compact" history?

Thanks for the effort put into this, Stephan - nice re-feature!

Thx for mentioning. I am glad doing it at the moment.

[SkyFrontier]

The plan looks nice & smart, Stephan, but I have no symlink support on some of the machines I plan to use this.

[autocart]

Well, I was also thinking of junctions but Wikipedia said they only support paths on the same(?) local drive.

However, thinking about it, actually there is no need for special symlinks nor junctions since I can dedicate that special folder to the scrpt's needs ONLY, saving the history items as normal folders there. Then I can check each browsed path for this special folder and still redirect browsing by way of the script.
The target would have to be saved somewhere also. It's not AS neat but it should do the trick.

[autocart]

Do you have support for DOS commands, though?

[autocart]

Another question , coming back to multiple instances. I was thinking what you might have meant with the paths of the instances. Could it be that you have multiple XYplorer.exe files in different locations, starting each instance from another XYplore.exe?

[SkyFrontier]

Another question , coming back to multiple instances. I was thinking what you might have meant with the paths of the instances. Could it be that you have multiple XYplorer.exe files in different locations, starting each instance from another XYplore.exe?

Sometimes they are launched by xyexes, sometimes not. Always on diff paths.

Do you have support for DOS commands, though?

Yes, I do.

[autocart]

Always on diff paths.

Arghl, You keep saying that and I keep not understanding what that means.
Can you not spell it out for me? Do you mean the path of the XYplorer.exe or the path that is displayed inside XY? Or what??
Please, if you are not more clearer in your statements (sorry that I am so dumb), it is very hard for me to adapt the code to your needs.

EDIT:
Besides, how can a XY instance not be launched by XYplorer.exe? Maye you and I understand something else under the term "instance"? 1 instance of XY for me is a whole XY-window with all it contains (tabs, list, tree,....). A 2nd instance would be a whole 2nd window by itself (with its own set of tabs, list, tree, ....).

[SkyFrontier]

Hi, Stephan!
Well...

Another question , coming back to multiple instances. I was thinking what you might have meant with the paths of the instances. Could it be that you have multiple XYplorer.exe files in different locations, starting each instance from another XYplore.exe?

Sometimes they are launched by xyexes, sometimes not. Always on diff paths.

I work with single, unique instances almost all of the time. Each unique instance has, therefore, its own xyexe path.

c:\temp\xy_v0001\xyexe
c:\temp\xy_v0002\xyexe
c:\temp\xy_v0003_Test\xyexe -- this is the instance I'd like AHK to intercept. The other, MT on or off, should not be touched when put in foreground.
d:\temp\xy_v0001\xyexe (yes, the same .exe as c:\temp\xy_v0001\xyexe, but copied under d:)

Sometimes one of those exes are launched by an xyexe via list, script or something, sometimes by shortcuts on desktop for instance. Currently your AHK affects all of them.
A SECOND INSTANCE OF THE SAME .XYEXE CAN BE LAUNCHED when needed,but if you tell me this would make it difficult for you to work with a second INSTANCE of the same .xyexe, I can avoid that.

[autocart]

ok, I understand now

yes this is possible. stating the path that should be used by the script in the ini file. I will try to implement it within the next days.

I can also limit the effects to the first instance of the same XYplorer.exe, if that is an advantage to you. Yes/No?

[SkyFrontier]

I can also limit the effects to the first instance of the same XYplorer.exe, if that is an advantage to you. Yes/No?

-oh yes, please!

[autocart]

ok, thx for bearing with me, now I have the info I need for right now. I will try to implement it within the next days.

right now, I implemented a visual aid for identifying the XY instance that is "treated" by the script (for next version).
The script adds its name and version nr. to XY's title bar (appending it at the end).
On "normal" script termination it deletes this appendix again (obviously not if the script gets "killed", but in this case XY anyway refreshes the title bar often e.g. on a path-change).

[autocart]

I will try to implement it within the next days.

Sorry for the delay, folks and SF. I had "planned" to work on it more during my vacation... But I did not forget.