Scripting Bugs

[Papoulka]

With all the activity on SC property() in the recent betas, I'm sorry I didn't mention this a few days ago when I ran across it. But the topic had been discussed before in this thread so I let it go.

SC folderreport() by default returns strings with a CR at the end. This leads to a bogus date if used with SC property() in a foreach loop. Try the following in a list pane with one folder (as in attached jpg):

Code: Select all

focus 'L';

// $list=folderreport('dirs', 'r', <curpath>, , , '|');    //WORKS
   $list=folderreport('dirs', 'r', <curpath>);             //FAILS

 foreach ($tgt,$list,'|') {                                //REGARDLESS OF SEPARATOR HERE
   $idat = property("#date.modified", $tgt);
   echo $idat;
 }

So, it can be made to work but that does take some time to figure out.

[edit: I had a message here with different evidence, which on review didn't reliably show the problem. This message replaces that.]

[PeterH]

Code: Select all

 foreach ($tgt,$list,<crlf>) {                                //REGARDLESS OF SEPARATOR HERE

NOT regardless

[admin]

Next version you do like this:

Code: Select all

focus 'L';

  $list=folderreport('dirs', 'r', <curpath>);

  foreach ($tgt, $list, <crlf>, "e") { //e = skip empty
    $idat = property("#date.modified", $tgt);
    echo $idat;
  }

[Papoulka]

PeterH - you're right; I didn't have the right syntax when I tried <crlf>. That would also work.

Getting to the point of considering the separator took a while, because the folderreport / property combination worked OK outside of the foreach loop. Even after I realized that the loop (not these two commands themselves) was somehow the problem, I couldn't figure out why since the string texts looked fine in the variables view. After trying everything else I eventually changed the separator in folderreport, and that worked. And then... I understood what had been happening .

So, the fix feature will save others, someday, from the same kind of confusion.

[admin]

Well, it's not a fix, it's a feature.

[LittleBiG]

Code: Select all

msg gettokenindex("Item#","Name,Ext,Item#,Size",",") //0 

Code: Select all

msg gettokenindex("Item#","Name,Ext,Item#,Size",",","") //3 

I don't understand why the difference, I think the first is a bug.

[admin]

If you leave the default flags ("iw") then "#" is seen as a wildcard.

[LittleBiG]

If you leave the default flags ("iw") then "#" is seen as a wildcard.

Ok, thanks. It took me 15 minutes of trying but now I understand the logic.

[admin]

It might be a fair question to ask if # should be treated as a wildcard here, or if the wildcard flag should really be the default flag. But it's probably too late to ask, since changes would break old code.

[LittleBiG]

... if #if the wildcard flag should really be the default flag...

That was my immediate question after understanding the way of working. I did think that if I wanted to use wildcards, I would have to set the "w" flag. If the flag was empty string or didn't exist, it meant: no wildcard in the token/don't treat anything like wildcard. It was clearly wrong thinking , now I know. In real I can switch off the default "w" with the "". Weird.

[admin]

... if #if the wildcard flag should really be the default flag...

That was my immediate question after understanding the way of working. I did think that if I wanted to use wildcards, I would have to set the "w" flag. If the flag was empty string or didn't exist, it meant: no wildcard in the token/don't treat anything like wildcard. It was clearly wrong thinking , now I know. In real I can switch off the default "w" with the "". Weird.

Yes, it was decided like that because I think when users pass patterns like "blah*" they probably expect * to be seen as a wildcard. It's another story with "#". Anyway, bad decision as I see it now, but too late.

[Papoulka]

Just ran across this in SC 'selfilter'. I'm posting as a bug since it may be one. Or it may be simply unintended, or even intended. I'm still sometimes confused between selected and focused etc.

• Navigate to a folder using the Tree
  Run a toolbar button script "selfilter "*.jpg", f;
  Find that this selects JPGs as desired BUT also keeps the folder selected in the Tree

So if I then press Delete, the whole folder will go. Not as I intended.

The folder in the Tree does not appear to be selected (bright blue), but it is shaded as if focused.

Of course I can and will (and usually do) precede this command with Focus "L". Note that result of this is not visibly different from the above - the Tree folder still appears shaded. However, it won't be deleted.

On the face of it, it seems that "selfilter" with the "files only" flag should not leave anything in the Tree selected. That's my point.

[admin]

SC selfilter does not change the input focus. Delete affects the focused control. All works as expected.

The folder in the Tree does not appear to be selected (bright blue), but it is shaded as if focused.

That I cannot confirm. The folder is clearly selected, and when you press Delete it's deleted (after confirmation prompt, I hope).

[autocart]

attrstamp()

Sets the attributes for files or folders.

Syntax
attrstamp([attr], [mode=1], [itemlist])

attr: a = FILE_ATTRIBUTE_ARCHIVE (32)
h = FILE_ATTRIBUTE_HIDDEN (2)
r = FILE_ATTRIBUTE_READONLY (1)
s = FILE_ATTRIBUTE_SYSTEM (4)
They can be combined in any order and any case, e.g. "raH".

mode: 0=get, 1=set [Default], 2=replace, 3=toggle, 4=remove.

itemlist: |-separated list of items (full path) to attrstamp;
if empty then the currently selected list items are attrstamped.

return: Old attributes of the last processed item. The return value is made from summing up the attributes bit values, e.g. RAH = 1 + 32 + 2 = 35.

Examples
attrstamp("r"); //set readonly to selected items
attrstamp("rh"); //set readonly and hidden to selected items
attrstamp("r", 2); //set readonly to selected items (any other existing attributes are removed)
attrstamp("r", 3); //toggle readonly in selected items
attrstamp("R", 3); //toggle readonly in selected items (same as above)
attrstamp("r", 4); //remove readonly from selected items
attrstamp("r", , "E:\Test\x"); //set readonly to "E:\Test\x"
If no attributes are passed it just returns the old attributes of the last processed item:
text attrstamp(); //e.g. 5 = 1+4 (readonly and system)

attrstamp("r", 0, <curitem>) returns the same as attrstamp("h", 0, <curitem>) as attrstamp("s", 0, <curitem>) as attrstamp("a", 0, <curitem>)
This is not logical and therefore must be a bug.
"r" should only return the value for "r", "h" for "h", "s" for "s" and "a" for "a". If I want the whole sum of the values then it should be attrstamp(, 0, <curitem>).

Besides what about the attributes N = NORMAL, D = DIRECTORY, O = OFFLINE, C = COMPRESSED and T = TEMPORARY?

[nerdweed]

Innermost for loops breaks out of all for loops if the list for the innermost loop is empty and flag is set to "e" (do not process empty lines).

I am having nested foreach loops. The second loop can have empty list and it executes once which is ok. The inner most loop should not execute when it doesn't have any loops - but it breaks out of all the loops

Code: Select all

foreach ($item, $cat, "<crlf>")
{
	; $index is set here
	foreach ($ind, $index, "|") //This loop can be empty and should run
	{
		goto "$cat_name$ind";
		sel f; sel i;
		$selections = get("SelectedItemsPathNames", "|");  //store
		//if ($selections)
		//{
			foreach($sel, $selections, "|", "e") //Do not execute if empty
			{
				goto "$sel";
			}
		//}
	}
}