Scripting Bugs
Re: Scripting Bugs
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.
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.
-
- Site Admin
- Posts: 60541
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Scripting Bugs
Yep, fixed. This has to be done case by case. I hope I got them all.TheQwerty wrote:Calling an XY menu via command ID may not reflect the current state of binary options. ...
FAQ | XY News RSS | XY Twitter
Re: Scripting Bugs
Fix confirmed! Not sure if I managed to check them all or not, but looks like you may have missed a couple..admin wrote:Yep, fixed. This has to be done case by case. I hope I got them all.TheQwerty wrote:Calling an XY menu via command ID may not reflect the current state of binary options. ...
#301; View->Views
#420; Tools->Customize List->Size Column Format
Re: Scripting Bugs
I have a script (see below) that is giving me problems.
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
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, ;
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
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build
Windows 7/10
Always using the latest stable two-decimal build
Re: Scripting Bugs
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.
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
Both background processing and queuing are enabled.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.
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build
Windows 7/10
Always using the latest stable two-decimal build
Re: Scripting Bugs
It's possible to control background processing from a script:zer0 wrote:Both background processing and queuing are enabled.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.
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
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 intendednas8e9 wrote:It's possible to control background processing from a script:
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build
Windows 7/10
Always using the latest stable two-decimal build
Re: Scripting Bugs
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.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
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
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.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 intendednas8e9 wrote:It's possible to control background processing from a script:
Re: Scripting Bugs
@zero: Completely OT, but...
...are you aware that WinRAR has a 64-bit version that installs both a 32-bit as well as a 64-bit shell extension?
Code: Select all
...
OpenWith("""C:\Program Files (x86)\WinRAR\WinRAR.exe"" e -- *.rar * $nn-temp", "s");
...
Re: Scripting Bugs
Yep, I will test when I get back home.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?
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.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.
That's affirm. However, I seldom use WinRAR outside of XYplorer, so its 32-bit flavour is fine for menas8e9 wrote:@zero: Completely OT, but......are you aware that WinRAR has a 64-bit version that installs both a 32-bit as well as a 64-bit shell extension?Code: Select all
... OpenWith("""C:\Program Files (x86)\WinRAR\WinRAR.exe"" e -- *.rar * $nn-temp", "s"); ...
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build
Windows 7/10
Always using the latest stable two-decimal build
Re: Scripting Bugs
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.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.
Re: Scripting Bugs
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" ).TheQwerty wrote: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.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.
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...
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build
Windows 7/10
Always using the latest stable two-decimal build
-
- Site Admin
- Posts: 60541
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Scripting Bugs
Quoting the change log (watch the last line!):zer0 wrote: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" ).TheQwerty wrote: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.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.
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...
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.
FAQ | XY News RSS | XY Twitter