XYplorer Beta Club

Posted: **02 Jun 2014 00:10**

admin wrote:Not possible even for me...

Oh well too bad. Using "DUAL:" command as I reported near the end of this thread http://www.xyplorer.com/xyfc/viewtopic.php?f=3&t=11757 actually worked consistently with absolutely no "Dual pane flicker" at all.

Code: Select all

goto 'DUAL:||C:\';#800;

I don't know if it surprises you, but it certainly did me. If I set pane 2 on some tab other than tab #1 which for me is C:\ and then return to pane #1 and run the above command it will change the pane #2 tab to C:\ (my tab #1). Now however with the recent layout changes there is some "Dual Pane flicker" but not all the time...not sure why.

Also, shouldn't ::goto 'DUAL:||seltab 1'; work. It doesn't seem to be working for me anyway in the AB or in a script.

Posted: **02 Jun 2014 02:21**

klownboy wrote:Also, shouldn't ::goto 'DUAL:||seltab 1'; work. It doesn't seem to be working for me anyway in the AB or in a script.

I cannot verify right now but you may need to make it explicit that the location is a quick script by including the '::' and ';':

Code: Select all

::goto 'DUAL:||::seltab 1;'

Posted: **02 Jun 2014 13:53**

Once again thanks TheQwerty, the double colons before the script command does the trick. So this works - to set Pane 2 to tab #1 and return to pane 1 in the AB. [In a script you lose the first pair of colons of course.] Note the need for a second semi-colon for another command which makes sense.

Code: Select all

::goto 'DUAL:||::seltab 1;';#800;

I was thrown off by the this thread here Dual Location where Don had given this example:

Code: Select all

DUAL:tabset("load", "Bat");||tabset("load", "Man");

I don't have multiple tabsets to try it, but I assume he inadvertantly left out the 2 colons.
Thanks'
Ken

Posted: **02 Jun 2014 22:26**

Please sir, I want some more.

This wish comes with free documentation!

History.txt:

Code: Select all

    + SC get got a new named argument "listofcommands".
      Syntax: get("listofcommands", [flags], [separator=CRLF])
        flags: (bit field)
          1 = Prepend Command IDs, separated by a TAB.
          2 = Append Keyboard Shortcuts, separated by a TAB.
        return:       The list of all commands.
      Examples:
        text get("listofcommands");
        text get("listofcommands", 3);

CHM:

Code: Select all

<Under:
::help('idh_scripting_comref.htm#idh_sc_get');
>

"listofcommands", [flags], [separator=CRLF]
Returns the list of all commands.
flags: (bit field)
 1 = Prepend Command IDs, separated by a TAB.
 2 = Append Keyboard Shortcuts, separated by a TAB.
return:       The list of all commands.
Examples:
text get("listofcommands");
text get("listofcommands", 3);

Posted: **03 Jun 2014 16:07**

Hm, what's the use of this?

Posted: **03 Jun 2014 18:14**

admin wrote:Hm, what's the use of this?

What could be done...
I'm working on a script* and could use this to generate a simple "script" builder by stringing together CIDs.

Alternately, it provides another means of accessing the list of commands, even allowing the possibility of creating custom filtered menus. (Menu of all Copy commands, or Rename commands.)

It would also allow someone to write a script that diffs this information between versions to show what's changed or to create custom cheat sheets for keyboard shortcuts.

Why these are difficult to achieve today...
There is no good way to retrieve the list of commands (with CIDs) via script.

The best solution I can think of is instruct the user to open the List of All Commands, while holding CTRL, copy the contents, close the dialog, and then run the script again. This would need repeated until the clipboard contents matches the expected format, but it would still be impossible to detect if they copied a filtered list of commands.

Another option is a painstakingly slow while loop that collects all commands which return something for Get('MenuCaption', $i).

In either case, this would need repeated each time XY is updated to account for command additions or removals, and that's ignoring the complications from UDCs.

*The script itself is actually a feature request I've held off making. I figured the surest way to get it into XY is to write a script that you can render useless shortly after release.

Posted: **03 Jun 2014 21:45**

Excuse the double-post to trigger New Posts status...

Recently I'm finding the extension parameter of InputFile frustrating because there's no way to specify multiple filters. Thus there is also no way to provide an "All Files" option to fallback to when the supplied filter matches nothing.

Some thoughts on possible solutions:
1) Allow extension to be a CRLF-separated list of filters and allow some way to specify all files. ('*' or '*.*'?)

2) Add smartness to extension or a flag parameter to optionally show an 'All Files' filter after the specified one.

3) Add smartness to extension or a flag parameter to disable XY's smartness and allow entering filter strings in the format expected by OpenFileDialog for the extension parameter. In this case the first should be the selected one so FilterIndex is 0. ('Image Files (*.gif, *.jpg, *.png)|*.gif;*.jpg;*.png|All Files (*.*)|*.*')

I'm partial to 3 as it gives the most flexibility but I can make any of them work for me.

Posted: **04 Jun 2014 07:30**

Could you keep both somewhere in the back of your mind? I currently cannot squeeze it in, sorry.

Posted: **04 Jun 2014 15:11**

admin wrote:Could you keep both somewhere in the back of your mind? I currently cannot squeeze it in, sorry.

Thoughts on when will be a good time for a bump? (After 14.20? In two months?)

Posted: **04 Jun 2014 15:20**

Autumn.

Posted: **11 Jun 2014 16:34**

Any chances to expose the variable containing the tagged items. I am basically looking for a slimmed down version of the undocumented SC edittags

EditTags offers too many features to my likings

Posted: **11 Jun 2014 16:37**

No such plans.

Posted: **07 Jul 2014 16:40**

I would like an ability to reference a specific script within a multi-script command. The main use case scenario here is to have an array of various scripts as a toolset and then being able to refer to an individual "tool" without copying the relevant code. The toolset would have a command ID, so being able to refer to a specific tool either by its order in the toolset or caption would be great.

Posted: **07 Jul 2014 16:55**

Isn't what you want described at page 432 of the Help? Script Files for the Advanced - Labels

Posted: **07 Jul 2014 17:27**

Marco wrote:Isn't what you want described at page 432 of the Help? Script Files for the Advanced - Labels

Close, but no cigar. According to Help, calling scripts based on labels requires them being saved in an .xys file. This poses a bit of an issue to me, since I have them in a UDC "Run Script" window. No, I will not save them to a file instead. Just to pre-empty what I suspect will be said

XYplorer Beta Club

Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)