Page 29 of 41
Re: Scripting Bugs
Posted: 04 Jan 2015 17:03
by bdeshi
In my view it's a bug.
If a separator is provided, it's inserted between items; one extra separator is not added at the end.
If a separator is not provided, "records are returned one per line"; one extra line added at the end => implies an empty item, or an extra separator: bug in either case.
Re: Scripting Bugs
Posted: 04 Jan 2015 17:43
by Filehero
Hi Peter,
seems we like discussing.
PeterH wrote:Maybe, if I didn't understand you wrong, you should just use separator <crlf>
That's exactly why I've chosen my example because it clearly show it's a bug. In this special case it's just by accident that the explicit separator happens to have the same semantic as the default one.
Of course, in simple scripts this all doesn't really matter, on those one/two pagers it's merely trial & error anyway. But with larger ones, perhaps including different script files, we all know things can quickly get nasty. Especially when after a long time a ticket enforces you return to the mess you one created.
FH
- dreaming of arrays, hashmaps & user-defined functions
Re: Scripting Bugs
Posted: 04 Jan 2015 17:45
by PeterH
I would be with you, if the sep operand would specify that the default is <crlf>
then empty sep and <crlf> would have to be identical.
But separator says: "If missing records are returned one per line."
This is not "identical <crlf>". And a line, even the last, can be ended by a line ending.
So no:
for me no
But at the end: Don must decide (or ignore)
Edit: @FH: from you last post our difference seems to be the interpretation of default?
Re: Scripting Bugs
Posted: 04 Jan 2015 17:58
by Filehero
PeterH wrote:Edit: @FH: from you last post our difference seems to be the interpretation of default?
Sort of yes. More correct, it is the fact, that a formatting detail is changing the semantic of the function by adding a ghost entry to a list.
Re: Scripting Bugs
Posted: 05 Jan 2015 00:06
by PeterH
OK: last try to explain my understanding:
Per default the list is a list of *lines* (each ended by crlf).
If you want a list of *tokens* ('records') you must use the separator operand, which is documented to *separate* the tokens. Here no separator follows the last token.
I think, for a list of lines, possibly used for output, the final crlf can be expected, while for a list of tokens, interpreted by script logic, it should not.
As long as this interpretation is possible, I would at least not call it a bug.
OK: if it *is* meant this way, documentation could be a bit more clear for that - to avoid problems with empty operand when looping.
To your last sentence: is it wrong that a formatting detail distinguishes between lines and tokens? A matter of formatting for output or for automated handling?
Re: Scripting Bugs
Posted: 09 Mar 2015 16:34
by TheQwerty
! SC Property: No longer opened the Shell Properties dialog.
Neither of these examples works in fresh v15.00:
Code: Select all
property(, "<xypath>\<xyexe>"); //show Properties for XYplorer
property(); //show Properties for current item
Re: Scripting Bugs
Posted: 10 Mar 2015 10:58
by admin
Confirmed and fixed, thanks.
Re: Scripting Bugs
Posted: 14 Mar 2015 17:33
by bdeshi
there something weird with angle brackets in comparison expressions:
Code: Select all
echo <get countselected> > 1; echo (<get countselected>) > 1;
echo 1 < <get countselected>; echo 1 < (<get countselected>);
echo <xyver> > "12.00.0000"; echo (<xyver>) > "12.00.0000";
echo "12.00.0000" < <xyver>; echo "12.00.0000" < (<xyver>);
when the part following a < start with <
ed. @Pete: happy now?
Re: Scripting Bugs
Posted: 14 Mar 2015 17:46
by PeterH
SammaySarkar wrote:there something weird with angle brackets in comparison expressions:
Code: Select all
echo <get countselected> > 1; echo (<get countselected>) > 1;
echo 1 < <get countselected>; echo 1 < (<get countselected>);
echo <xyver> > 12.00.0000; echo "<xyver>" > 12.00.0000;
echo 12.00.0000 < <xyver>; echo 12.00.0000 < "<xyver>";
when the part following a < start with <
Basically you seem right: the 2nd and 4th line show wrong results:
But for the last 2 lines: 12.00.0000 isn't a (valid) number, but a string. So I expect it should be quoted.
<xyver> is a variable - no reason to quote. (But not wrong.)
(Sorry
)
Re: Scripting Bugs
Posted: 14 Mar 2015 19:18
by admin
Comfirmed and fixed. Good find!
Re: Scripting Bugs
Posted: 16 Mar 2015 07:24
by bdeshi
tab('get', 'term') isn't returning VFs. QS is good.
Code: Select all
::goto "<xypath>?exe"; echo tab('get', 'term');goto "<xypath>|exe"; echo tab('get', 'term');
tab() reference wrote:"term": the path including any Visual Filter or Quick Search (same as menu View | Tab | Copy Location Term).
btw, that Copy Location Term also forgets about VFs.
Re: Scripting Bugs
Posted: 16 Mar 2015 11:04
by admin
Works fine here. Both.
Re: Scripting Bugs
Posted: 16 Mar 2015 13:02
by bdeshi
I only get the <curpath> , even in ::fresh!
Re: Scripting Bugs
Posted: 16 Mar 2015 15:04
by admin
OK, it depended on Configuration | Find Files & Branch View | Visual Filters | Show filter information in tab headers.
Next version will always work.
Re: Scripting Bugs
Posted: 16 Mar 2015 21:29
by TheQwerty
This old bug seems to still exist...
TheQwerty wrote:Self and Caller enter a fugue state when Load displays a menu for multiple labels...
Code: Select all
"A" Text "Myself:<crlf>" . Self('script') . "<crlf 2>Caller:<crlf>" . Caller('script');
"B" Text "Myself:<crlf>" . Self('caption') . "<crlf 2>Caller:<crlf>" . Caller('caption');
-
"Sub - Correct" Sub 'A'; Sub 'B';
"Load A - Correct" Load '*', 'A';
"Load B - Correct" Load '*', 'B';
-
"Load A;B - Confused" Load '*', 'A;B';
The results I expect are these:
TheQwerty wrote:That they would more closely resemble the results shown for the scripts marked "Correct".
[i]Load A;B - Confused > A[/i] wrote:Myself:
Text "Myself:<crlf>" . Self('script') . "<crlf 2>Caller:<crlf>" . Caller('script');
Caller:
Load '*', 'A;B';
[i]Load A;B - Confused > B[/i] wrote:Myself:
B
Caller:
Load A;B - Confused