Problems with "save Method as..." and "open method..."

[danisa]

Dear DataApex,

I think I have found some problems in managing method.
The steps to sistematically reproduce the first issue are:

1) open an instrument
2) open property pages
3) change a value
4) press "ok"
5) Click the item "Save method as..." in File menu
6) open the previous method

The first method already have the flag "(modified)" !!
That means: the changes are already in the first method !

I think that there is another problem, going on (using a method with changes!):
1) Click the item "Open method..." in File menu
2) When "method.met has been changed. Save before closing?" messageBox, answer "no".
3) "open Method" window appears. Press "Esc" button to close window

Every change I made isn't in the method!

I think these are issues...
if they aren't, please write me how file manager works.

Thank you,

Agostino Domenico

[Daniel Mentlik]

Dear Domenico,
the first behavior you described is obviously some kind of bug, though I'm not sure it is a lethal one. I have added it to the internal bug database to be repaired in some of the future releases.

Internal issue tracking ID: 31016

On the contrary, the second behavior is an intended one. It is a product of desired behavior - it would not be correct to hold the changes made in the method in memory even if the user pressed "No" for the changes to be saved just in case "Cancel" is pressed later. The changes would be miraculously found from nowhere then.
The other approach would be to leave the question on the time "OK" is pressed in the "Open Method" dialog, but then, what would happen if the user changed his mind and pressed "Cancel" in the following dialog? Should the new method be opened or no, where the user should return etc.

I believe that the implemented behavior is predictable and user is namely asked to either save or delete the changes, or cancel the opening of the method at that point. If he changes his mind later, it is a shame, but the changes performed are already lost, as he ordered them to. Adding some other confirmation step etc. would only hinder normal routine users (1 click more) and still there might be a point from which the user would like to return (after the second confirmation), so the solution is not fool-proof either.