Scripting Bugs

Things you'd like to miss in the future...

Re: Scripting Bugs

Postby TheQwerty » 06 May 2010 12:14

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.
TheQwerty
 
Posts: 3230
Joined: 03 Aug 2007 21:30

Re: Scripting Bugs

Postby TheQwerty » 06 May 2010 12:16

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?
TheQwerty
 
Posts: 3230
Joined: 03 Aug 2007 21:30

Re: Scripting Bugs

Postby admin » 06 May 2010 12:23

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.
admin
Site Admin
 
Posts: 33217
Joined: 22 May 2004 15:48
Location: Cologne

Re: Scripting Bugs

Postby jacky » 06 May 2010 13:22

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.
Proud XYplorer Fanatic
jacky
XYwiki Master
 
Posts: 3106
Joined: 23 Aug 2005 21:25
Location: France

Re: Scripting Bugs

Postby TheQwerty » 06 May 2010 14:07

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.
TheQwerty
 
Posts: 3230
Joined: 03 Aug 2007 21:30

Re: Scripting Bugs

Postby zer0 » 20 Jun 2010 14:07

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
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7 Professional/Enterprise 64-bit SP1
Always using the latest stable build
zer0
 
Posts: 2492
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Postby TheQwerty » 20 Jun 2010 17:23

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. ;)
TheQwerty
 
Posts: 3230
Joined: 03 Aug 2007 21:30

Re: Scripting Bugs

Postby zer0 » 20 Jun 2010 19:08

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
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7 Professional/Enterprise 64-bit SP1
Always using the latest stable build
zer0
 
Posts: 2492
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Postby TheQwerty » 20 Jun 2010 19:34

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
TheQwerty
 
Posts: 3230
Joined: 03 Aug 2007 21:30

Re: Scripting Bugs

Postby zer0 » 20 Jun 2010 20:41

Thanks for the tip, I've edited accordingly.

Still, the matter of Sticky Selection remains...
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7 Professional/Enterprise 64-bit SP1
Always using the latest stable build
zer0
 
Posts: 2492
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Postby admin » 21 Jun 2010 07:54

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.
admin
Site Admin
 
Posts: 33217
Joined: 22 May 2004 15:48
Location: Cologne

Re: Scripting Bugs

Postby zer0 » 21 Jun 2010 08:49

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.
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7 Professional/Enterprise 64-bit SP1
Always using the latest stable build
zer0
 
Posts: 2492
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Postby admin » 21 Jun 2010 09:39

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...
admin
Site Admin
 
Posts: 33217
Joined: 22 May 2004 15:48
Location: Cologne

Re: Scripting Bugs

Postby zer0 » 11 Aug 2010 19:43

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? :?
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7 Professional/Enterprise 64-bit SP1
Always using the latest stable build
zer0
 
Posts: 2492
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Postby admin » 11 Aug 2010 19:48

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', '|') . '|';
admin
Site Admin
 
Posts: 33217
Joined: 22 May 2004 15:48
Location: Cologne

PreviousNext

Return to Bug Reports



Who is online

Users browsing this forum: No registered users and 3 guests