How can I get the OK or CANCEL message

[Hoa Tu]

Hi All,

I need to write data of some parameters to a text file using the OPEN ("DATA", ... ).

I can detect when the parameter is modified by using GLOB_MODPAR_NAME, but how can I check the user click the OK or CANCEL button to determine to update the text file or not.


Best Regards,
Hoa

[Barry Kelly]

You won't have the choice.
One of two things will happen - I can't say which without testing.
Either the script will run as you edit the parameters or it won't run until you commit to the change.


One - The text file will not be modified until you press OK. If you press Cancel then there will be no changes and the text file should not be written to (or it will be written to but with the unchanged parameters).


Or Two - the text file will update as the user amends the parameters because the script is run as the parameters are modified.
This is before the OK or Cancel button is pressed so You won't have a choice.
I would then hope that if you press Cancel the object will re-run the script as you return to the plan and will send the unchanged parameters back to the text file.


Either way I think you will be OK - but just do a simple test to see.
As far as I know you can't delay the writing to a text file dependent on the pressing of the OK or Cancel buttons.

Also you could be changing the parameters in plan by stretching or moving hotspots which don't involve pressing OK or Cancel.
So I think the best you can do is say if this parameter is changed then write to the text file.

Barry.

[Hoa Tu]

Thanks Barry. The problem I have is when the user change the parameter, the command is executed and the text file changed. If the user press the CANCEL button, I can't reverse the text file back.

Regards,
Hoa

[Barry Kelly]

OK because you are using GLOB_MODPAR_NAME then as you change the parameter the text file is written to.
Then pressing the Cancel button cancels the parameter change but because you are not physically changing the parameter then the text file does not get written back to.

I don't know exactly what you are doing but all I can thing of is to forget the GLOB_MODPAR_NAME and just update the text file anyway.
That just means it will constantly update.

Or add a switch parameter so the user has to turn it "ON" before pressing OK/Cancel to force the change.
You could add a command to set the switch back to "OFF" after the text file is written to.
i.e. if switch = 1 then write text file then set switch = 0
Not so automatic and you are relying on the user to force the update.

Or maybe you could compare the parameter to the value in the text file.
If the parameter does not match the value in the text file then write the parameter to the text file.
This is essentially the same as using GLOB_MODPAR_NAME but without actually using it.
The text file will only update when the parameter is different and the script the write command is in is run (master script is probably the best choice).

Hopefully there is some suggestion here that you might be able to use.
Again it will take testing to confirm if they will work or not - I was just thinking out loud and haven't tested this myself.

Barry.

[Hoa Tu]

Thanks for your suggestion.

To add a switch to the object is a workaround and not automatic. I just worried that the user changes the parameter but forget to press the switch.
The chance of error is the same as using GLOB_MODAR_NAME.

Hoa

[Frank Beister]

You can detect the "first run". Maybe you can read the file at this time and store the content into object internal parameters or to a second backup file only in this moment. Later, if you click on an object internal, separate button with "undo" you could restore at least the content of the beginning of the current modification.

If you give it a try, could you please post your results here. I would be interested, if it works.

[Hoa Tu]

Hi F. Beister,
Thanks for your idea. Your suggestion is similar to Barry's. It is still not 100% fool prove. But I like your idea of an "UNDO" button to restore the original content. I will give it a try and let you know the result.

Thanks,
Hoa

[Frank Beister]

Another idea is to store the content incremental and saving an index into the file and into one object parameter. Maybe containing the date and time. Reading the file needs to select the last saved value. Undoing switches back to the last index of each value. This way needs comparing, if the last saved value has changed, because otherwise the file would increase unusable fast.

[Hoa Tu]

Hi All,
At the moment, we are settled with a button "Click to save data to external file".
Thanks for your suggestions.
Hoa