XYplorer Beta Club

j_c_hallgren wrote:When I press Enter, nothing happens...If I have the same exact script entered as another entry on "Run Script" directly, it works...am I missing something or is it bug?

You're probably missing something, but I don't know what. Because I just tried that code, pasted it into the window of a write command, and it works.
Although it's easy to miss it I guess, but the menu does pop up at mouse cursor position.

When you say you press Enter, you mean Ctrl+Enter, or Enter ? If the later, make sure the Cancel button isn't focused at that time. If that's not it, I have no idea, sorry.

j_c_hallgren wrote:Does that explain why, when I tried to add a new script, it just keep changing back to "New" no matter what I typed in Script entry line?

Yes, you need to use the Edit button for now, anything typed in right on the UDC window gets canceled when pressing Apply for now...

jacky wrote:When you say you press Enter, you mean Ctrl+Enter, or Enter ?

Typed Enter, but meant OK...
Tried it again, and now it works properly...not sure what differs between attempts.

j_c_hallgren wrote: Also, when I first attempted to add 'write' as first/only Run Script, somehow I ended up with an empty box that showed instead of the script.

Ok...managed to get it to occur again...starting with no scripts and no UDC, I used 'Manage Cmds' and selected 'Run Script', typed in "write" as Script, and used Apply, then OK...it created a null command of some type that shows as blank box when you select Run Script on pull-down UDC...this may be related to the Edit button issue above.

j_c_hallgren wrote:

jacky wrote:When you say you press Enter, you mean Ctrl+Enter, or Enter ?

Typed Enter, but meant OK...
Tried it again, and now it works properly...not sure what differs between attempts.

j_c_hallgren wrote: Also, when I first attempted to add 'write' as first/only Run Script, somehow I ended up with an empty box that showed instead of the script.

Ok...managed to get it to occur again...starting with no scripts and no UDC, I used 'Manage Cmds' and selected 'Run Script', typed in "write" as Script, and used Apply, then OK...it created a null command of some type that shows as blank box when you select Run Script on pull-down UDC...this may be related to the Edit button issue above.

The little mess will probably be gone after the latest fixes.

Command sel using syntax "[filename.ext]" will not select the given item but "unselect" if it has focus.

I say "unselect" because it item was both focused&selected it'll get unselected, which isn't expected behavior anyway, but if it had focus but wasn't selected, nothing is done.

jacky wrote:Command sel using syntax "[filename.ext]" will not select the given item but "unselect" if it has focus.

I say "unselect" because it item was both focused&selected it'll get unselected, which isn't expected behavior anyway, but if it had focus but wasn't selected, nothing is done.

It's how the "sel" function is implemented: it searches/selects downwards to the end of the list and does not wrap around.

admin wrote:

jacky wrote:Command sel using syntax "[filename.ext]" will not select the given item but "unselect" if it has focus.

I say "unselect" because it item was both focused&selected it'll get unselected, which isn't expected behavior anyway, but if it had focus but wasn't selected, nothing is done.

It's how the "sel" function is implemented: it searches/selects downwards to the end of the list and does not wrap around.

Yeah, but shouldn't it start at the current focus position, and not +1 ? Cause now imagine a sel "[file.ext]" triggered in a list with only one item - named file.ext - then, it won't ever be selected.
Same is true if the item happens to be the first one list, even with a sel 1,0 right before.

Still sounds like a bug to me...

jacky wrote:

admin wrote:

jacky wrote:Command sel using syntax "[filename.ext]" will not select the given item but "unselect" if it has focus.

I say "unselect" because it item was both focused&selected it'll get unselected, which isn't expected behavior anyway, but if it had focus but wasn't selected, nothing is done.

It's how the "sel" function is implemented: it searches/selects downwards to the end of the list and does not wrap around.

Yeah, but shouldn't it start at the current focus position, and not +1 ? Cause now imagine a sel "[file.ext]" triggered in a list with only one item - named file.ext - then, it won't ever be selected.
Same is true if the item happens to be the first one list, even with a sel 1,0 right before.

Still sounds like a bug to me...

Okay, if the current focus is not selected then start here, else start at +1. Makes sense. However, if focus is at your item, it will unselect the item. Then select again. Then unselect again... toggle... is that good?

admin wrote:Okay, if the current focus is not selected then start here, else start at +1. Makes sense. However, if focus is at your item, it will unselect the item. Then select again. Then unselect again... toggle... is that good?

hmm... why not start here all the time, if there's no wildchars ? Then, there's no problem : with a full name given, and item is focused :
- selected : gets/stays selected
- not selected : gets selected

And when there's a wildcar, start here when not selected, +1 otherwise.

jacky wrote:

admin wrote:Okay, if the current focus is not selected then start here, else start at +1. Makes sense. However, if focus is at your item, it will unselect the item. Then select again. Then unselect again... toggle... is that good?

hmm... why not start here all the time, if there's no wildchars ? Then, there's no problem : with a full name given, and item is focused :
- selected : gets/stays selected
- not selected : gets selected

And when there's a wildcar, start here when not selected, +1 otherwise.

Yep, had the same thought.

BTW I forgot, another little bug:
sel 1,0;
sel 3;

will not work, because during the second call the value of the second parameter is still remembered (0) instead of being defaulted (1). Easy to find a way around it (sel 3,1) but should be fixed anyways.

Found a new one! Try this: ::goto "<xypath>\?*.ini"

It will not work unless you were already in <xypath>. If you were, it's all fine, otherwise, you get an error ("D:\Program Files\XYplorer\' could not be accessed. -- The script ends here anyway.") after the search has been done (successfully).
It seems to be linked to changing location and running a name search at the same time, cause this will work just fine: ::goto "<xypath>"; goto "?*.ini";
Although, of course, it doesn't really do the same...

admin wrote:

jacky wrote:

admin wrote:Okay, if the current focus is not selected then start here, else start at +1. Makes sense. However, if focus is at your item, it will unselect the item. Then select again. Then unselect again... toggle... is that good?

hmm... why not start here all the time, if there's no wildchars ? Then, there's no problem : with a full name given, and item is focused :
- selected : gets/stays selected
- not selected : gets selected

And when there's a wildcar, start here when not selected, +1 otherwise.

Yep, had the same thought.

Alas, there's one problem: in a search results list you can have more than one "file.ext". Then "- selected : gets/stays selected" will never select the next "file.ext".

jacky wrote:BTW I forgot, another little bug:
sel 1,0;
sel 3;

will not work, because during the second call the value of the second parameter is still remembered (0) instead of being defaulted (1). Easy to find a way around it (sel 3,1) but should be fixed anyways.

Yep, fixed. Thanks, man!

jacky wrote:Found a new one! Try this: ::goto "<xypath>\?*.ini"

It will not work unless you were already in <xypath>. If you were, it's all fine, otherwise, you get an error ("D:\Program Files\XYplorer\' could not be accessed. -- The script ends here anyway.") after the search has been done (successfully).
It seems to be linked to changing location and running a name search at the same time, cause this will work just fine: ::goto "<xypath>"; goto "?*.ini";
Although, of course, it doesn't really do the same...

Yep, fixed.

admin wrote:Alas, there's one problem: in a search results list you can have more than one "file.ext". Then "- selected : gets/stays selected" will never select the next "file.ext".

hmm.. yeah, but really, when will that be needed?!

Seriously though, I see you've done this along with the fixes mentioned above quietly, and it seems that the syntax sel "[text]" doesn't work in Finding Tabs, with or without wildchars.
Is that a recent change ? I honestly never used it on SR before...