When unchecking this option and clicking OK, the option is still checked if the action is reopened.
The same if the project is saved and reopened.
Next question I asked myself: Could it be that the option is correctly stored in the script, but displayed incorrectly?
Turns out this is likely the case.
Tested in this way:
1) Opened the action dialog.
2) Toggled the option a few times, and let it end up either checked or unchecked.
3) Run script and see what happens.
If checked before OK: The directory was actually forced created.
If unchecked before OK: Error message “Win32 Error: The system cannot find the path specified”.
I haven’t bothered to also check the script content. Still, it is reasonable to conclude that the option is correctly stored in the script, but the checkbox state is not read from the script as it should when the dialog is opened.
FinalBuilder version: 7.0.0.2056
Windows version: Windows 7 Ultimate, Service Pack 1, all updates as of date.
See also the report with title “Irratic failure of Copy File(s) Method.”
See also the report with title “Copy File(s) single file rename problem”. From the discussion it seems obvious this issue caused some confusion, but you didn’t see the possibility of a bug and where it was hiding.
Suggest you search other reports as well.
Hi Bent
I finally found some time to investigate this issue further. I have not been able to reproduce the win32 error. The behaviour of Force Directories option is a bit complex, as it is forced on when certain combinations of other options are set. I have made some changes to allow the option to be turned off more easily, however I suspect all that will do is make the action fail more often. The Force Directories option is needed because the windows copy api does not create the destination directory if it does not already exist, and the copy will fail.
One thing I forgot to tell, which may have made my explanation difficult to understand: I deleted the directory every time before running the test script. Before step 3 in my explanation. Please reread with that in mind.
In this way I would either see the win32 error, and not see a new directory, confirming that “force directories” was actually not in effect, or I would see the directory being created, confirming that “force directories” was actually in effect.
Then the testing revealed that “force directories” was stored and retrieved correctly in all cases, because the script acted correctly in all cases, using the value that was actually stored by the dialog earlier.
The only problem I did see was that “force directories” was initially checked in the dialog box even when it shouldn’t be, when I reopened the dialog. I suspected it wasn’t read from the script, but simply defaulted to “checked”.
This behavior - that the dialog shows a checked “force directories” when it is actually unchecked - is what I think has caused some confusion, and probably is the actual but still undetected cause of the problem in the other reports I have referred to. It’s some weeks ago now, but I think that was my thoughts back then.