36 replies to this topic

[Alexei]

But if he resets an existing file by FileCreateBlank, this affects other scripts.
Peter

Yes, exactly, that's what I was talking for a while
Why would we need to have all that just because FileCreateBlank was unsafe?
I hope Nuno already fixed it, at list he promised

Alexei

[Brito]

..
Why would we need to have all that just because FileCreateBlank was unsafe?

Would this be FileCreateBlank's fault?

I think this still depends on the end-user..


Someone could also code something like:

DirDelete,"%WindowsDir%"

This would still be considered unsafe unless an enourmous code filtering was imposed. Besides performance wouldn't this also break flexibility?

[Alexei]

Would this be FileCreateBlank's fault?

I think this still depends on the end-user..
Someone could also code something like:

DirDelete,"%WindowsDir%"

This would still be considered unsafe unless an enourmous code filtering was imposed. Besides performance wouldn't this also break flexibility?

Can't agree
Cleaning file by FileCreateBlank is a "side effect" that can be easily overlooked by developer.
Explanation: Developer supposed (wrongly) that file doesn't exist.
DirDelete is obviously intentional
Basically, there are two styles of correct processing of "unexpected situations". I would call them "relaxed style" and "strict style".
relaxed style:
- FileCreateBlank does nothing if file exists.
- DirDelete does nothing if directory does not exist.
- DirCreate does nothing if directory exists.
strict style:
- FileCreateBlank raises error if file exists.
- DirDelete raises error if directory does not exist.
- DirCreate raises error if directory exists.
Deletion of file contents by FileCreateBlank has no analog in DirDelete.
However, if DirCreate erased everything of existing directory, it would be alike FileCreateBlank erasing file contents

I see the fault of FileCreateBlank is that "create"-type call (percepted as safe) deletes information, i.e. acts as "delete"-type call (potentially unsafe).
Should we consider potentially dangerous (spider) in something that looks safe (bed) to be a bug?

It's usually preferable to keep same style (relaxed/strict) throughout the system, or make it depend on "danger level" of the operation.
I would say, relaxed style may be preferable to WinBuilder because:
- We manipulate with the Target, so no real danger is something went wrong.
- Less writing, no need to duplicate names in IF and "call".

BTW, "slacker style":
- first TxtAddLine creates file (no FileCreateBlank ever needed).
- first FileCopy creates target directory.

And the last notes:
- Any "default" or "dangerous" action should be listed in the processing log.
- We can disallow "very dangerous" actions (such as DirDelete) outside the Target. In fact, I really dislike an idea of user-defined path to the Target.

And finally, Nuno may want to add optional "style" parameter to some script commands (with "relaxed" as default for create-like functions and "strict" for delete-like functions).


Alexei

[Brito]

Very good description Alexei!

[pscEx]

Can't agree
Cleaning file by FileCreateBlank is a "side effect" that can be easily overlooked by developer.
...
And finally, Nuno may want to add optional "style" parameter to some script commands (with "relaxed" as default for create-like functions and "strict" for delete-like functions).


Alexei

Peter

[Alexei]

Peter

As we finally agreed with Peter
@Nuno,
Can we have FileCreateBlank not erasing data in the upcoming WinBuilder betta, please?

Alexei

[Brito]

Will comply!

[Alexei]

Will comply!

Thanks

Alexei

[Alexei]

Peter
Isn't it the time (052 betta 7 - FileCreateBlank) to return to TxtAddLine for Autoruns?

Alexei

[h7se]

Run,%AutoRunScript%,Add,%SystemDrive%\Programs\Rename\Rename.exe

is this in a correct format ?

should i use %SystemDrive% or %pedrive% so the script can convert the value correctlly on build time

[pscEx]

Run,%AutoRunScript%,Add,%SystemDrive%\Programs\Rename\Rename.exe

is this in a correct format ?

should i use %SystemDrive% or %pedrive% so the script can convert the value correctlly on build time

If you use %PEDrive% then a hardcoded drive letter (usually X:) will be written into autostart.cmd.
%SystemDrive% will be written as it is. During run of autostart.cmd it will be replaced by the actual drive letter, which usually is X: too, but different in case of FBWF.

A hint: You should use #$pSYstemDrive#$p
Reasaon: If (out of whatever reason) WinBuilder has a variable %SystemDrive% defined, then %SystemDrive% will be replaced by its contents, which is wrong.
The #$p is replaced by % when writing into autostart.cmd. That is the result you want.

Peter

[pscEx]

Run,%AutoRunScript%,Add,%SystemDrive%\Programs\Rename\Rename.exe

is this in a correct format ?

should i use %SystemDrive% or %pedrive% so the script can convert the value correctlly on build time

If you use %PEDrive% then a hardcoded drive letter (usually X:) will be written into autostart.cmd.
%SystemDrive% will be written as it is. During run of autostart.cmd it will be replaced by the actual drive letter, which usually is X: too, but different in case of FBWF.

A hint: You should use #$pSYstemDrive#$p
Reasaon: If (out of whatever reason) WinBuilder has a variable %SystemDrive% defined, then %SystemDrive% will be replaced by its contents, which is wrong.
The #$p is replaced by % when writing into autostart.cmd. That is the result you want.

Peter