Page 22 of 41
Re: Scripting Bugs
Posted: 26 Apr 2014 13:28
by zer0
admin wrote: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.
Re: Scripting Bugs
Posted: 26 Apr 2014 13:34
by admin
backupto [location], [source], [on_collision], [preserve_dates], [create_log], [pop_stats], [skip_junctions], [verify], [show_progress]
Re: Scripting Bugs
Posted: 26 Apr 2014 14:14
by zer0
admin wrote: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].
Re: Scripting Bugs
Posted: 26 Apr 2014 18:13
by 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.
Re: Scripting Bugs
Posted: 26 Apr 2014 19:21
by zer0
admin wrote: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.
Re: Scripting Bugs
Posted: 27 Apr 2014 09:26
by admin
I will add another argument in a later version.
Re: Scripting Bugs
Posted: 04 May 2014 21:27
by 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.
Re: Scripting Bugs
Posted: 05 May 2014 10:34
by admin
Cannot confirm.
Re: Scripting Bugs
Posted: 05 May 2014 11:58
by zer0
admin wrote: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.
Re: Scripting Bugs
Posted: 06 May 2014 17:37
by admin
Still: Cannot confirm.
Re: Scripting Bugs
Posted: 06 May 2014 23:22
by zer0
admin wrote: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.
Re: Scripting Bugs
Posted: 07 May 2014 01:48
by 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
Re: Scripting Bugs
Posted: 07 May 2014 09:51
by 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
Re: Scripting Bugs
Posted: 07 May 2014 11:14
by bauxite69
admin wrote: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.
Re: Scripting Bugs
Posted: 14 May 2014 10:13
by 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