Page 14 of 41

Re: Scripting Bugs

Posted: 06 May 2010 13:14
by TheQwerty
zer0 wrote:A better solution would be to establish a type of a delayed-response mechanism between scripting and XYcopy as follows:

a) The scripting engine tells XYcopy to move a file. In the meantime, the script does not continue to execute.
b) Presumably, XYcopy knows once a job is finished. It sends an "all clear" signal to the scripting engine.
c) Scripting engine receives this signal and resumes parsing the remainder of a script.

Such close integration would be really useful. Otherwise, why be able to use XYcopy for intra-volume moves using scripting at all as opposed to how things were in the past?
I'm not convinced this would actually be better. It doesn't give the script writer the ability to do the move in the background without blocking, which I believe could be useful.

I'm not sure why this would be preferable to using Setting('BackgroundFileOps', 0); before the file op that needs to block?


Remember the actual issue isn't the type of file op or even that there is a second file op, it's just whether or not the rest of the script depends on this operation happening first.

Re: Scripting Bugs

Posted: 06 May 2010 13:16
by TheQwerty
admin wrote:Ah yes, confirmed. But I don't see how this could be a very recent error. From the source code it looks like it was born 20090801.
I don't know when it first started happening, but it's been in the last month or so. I only noticed it because of jacky's updater script (which makes me surprised no one else reported it).

EDIT: Presumably, there's some circumstances where those command IDs work without error?

Re: Scripting Bugs

Posted: 06 May 2010 13:23
by admin
TheQwerty wrote:
admin wrote:Ah yes, confirmed. But I don't see how this could be a very recent error. From the source code it looks like it was born 20090801.
I don't know when it first started happening, but it's been in the last month or so. I only noticed it because of jacky's updater script (which makes me surprised no one else reported it).

EDIT: Presumably, there's some circumstances where those command IDs work without error?
I could only reproduce (and fix) the when running it directly through the address bar.

Re: Scripting Bugs

Posted: 06 May 2010 14:22
by jacky
TheQwerty wrote:Don, I know you told me you couldn't add a tweak which made all scripted file ops occur in the foreground and be blocking, as they were before XYcopy. But couldn't you add a tweak that forces a "Setting('BackgroundFileOps', 0);" before every script? That seems like it would be incredibly easy to do; like most things when you cannot see the source. ;)
About this issue, somewhat. I understand TheQwerty's request, because to be honest I only use background processing on copy operations because I don't want to have to go through all my scripts (many of which do do move operations, and require for their execution to only continue upon completion of said file (move) operation) right now to add such a thing. I'm lazy, I know.

But there is something I wish for, because right now the "odd" thing with BackgroundFileOps (as param for setting) is that it's an "incomplete" option, since unlike all the other ones, it relies itself or other options (Apply to).

What I mean is, if today I write a script and I need to make sure there won't be no background processing, cause I need the script to continue its execution only after it's done, I can do that (setting 'BackgroundFileOps', 0;) just fine. (Side note: Ideally, when we have CEA if we could add a script to be executed upon completion of a background job, that would be awesome. As in, a script to be executed when a specific bg job is completed, or where we have the job #ID and can use that...)

Back on topic, now let's imagine I have a script and I need to have a file operation in the background. Well, I can't. Oh sure, I can do a setting 'BackgroundFileOps', 1; but that doesn't mean anything at all, really. It means "process in the back, IF the user said so in his "Apply to" settings). I wish the script could force the operation to be processed in the background. The whole point of setting, to me, is to be able to know/set what's gonna happen, regardless of the current user-settings. We can if we want to disable bg processing, but not the other way around.

For example, I have have bg processing enabled for Copy only, for reasons stated previously, but I'd love a script that would force a move operation to be processed in the background (meaning the script should be able to "by-pass" the Apply to settings). Maybe a new setting should be added, alongside BackgroundFileOps, such as BackgroundedFileOps. (Although that's probably somewhat asking for confusion... I blame Don, though, who decided to call FopInBackground BackgroundFileOps.)
Either that or we should have the current BackgroundFileOps work as its brother in the INI does, thus allowing the script to really know what will happen, and maybe a new value (for use with setting only) would need to be added, meaning "use user setting".

TheQwerty wrote:
admin wrote:Ah yes, confirmed. But I don't see how this could be a very recent error. From the source code it looks like it was born 20090801.
I don't know when it first started happening, but it's been in the last month or so. I only noticed it because of jacky's updater script (which makes me surprised no one else reported it).
Well, for the record I use that script too, and never had any crash... so there must be another factor somewhere or something.

Re: Scripting Bugs

