XYplorer Beta Club

the correct line should be or

StringReplace, path, path, file: doesn't do anything? Where in the code did you add it?
And why do you think that StringReplace, path, path, file://, should work?

doesn't do anything, this line is in your script
you can try to display the path variable before and after this line
you'll see by yourself
WE have file:// in the path so file:/// doesn't trigger the replace
or are doing the trick
replace is triggered and file: is removed from the path

So, finally I am back for now.
Couldn't check it before in the source because I was away, sorry that it took so long.

You are right, StringReplace, path, path, file:/// is in the code, but it is a function which I copied from someone else. Therefore I did not remember / know it when I answered at first.

I added StringReplace, path, path, file://, // for the next release.

No doubt, mine was just reproducing local XY conduct yet it didn't generally make a difference to me as long as it implied that WE weren't opened. Then again, my content doesn't expect XY to be open so it's a tad of a compromise with either content. I do LOVE that yours chooses the document since that is perhaps the greatest inconvenience about XY (despite the fact that I'm generally diverting to an organizer, not a record) at the same time, for me in any event, it doesn't look over the record into seeing. Is that normal conduct and, assuming this is the case, would it be able to be changed? Provided that I despite everything need to look to the document then it diminishes the advantage of having it preselected. Good health.

Hello hankr123 and welcome to the forum!

Thanks for replying. It keeps me motivated to keep working on my script.

Unfortunately, I don't understand most of your post.
Could you, please, give it another try to explain. I would love to help and improve my script, but I don't really understand, so far, what you really need/want.

Regards, S.

Hi, I've been using this script for a while, it works great, but there is some delay between closing the explorer window and opening xyplorer, is this normal or is it just my problem?

Execute this from the address bar after you've had such a delay time and show the results

highend wrote: ↑12 Jan 2021 19:44 Execute this from the address bar after you've had such a delay time and show the results

Code: Select all

text get("loadtimes");

That could already provide hints.

Another thought is, does this only happen when XY is not running and, thus, the script is kicking XY to start up first, or are the delays also happening when XY is already running in the task bar?

From your answers, I deduce that it's probably my problem. I am attaching a gif of the problem: the duration of the explorer.exe screen depends on the workload of the pc, in this example I had nothing else open, but sometimes it can even last 1 or 2s.

Sorry for the delay in answering. I had not gotten any notification about your reply.

From your answer, I deduce that XY is already running.
I was asking because in the case that it is not running, XY is first started up and that would explain a delay.

However, it sometimes happens to me too, that, even when XY is running already, the Windows Explorer window stays open for 1 or 2 seconds before it gets redirected to XY.

Still, since this happens to me rarely, and the same view gets redirected much faster on consecutive redirections, it did not and still does not bother me enough to investigate the reason, especially since I would not know what it could be. If you can convince me with enough credibility of why it is very important, then I will try to investigate the issue further.

autocart

This script looks as if it will do the job nicely.

Thank you for pointing out this to me.

Wfeg

wfeg wrote: ↑01 Feb 2021 07:21autocart
...
Thank you for pointing out this to me.

For the record:
It was highend, who pointed it out:
viewtopic.php?p=184895#p184895
Thx, highend.

Alrighty, folks,

A new version is out, roaming the streets:
viewtopic.php?f=7&t=10671

I also rewrote the help in the first post and, thus, also inside the script itself.
I am always happy about feedback, positive and negative.

The most noteable changes are:
-) So far, the focused control in XY did not change after a redirection. It was mere chance whether or not the list had focus.
Now it can be specified whether the list in XY should automatically get focus after a redirection, in case some other control of XY has focus. This can be useful, because if the list does *not* have focus, then any selected items might visually not be distinguishable so easily.

-) Redirected WE paths can now be opened in separate (new) XY read-only instances or still in the normal XY window as new tab, as before.
For such read-only instances, a different ini file can be specified, so that these instances have a different layout.
Details in the help.

Couple of small changes to the system tray context menu:
-) Added an item in the tray menu, that activates or deactivates (on the fly) the hotkey for manually redirecting XY tabs to a new WE window (the other direction than usual). That hotkey could already be specified in the config file of the previous version. I just added the corresponding item to the tray menu, as it was already there for the a similar hotkey.

-) The tray icon context menu can now be opened also with a single left mouse button click on the tray icon. Before, the context menu opened only with a right mouse button click.

-) Changed the indicator symbol in the tray menu for the suspended state from a check mark to a big fat dot. This way it might be less confusing, since the meaning of the other checkable items is slightly different, plus their logic is reverse too (namely check = hotkeys are "on" but with the suspend item it means check = script is "off"). Just a little tiny experiment. (FYI, other indicator symbols for the tray menu items are, it seems, not available in standard AutoHotkey.)

-) If a hotkey is not defined, then in the previous version no tray menu item was generated for them. Now, the tray item context menu will still generate an entry indicating that the hotkey could be defined but has not been. (BTW, the Ctrl-Hotkey for manually avoiding redirection is, so far, hard coded / not user definable. Right now it can be de-/activated, but only through the tray icon context menu at runtime. However, this is on the to-do list, to "raise" specification, and thus de-/activation also to the config file.)

And other internal changes. Full change log in the first post.

Thanks for the hard work!