Undo for Form Designer working?

[Martin_fr]

undoing, or restoring the form/lfm is not enough.

the source is also modified (components are added/deleted to the Form1 (or other) class); units are added; ....

Those operations would have to be undone too

[IPguy]

But you could restore the whole previous state of the form instead of reversing each operation.

Could this be done by saving the current instance of the form (.lfm) and showing the user which prior version of the form they want to revert to?

The problem with this simple undo is that it does not affect the code.  It would work if form objects were moved around, but the application might have problems if several objects had been deleted then the user, after undo, expects the app to compile correctly with several of the original  Shape1:  TShape;   declarations missing (for example).

[IPguy]

How about showing me (in a form sheet/window?) the specific instances of objects I've deleted and allowing me to drag / drop (or copy/paste) them back into my form?

That way I can see which objects I've deleted, what the object customizations were (ie: labels, colors, size, shape,etc..).

This undo would only be valid for the current instance of the editor and all of the saved undo objects would be cleaned up when the editor shuts down?

I do realize this is not a trivial task and I can live without it, but it would be nice.

Assuming nothing changes for a while, could the "undo" menu be disabled out when the focus is in a form and enabled when in an edit window?  At least we would set expectations about when Undo will not function.

[typo]

Those operations would have to be undone too

My point is: you could save the whole files, also the PAS file, before each operation and restore them back instead of reverting the operation.

If so, even the uses section should be restored, which not occurs if one deletes a component. I don't know how it would interact with undo feature of the code editor, however.

This undo would only be valid for the current instance of the editor and all of the saved undo objects would be cleaned up when the editor shuts down?

Of course once one has closed the IDE, undo feature is gone.

[Blaazen]

How is adding component done?

I presume that when I click TButton on Component Palette and click the form then some TButton.Create is done for design-time form and *.lfm is generated later.

[typo]

You can see it on designer/designer.pas, line 1880.

[Blaazen]

Thanks.

My idea is that trash would be a simple list whose items would be pointers to (not really) deleted components.
When someone deletes any component then it will not be really deleted (like TButton.Free) but will stay created and pointer on it will be added to trash-list.

Restoring component from trash is then similar to creating new component with at least three differencies:
1) Creating component is not necessary
2) Check if component's previous parent is still present
3) Check component's name duplicity.

Adventage of this solution is that there is not necessary do any change with Source Editor.

Of course user's can delete Panel with some components on it at once which is next problem.

[typo]

My approach is similar to that used for undoing image editions.

[Martin_fr]

Thanks.

My idea is that trash would be a simple list whose items would be pointers to (not really) deleted components.
When someone deletes any component then it will not be really deleted (like TButton.Free) but will stay created and pointer on it will be added to trash-list.

That may cause issues too:

Scenario Button1 and Button2; Button2's left side is anchored to Button1 (so the Anchorside has a pointer to button1)

When you delete button1, then the anchor must be removed.

AFAIK, that is done by "TComponent.Notification" (something automatically done, on destruction).

So if you do not destroy, then you have an invalid anchor.

And, independent of how you store the information, you must find such additional changes too, as undo should restore the anchor, I guess

Restoring component from trash is then similar to creating new component with at least three differencies:
1) Creating component is not necessary
2) Check if component's previous parent is still present
3) Check component's name duplicity.