Posted: 06 May 2010 15:07
by TheQwerty
jacky wrote:Maybe a new setting should be added, alongside BackgroundFileOps, such as BackgroundedFileOps. (Although that's probably somewhat asking for confusion... I blame Don, though, who decided to call FopInBackground BackgroundFileOps.)
Either that or we should have the current BackgroundFileOps work as its brother in the INI does, thus allowing the script to really know what will happen, and maybe a new value (for use with setting only) would need to be added, meaning "use user setting".
Indeed, I agree with you. It hadn't dawned on me that this setting (or a new one) should be able to define the Apply To options.

I've really felt that what was needed was yet another parameter for the file op commands, but I also didn't want to see these continue to grow with more and more arguments. What you suggest is, per usual, a great compromise.
jacky wrote:
TheQwerty wrote:I don't know when it first started happening, but it's been in the last month or so. I only noticed it because of jacky's updater script (which makes me surprised no one else reported it).
Well, for the record I use that script too, and never had any crash... so there must be another factor somewhere or something.
It could be the fact that I call your script from another script, which would explain why no one else has mentioned it. I hadn't tried reproducing it outside of directly calling the CIDs through the AB; maybe if the next beta doesn't fix it for me.

Re: Scripting Bugs

Posted: 20 Jun 2010 15:07
by zer0
Scripting selecting files by extension using a script below does not fare well with Sticky Selection enabled as the selection is lost for each new criteria applied -- defeating the concept of Sticky Selection.

Code: Select all

$a = input("Enter File Extention");
    Selfilter *.$a, f;
    focus l;
P.S. Could be a bug in SS rather than Scripting, but it only applies while calling a script, so...:P

Re: Scripting Bugs

Posted: 20 Jun 2010 18:23
by TheQwerty
No comment on the actual behavior but FYI:
zer0 wrote:

Code: Select all

Selfilter *.$a, f;
If the value of "$a" is "exe", the above will give you "*exe" instead of "*.exe" because without the quotes it's viewing the "." as meaning concatenate "*" and the value of "$a".

EDIT: And I'm assuming that's not what you actually want. ;)

Re: Scripting Bugs

Posted: 20 Jun 2010 20:08
by zer0
TheQwerty wrote:If the value of "$a" is "exe", the above will give you "*exe" instead of "*.exe" because without the quotes it's viewing the "." as meaning concatenate "*" and the value of "$a".

EDIT: And I'm assuming that's not what you actually want. ;)
Hmm. I went to a folder with a few EXEs and other file formats. Run my script and typed exe -- voila! All EXE files were selected.

Are you saying that that should not have happened? If that's the case, there are a couple of bugs that have been uncovered :P

Re: Scripting Bugs

Posted: 20 Jun 2010 20:34
by TheQwerty
zer0 wrote:Are you saying that that should not have happened?
No, the difference I'm pointing out is that it will select all files that end in "exe" but not necessarily only those that have an extension of "exe".

It will select "a.exe", "b.notexe" and "cexe" because it uses that period for concatenation instead of as part of the actual pattern.

These will all act the same (as you can see in the step dialog):

Code: Select all

SelFilter *.$a, f;
SelFilter *$a, f;
SelFilter "*$a", f;
Given that you're prompting for a file extension I'd imagine you want to restrict the filter to only match against the extension so the more correct syntax would be to include the period as part of the pattern as in:

Code: Select all

SelFilter "*.$a", f;
zer0 wrote:If that's the case, there are a couple of bugs that have been uncovered :P
Well yes, but one is in the script and not XY. :P

Re: Scripting Bugs

Posted: 20 Jun 2010 21:41
by zer0
Thanks for the tip, I've edited accordingly.

Still, the matter of Sticky Selection remains...

Re: Scripting Bugs

Posted: 21 Jun 2010 08:54
by admin
zer0 wrote:Scripting selecting files by extension using a script below does not fare well with Sticky Selection enabled as the selection is lost for each new criteria applied -- defeating the concept of Sticky Selection.

Code: Select all

$a = input("Enter File Extention");
    Selfilter *.$a, f;
    focus l;
P.S. Could be a bug in SS rather than Scripting, but it only applies while calling a script, so...:P
I think it is good that SC Selfilter does not honor SS, otherwise scripting would depend on this setting. The command Selection Filter in menu Edit behaves the same.

Re: Scripting Bugs

Posted: 21 Jun 2010 09:49
by zer0
admin wrote:I think it is good that SC Selfilter does not honor SS, otherwise scripting would depend on this setting. The command Selection Filter in menu Edit behaves the same.
I see, so how would one script selection of user-defined -- but not pre-specified -- multiple file formats? I suppose I saw selfilter SC as an equivalent to batch point-and-click selection -- for which SS is honoured -- thus did not think of a reason to be discrepant in behaviour.

Re: Scripting Bugs

Posted: 21 Jun 2010 10:39
by admin
zer0 wrote:
admin wrote:I think it is good that SC Selfilter does not honor SS, otherwise scripting would depend on this setting. The command Selection Filter in menu Edit behaves the same.
I see, so how would one script selection of user-defined -- but not pre-specified -- multiple file formats? I suppose I saw selfilter SC as an equivalent to batch point-and-click selection -- for which SS is honoured -- thus did not think of a reason to be discrepant in behaviour.
I just enhanced the selfilter command to do this...

Re: Scripting Bugs

Posted: 11 Aug 2010 20:43
by zer0
I am of a strong suspicion that this change

Code: Select all

v9.40.0007 - 2010-08-10 20:37
    ! SC getinfo("SelectedItemsPathNames") and
      getinfo("SelectedItemsNames") returned a trailing delimiter after
      the last returned item. Fixed. Now delimiters are found only
      between the items.
has broken my script that features this code

Code: Select all

$filelist = getinfo('SelectedItemsPathNames', '|');
   $p = strpos($filelist, '|');
   while ($p >= 0)
   {
      $file = substr($filelist, 0, $p);
      $name = regexreplace($file, "^.+\\(.+)$", "$1");
      $filelist = substr($filelist, $p + 1);
      $p = strpos($filelist, '|');
      ......
Is this correct? And, if yes, how can I rework my script to remedy? :?

Re: Scripting Bugs

Posted: 11 Aug 2010 20:48
by admin
Without any testing I would say simply append the delimiter manually if you really need it at the end:

Code: Select all

$filelist = getinfo('SelectedItemsPathNames', '|') . '|';