Scripting Bugs

[zer0]

It might be unwanted by you, but IMO it is what one would expect (and, for hypothetic other users, also want) to happen.

Isn't that what "Keep progress dialog open" is for though? Mine is unchecked and, as per help file...

Keep progress dialog open: If checked the dialog stays open after the operation is completed. If unchecked the dialog is auto-closed. In the latter case, if Show summary report is checked the dialog is auto-closed only after 5 seconds, otherwise it is auto-closed immediately.

[admin]

backupto [location], [source], [on_collision], [preserve_dates], [create_log], [pop_stats], [skip_junctions], [verify], [show_progress]

[zer0]

backupto [location], [source], [on_collision], [preserve_dates], [create_log], [pop_stats], [skip_junctions], [verify], [show_progress]

Correct, to show [while a copy is taking place] not to keep [after the copy has finished].

[admin]

Code: Select all

v10.00.0008 - 2011-07-14 15:42
...
    * SC backupto: Any progress dialog will be kept open, so "Keep 
      progress dialog open" (a setting that's not available as argument) 
      is internally ON when the progress dialog is popped via SC 
      backupto.

[zer0]

Code: Select all

v10.00.0008 - 2011-07-14 15:42
...
    * SC backupto: Any progress dialog will be kept open, so "Keep 
      progress dialog open" (a setting that's not available as argument) 
      is internally ON when the progress dialog is popped via SC 
      backupto.

But that creates a "damned if you do and damned if you don't" situation. Changing the script to

Code: Select all

backupto "<location1>", "<location2>";

to have it use the global setting instead, having "Show progress dialog" checked and "Keep progress dialog unchecked still keeps the dialogue at the end even if it is not popped up via explicit SC declaration.

[admin]

I will add another argument in a later version.

[zer0]

Staying with backupto(), using v14.00.0100 and running this script:

Code: Select all

backupto "<source>", "<destination>";

moves the scrolling position to the top of the list when in <destination>. Outside of <destination>, scrolling position stays where it is.

[admin]

Cannot confirm.

[zer0]

Cannot confirm.

I was able to reproduce it in a fresh build once I locked the tree. If the tree is unlocked, it does not happen.

[admin]

Still: Cannot confirm.

[zer0]

Still: Cannot confirm.

Forget the locked tree. In fact, forget it moving the scrolling position to the top of <destination> list. The key is having an item selected in the list of <destination> before starting the script command, but having that item not in view of what is currently displayed in the list. Basically: click on an item at the top of the list, scroll all the way to the bottom, run the script. On completion of backupto(), the list jumps to that selected item. Curiously, the extent of the "scrolling jump" depends on whether the item is above the current list position or below. If it is above, it moves the list so that the items is the first seen at the top. If it is below, the list is shifted so that it is the first from bottom.

[bauxite69]

Hi,

If a folder name contains .(DOT) FORMATLIST with filter "!*.*" won't return filename without extension

Code: Select all

text formatlist("D:\test\data1\filename1|D:\test\data1\filename2.ext", "f", "|", "!*.*")

Return "D:\test\data1\filename1"

Code: Select all

text formatlist("D:\test\data.1\filename1|D:\test\data.1\filename2.ext", "f", "|", "!*.*")

Return ""

Thanks

[admin]

Hi and welcome!

Well, the filter is applied to the whole path/file, not just to the filename. Is this a bug? No! FORMATLIST is not even specialized to filenames. It does not know what a path is.

Don

[bauxite69]

Hi and welcome!

Well, the filter is applied to the whole path/file, not just to the filename. Is this a bug? No! FORMATLIST is not even specialized to filenames. It does not know what a path is.

Don

Thank you for your quick reply

That's clear, it's not a bug.

I'll post in "Tips & Tricks, Questions & Answers" for how to achieve that with another scripting command.

[bdeshi]

readfile() throws a sinister-looking error if asked to read from a file where "byte position to start reading from" is greater than filesize.
create a 4byte file and try reading from 6th byte:

Code: Select all

 writefile("c:\testfile", '0000', , b);
 readfile("c:\testfile", b, 1, , 6);

Can it be made to return empty string instead? Like the numbytes parameter does when numbytes<=0