Page 1 of 1
Scripting - "Focus" / "Sel" commands not as expected
Posted: 14 Jun 2015 01:40
by Papoulka
I thought this would be simple (!) but after a couple of hours I have to ask...
I have a folder named "test". Within that folder is a subfolder named "vvvv" and a file named "zzz.dat". I want XY to select the file zzz.dat so I can work with it.
I have one List pane open. The folder "test" is selected in the Tree. As expected the pane shows:
vvvv
(folder)
zzz.dat
(file)
My script is:
Code: Select all
//title
focus "L";
sel f;
echo getpathcomponent(, "base");
end;
I expect the script to return "zzz",
but it always returns "test" (the parent folder)
unless I manually select the file zzz.dat first - then it returns "zzz". Of course I expect XY to select the file, that being the point of the "sel f" command.
I don't know if the problem is with the Focus command or the Sel command. Or if I am somehow misusing them. This is with Win 7 32-bit, XY ver 15.20.0300.
Any help will be appreciated
Re: Scripting - "Focus" / "Sel" commands not as expected
Posted: 14 Jun 2015 06:04
by bdeshi
sel/focus works fine, it's a problem with getpathcomponent().
When the focused item is not in selection, and getpathcomponent() path AKA item/first parameter is empty, the function fails to detect current item, and operates on current path.
select any one or more items
(file or folders don't matter), and echo a getpathcomponent() call. Now hold CTRL and press UP/DOWN to focus
(and focus only) an out-of-selection item, and echo the same function call again. In this case, gpc() works in the context of current path, rather than selected item.
Autotest:
Code: Select all
"gpc() test"
focus 'L';
if (listfolder(,,32) < 2){$tmp1 = new();$tmp2 = new();} //create test items if needed
wait 100;
sendkeys '{END}'; //select last item
wait 100;
echo "selected and focused<crlf><selitem>";
echo 'path: '.getpathcomponent(,'path').<crlf 2>.'processed <curitem>';
wait 100;
sendkeys '^{UP}'; //focus another item.
wait 100;
echo "focused NOT selected<crlf><focitem>";
echo 'path: '.getpathcomponent(,'path').<crlf 2>.'processed <curpath>';
if isset($tmp1){delete 1,0, "$tmp1|$tmp2";} //remove test items if created
[/size]
Re: Scripting - "Focus" / "Sel" commands not as expected
Posted: 14 Jun 2015 20:14
by Papoulka
Thank you for looking into this, Sammay.
I didn't suspect the getpathcomponent command. I'm still often confused between what is "focused" and what is "selected" so I thought the problem would be there.
I think you are saying that the getpathcomponent command has a bug. If so, I leave it up to you as a mod to move this to bug reports.
It looks like a bug to me since the most relevant Help example is
Code: Select all
echo getpathcomponent(, "file"); // current item without path
For now I got it working using:
Code: Select all
getpathcomponent(<selitem>, "ext");
Thanks for pointing me in the right direction...
Re: Scripting - "Focus" / "Sel" commands not as expected
Posted: 14 Jun 2015 20:39
by highend
I think you are saying that the getpathcomponent command has a bug
From the help file:
path: The path to parse; can be a folder or a file. Defaults to the current folder or file.
If the file is invalid (not selected AND focused) it uses the current folder. Perfectly valid...
Re: Scripting - "Focus" / "Sel" commands not as expected
Posted: 14 Jun 2015 21:38
by Papoulka
But, I had done all the obvious things to get that file to be selected:
Code: Select all
//title
focus "L";
sel f;
echo getpathcomponent(, "base");
end;
If that's not right, what would get that file selected?
Re: Scripting - "Focus" / "Sel" commands not as expected
Posted: 14 Jun 2015 23:07
by highend
I think this is a problem of the sel command, not of getpathcomponent.
Use a folder with only one file in it. Click anywhere in the list pane to deselect it.
use sel f; text getpathcomponent(, "ext");
The result is empty. At least here.
Again, click anywhere to deselect it.
Use sel 1; text getpathcomponent(, "ext");
It should contain the extension.
Somehow sel f; works differently as sel 1; if there is only one file in a folder. I'd call that a bug (or at least a behavior I wouldn't expect).