XYplorer Beta Club

Hi Don,
I was thinking about this already for so long, now I simply ask it:

A Custom Event Action CAE_LocationChange (to take effect whenever the location in a XY pane changes) would be so much help for scripting customization IMHO.

I personally have some scripts that watch XY for location change from the outside. It would be so much better if XY could invoke a script in this case actively on its own.

So, now it is said. Hope you do not find it completely useless. This would really be one of my biggest wishes (no exaggeration).
But I do not want to stress you with this. Better the thought matures slowly than you being stressed.

Anybody else who would find this useful?
Regards, Stephan

In the meantime, I'd suggest a workaround (sorry if this is redundant to you, but valid for viewers after a solution anyway):

-endless/"timeoutless" script running in background (yeah, I hate this part...);
-at each 500/"x" ms get("pane"); store the value at [$ref];
-trigger if get("pane") != $ref, else do nothing.

+1
I asked this long time ago. I have to workaround using AHK:
- Push the <path> to Titlebar via ini tweak TitlebarTemplate="<path> - <app> <ver>"
- Use AHK to watch for Titlebar change:This script triggers whenever <path> change instead of checking every xx ms.
Anyway, this is still a workaround.

binocular222 wrote:- Use AHK to watch for Titlebar change

I know, because I gave you that hint back then.
Still, atm I am doing it as SF said (checking every 150 ms, though, or so in order to have a faster reaction time), because IF the path is too long then it gets truncated in the titlebar, making a reliable compare impossible, besides clogging up the titlebar like that is not really nice to look at.
Thinking of which, maybe it could help to use "short" DOS-paths instead of the full paths, making the truncation less likely. But would it then be 100% reliable, I wonder? Would have to do some testing. It surely also depends on what else is in the titlebar.
Regards

The next beta will offer a Custom Event Action that will call a script of your making before or after browsing to a new folder.

That sounds nifty. Would the script be able to execute different actions based on the new folder's location? Or, would the folder be a set location in XYplorer.ini file? If the latter was the case, you'd probably need multiple CEA entries in the ini.

No, you have to define on what folder the script reacts
The best way would to define a heredoc with all folders and their action(s) afterwards...

From the beta log:

v21.30.0005 - 2020-11-30 13:17
    + Custom Event Actions (CEA): Now you can run or load a script at the event 
      of browsing to a new folder. Note that there is no action when the current 
      folder is rebrowsed, i.e. refreshed.
      Like all CEAs, it is currently only implemented as a tweak.
      Example for the tweaked INI file:
        ; Tweak: 0=None, 1=Before Browse, 2=After Browse, 3=Both
        CEA_OnBrowseScript=1
        CEA_OnBrowseScript_Script=echo "Hi!"
      You would probably use a script that loads some script file that does 
      some interesting things. This would load "AfterBrowse.xys" (located in the 
      Scripts subfolder of the app data folder) after browsing a folder:
        CEA_OnBrowseScript=2
        CEA_OnBrowseScript_Script=load "AfterBrowse"
      To do something useful the script should know about the new path. You can 
      refer to it by the new variable <newpath>. It will return the full new 
      path, without trailing backslash. For example:
        CEA_OnBrowseScript=1
        CEA_OnBrowseScript_Script=echo "Going to <newpath>."
      If you want to call one script before and another script after the browse 
      you can pass 2 scripts separated by "||":
        CEA_OnBrowseScript=3
        CEA_OnBrowseScript_Script=echo "Going to <newpath>."||echo "Went to <newpath>."

A bit more sophisticated / user changeable...

Sounds great! I hadn't realized Don had already issued the beta when I wrote my comment. Thanks guys and Don of course.

You could probably use a switch statement for this as well.

I would recommend to resolve <newpath> before any loop. Just a habit to gain speed...

I can't see any speed improvements assigning <newpath> before the loop and do the comparison with that variable instead...

But I can because I see the code. Resolving script variables is faster. Should be. Or did you test it?

Of course I did test it before
These values vary a bit but they're always very close together and 10 ms on 10.000 runs... Neglectable...

Interesting, thank you!