Check for anchors, check inheritance (if frames are involved, or visual form inheritance..., check events, scheck duplicate event names, datasource dependencies, other links to other components ...

The list of dependencies is endless.
On the other hand, a system that undoes every step (across all forms), then that ensures that at the time of an undo, the entire state is exactly as it was at the time of the action (since all changes after the action were undone)

Advantage of this solution is that there is not necessary do any change with Source Editor.

How so?

Unless you leave the line
  Button1: TButton;
If you delete button1, (even if you move it into a trash) you must remove this line.
so you must restore it on undo?


And thats another already existing issue. Any changes to the source, are part of SynEdits undo list (and must be, because synedit, stores undo in a way that requires them to be complete.

So if you press undo in the edit, you may just delete the line
  Button1: TButton;
but the component remains.....

You can not exclude the insertion of this line from synedit's undo info, or you loose all undo from before....

So the final goal would have to be one single unified undo system across the entire IDE; or at least for each source and form together (but then you need to ensure that form undo does not fail on frames etc).

------------------
Of course not all of it has to be done in one step...
But you have to keep it in mind.

[Blaazen]

I forgot the anchors. Yes, it is problem.

Quote:
Advantage of this solution is that there is not necessary do any change with Source Editor.
How so?

I was not clear.

Advantage of this solution is that there is not necessary do any change IN WORKING with Source Editor.

Current state:
Add component:
  Button1: TButton;  //line is added  (and possibly something to uses lists for some components)
Delete component:
  Button1: TButton;  //line is deleted (AFAIK uses lists is not affected)

Trash:
Restore component:
  Button1: TButton;  //line is added  (and possibly something to uses lists for some components)
Delete component to trash:
  Button1: TButton;  //line is deleted (uses lists is not affected)

So, no change.

[JuhaManninen]

Assuming nothing changes for a while, could the "undo" menu be disabled out when the focus is in a form and enabled when in an edit window?  At least we would set expectations about when Undo will not function.

This is a valid suggestion. I disabled Undo and Redo now when designer is active.
Even this was kind of a hack because the command dispach system is a mess. Neither Undo/Redo nor Copy/Paste from menu are forwarded to form designer. It means you can use shortcuts but not menu items for Copy/Paste in designer.
I hope the command system gets fixed and cleaned by the core developers.

Otherwise this discussion has been rather useless. Sorry...
I also have many "ideas" and "approaches" but they have no importance if I don't know how the existing code works and how I can implement those ideas and approaches.

It is like : "Talk is cheap, show me the code" as one open-source person said.

No offence meant for anybody personally.

Regards,
Juha

[Jishaxe]

I swear once I deleted a component and pressed Ctrl+Z to restore it. Or maybe it was a dream :L

[Sanchoyzer]

Good day. I want to implement a function of the complete undo\redo of the Form Designer. Excuse me, I write in the subject, which is not updated for a long time, but I think my thoughts are a logical extension of the existing messages. And sorry for my English.

After reading the existing solutions, I have formed a 7 options, one of which I think to implement in the code:

For the PAS:
1.    Changes:
          insert  modified remove
*. Pas    +       -             +
*. Lfm    +       +             +

Since the changes in the *. pas-file will only occur when adding or removing, the need to implement the inverse function + function text search (fast enough, such as the KMP).
Inverse function of removal: find a place (Class), where to insert (using a text search), add the appropriate ad.
The inverse adding: find a place (Class), which removed (using a text search), delete the row.

2. Divide all the time with Lazarus into 2 periods: the work in the form editor and the rest of the time. We believe that while the user in the form editor, it does not change the *. pas-file, so undo \ redo will operate only during the active form editor. When you switch to Form Designer ability to undo \ redo disappear. Changes in the code can be done the usual (already implemented) undo \ redo for the code editor. Or, to save every time you change the form *. pas-file and store the last N = N files change.

For LFM:
1. We completely keep a list_1 (by time) lists_2 (by space of form) of objects. That is, with any operation, the new item of list1 will create, in which list_2 of all elements of the form with all fields \ methods. Undo \ redo is iterating on the list_1.

2. We keep a list of objects, ie at any operation object is added to this list, which changed its status \ add \ remove + the type of operation for him. Iteration is implemented undo \ redo functionality.

By combining these methods, we obtain 2 * 2 = 4 = IV option.

V) Since the changes in the *. lfm-file occur with any operation, it is necessary to maintain its integrity and relevance. We will store the last few versions (states) *. lfm. Undo \ redo will be realized through the implementation of diff over the two neighboring (in time) states of the form. So we find the fields\ method that has been modified \ add \ remove, and then all of the same text search find the right place in the pas-file.

VI) Making the mechanism undo \ redo is not automatic, and controllable by the user: pressed save - save the state of the project (for example, by saving lfm- and pas-files), pressed undo - returned to the saved state. Thus we carry all the responsibility for maintaining the relevance and integrity on the shoulders of the user. In addition, you can make an optional auto-save after every certain number of minutes.

VII) Pointer Relocation Map (PRM). Some way to add monitoring a pas-file to scheme PRM. In the process...

These methods should maintain synchronization *. pas, and *. lfm files, and (in theory) there should be no situations with the disappearance of the code in the *. pas, and incorrect processing of contacts, such as anchors.

Accordingly, to obtain the object's state will be using rtti: TPropInfo, TPropList and the like - from <fpc\2.6.0\source\rtl\objpas\typinfo.pp>.
Catch the change \ add \ remove the object will be using GlobalDesignHook: TPropertyEditorHook, which of the module <laz\ideintf\proredit.pp>, namely, using the functions like AddHandlerComponentRename, RemoveHandlerComponentRename, AddHandlerPersistentDeleting and other. We will have observe the state in the property OnModified from module <laz\designer\designer.pp>.

That's it. What will say the community?

[JuhaManninen]

Sounds good!
You will surely surprise me and some other people if you actually do it.
Waiting to see your patch...

Regards,
Juha