Page 12 of 41
Re: Scripting Bugs
Posted: 02 Mar 2010 21:46
by TheQwerty
Calling an XY menu via command ID may not reflect the current state of binary options.
For instance call the Show Items Menu via #490;.
Toggle a setting.
Call #490; again.
The Show Items Menu will continue to display the wrong state(s) until you open it via View->Show Items.
This is also an issue if you toggle one of those options directly via command ID.
For instance calling #496;#490; should toggle show folders and display the show items menu, but the menu is inaccurate until doing View->Show Items.
Re: Scripting Bugs
Posted: 03 Mar 2010 10:24
by admin
TheQwerty wrote:Calling an XY menu via command ID may not reflect the current state of binary options. ...
Yep, fixed. This has to be done case by case. I hope I got them all.
Re: Scripting Bugs
Posted: 08 Mar 2010 14:53
by TheQwerty
admin wrote:TheQwerty wrote:Calling an XY menu via command ID may not reflect the current state of binary options. ...
Yep, fixed. This has to be done case by case. I hope I got them all.
Fix confirmed! Not sure if I managed to check them all or not, but looks like you may have missed a couple..
#301; View->Views
#420; Tools->Customize List->Size Column Format
Re: Scripting Bugs
Posted: 28 Apr 2010 00:07
by zer0
I have a script (see below) that is giving me problems.
Code: Select all
Set($cf,<curfolder>);
Set($cp,<curpath>);
Set($nn,<date yyyymmddhhnnss>);
new "$nn-temp", dir;
OpenWith("""C:\Program Files (x86)\WinRAR\WinRAR.exe"" e -- *.rar * $nn-temp", "s");
Msg("Press OK when WinRAR is finished.",1);
GoTo("<curpath_s>\$nn-temp");
Sel(a);
Rename(b,$cf);
Focus(L);
MoveTo("..\..");
#523;
#523;
Rename(b,$nn,"$cp");
SelFilter($nn, d, Name);
Focus(L);
delete 1, 0, ;
There appears to be some timing issue once I click "OK", because instead of moving file(s) 2 levels up the file structure the whole shebang is shifted to RB. And if RB's allowed size is less that contents that have been deleted by this move then RB is bypassed and files are deleted without a confirmation dialogue
I've lost about 8GB like that earlier today, so understandably I am not best pleased. From looking in RB, I know that
Rename(b,$cf); happens correctly, but this script seems to ignore the rest until it comes to deletion. What could be going wrong here?
P.S. In step mode, the script works fine, which is why I believe that it is a matter of timing rather than anything else
Re: Scripting Bugs
Posted: 28 Apr 2010 02:50
by TheQwerty
Well the OpenWith probably should have quotes around the "$nn-temp".
You don't mention how you have background processing/queuing setup so it's possible the script is proceeding without waiting for the move to finish.
The second Rename is using "$cp" as the preview argument, when I believe you meant it to be the item list.
Re: Scripting Bugs
Posted: 28 Apr 2010 11:39
by zer0
TheQwerty wrote:You don't mention how you have background processing/queuing setup so it's possible the script is proceeding without waiting for the move to finish.
Both background processing and queuing are enabled.
Re: Scripting Bugs
Posted: 28 Apr 2010 12:04
by nas8e9
zer0 wrote:TheQwerty wrote:You don't mention how you have background processing/queuing setup so it's possible the script is proceeding without waiting for the move to finish.
Both background processing and queuing are enabled.
It's possible to control background processing from a script:
Code: Select all
v9.00.0021 - 2010-04-20 13:37
...
+ Scripting commands enhanced:
- setting, settingp
New named argument "backgroundfileops"
0 = Disable background processing of file operations
1 = Enable background processing of file operations
Example:
::setting "backgroundfileops", 1;
...
Re: Scripting Bugs
Posted: 28 Apr 2010 12:41
by zer0
nas8e9 wrote:It's possible to control background processing from a script:
Indeed, however those are intra-partition moves, so I don't need to get background processing involved as only changes to MFT are required. And regardless of background processing, in step mode the script works as intended
Re: Scripting Bugs
Posted: 28 Apr 2010 12:48
by nas8e9
zer0 wrote:Indeed, however those are intra-partition moves, so I don't need to get background processing involved as only changes to MFT are required. And regardless of background processing, in step mode the script works as intended
I may not have read too carefully. I did see the delete command in scripting causing problems, which reminded me of
this thread in which TheQwerty had a major problem with deletes being handled in the background.
In general it might be an idea to retest with background operations turned off in the script (saving on hunt the setting
). I don't know if this is a new script; did this use to work?
Re: Scripting Bugs
Posted: 28 Apr 2010 12:54
by TheQwerty
zer0 wrote:nas8e9 wrote:It's possible to control background processing from a script:
Indeed, however those are intra-partition moves, so I don't need to get background processing involved as only changes to MFT are required. And regardless of background processing, in step mode the script works as intended
Presumably in step mode you actually wait for it to finish the move before proceeding. Part of my question about background processing was the values in the File Ops->Apply To dialog, because for all we know you do have it set to do background processing of intra-volume moves as well.
Re: Scripting Bugs
Posted: 28 Apr 2010 13:18
by nas8e9
@zero: Completely OT, but...
Code: Select all
...
OpenWith("""C:\Program Files (x86)\WinRAR\WinRAR.exe"" e -- *.rar * $nn-temp", "s");
...
...are you aware that WinRAR has a 64-bit version that installs both a 32-bit as well as a 64-bit shell extension?
Re: Scripting Bugs
Posted: 28 Apr 2010 13:50
by zer0
nas8e9 wrote:In general it might be an idea to retest with background operations turned off in the script (saving on hunt the setting
). I don't know if this is a new script; did this use to work?
Yep, I will test when I get back home.
TheQwerty wrote:Presumably in step mode you actually wait for it to finish the move before proceeding. Part of my question about background processing was the values in the File Ops->Apply To dialog, because for all we know you do have it set to do background processing of intra-volume moves as well.
Hmm, interesting. A tweak that defaults intra-volume moves to use XYcopy was introduced about a week ago, which is around when I started having issues. Just checked the INI and a change from 14 to 7 for
BackgroundedFileOps hasn't taken place -- presumably, it should have done as that's the new default. I will test with it set at "7", but that's a bug either way.
nas8e9 wrote:@zero: Completely OT, but...
Code: Select all
...
OpenWith("""C:\Program Files (x86)\WinRAR\WinRAR.exe"" e -- *.rar * $nn-temp", "s");
...
...are you aware that WinRAR has a 64-bit version that installs both a 32-bit as well as a 64-bit shell extension?
That's affirm. However, I seldom use WinRAR outside of XYplorer, so its 32-bit flavour is fine for me
Re: Scripting Bugs
Posted: 28 Apr 2010 13:57
by TheQwerty
zer0 wrote:Just checked the INI and a change from 14 to 7 for BackgroundedFileOps hasn't taken place -- presumably, it should have done as that's the new default.
It should reflect that change on a fresh install. Upgrading should never change a user's settings to the defaults, so I don't think this is a bug.
Re: Scripting Bugs
Posted: 28 Apr 2010 15:20
by zer0
TheQwerty wrote:zer0 wrote:Just checked the INI and a change from 14 to 7 for BackgroundedFileOps hasn't taken place -- presumably, it should have done as that's the new default.
It should reflect that change on a fresh install. Upgrading should never change a user's settings to the defaults, so I don't think this is a bug.
While there's a debate to be had that whether an earlier, unchanged-by-user default should be overridden by a newer default, the fact that it does not do so isn't a bug in its "face value" sense, but may be an inconvenience (or more as I lost 10GB of data through this "inconvenience"
).
However, I will test using a modified tweak in a few hours and see how it works. There is a bug in there somewhere, it's just a matter of narrowing down where the cause lies. Will report what the tests show...
Re: Scripting Bugs
Posted: 28 Apr 2010 15:36
by admin
zer0 wrote:TheQwerty wrote:zer0 wrote:Just checked the INI and a change from 14 to 7 for BackgroundedFileOps hasn't taken place -- presumably, it should have done as that's the new default.
It should reflect that change on a fresh install. Upgrading should never change a user's settings to the defaults, so I don't think this is a bug.
While there's a debate to be had that whether an earlier, unchanged-by-user default should be overridden by a newer default, the fact that it does not do so isn't a bug in its "face value" sense, but may be an inconvenience (or more as I lost 10GB of data through this "inconvenience"
).
However, I will test using a modified tweak in a few hours and see how it works. There is a bug in there somewhere, it's just a matter of narrowing down where the cause lies. Will report what the tests show...
Quoting the change log (watch the last line!):
Code: Select all
* Background Processing: I now think that the factory default for
backgrounded file operations should NOT include intra-volume
moves. Backup will soon be added so this should already be
included. So the new default is:
1 [x] Backup (currently unused; has yet to be coded)
2 [x] Copy
4 [x] Cross-volume move
8 [ ] Intra-volume move (always parallel = not queued!)
16 [ ] Delete (always parallel = not queued!)
The default value is 7 (1+2+4):
BackgroundedFileOps=7
This will not affect your configuration when you upgrade.