View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0029884 | Community | OCCT:Application Framework | public | 2018-06-20 10:56 | 2020-05-08 18:31 |
| Reporter | Vico Liang | Assigned To | bugmaster | ||
| Priority | normal | Severity | minor | ||
| Status | closed | Resolution | no change required | ||
| Target Version | 7.5.0 | ||||
| Summary | 0029884: Application Framework - Calling sequence of BeforeUndo() and AfterUndo() unpredictable | ||||
| Description | Undo/redo delta sequence is base on label tree hierarchy. Base on this assumption, attributes may be designed with dependency with each other. The predict behavior is that BeforeUndo() and AfterUndo() will be called in the label tree hierarchy order. Actually, the order is unpredictable. The reason is TDF_Data::FixOrder() adjusted the delta order to fix another bug 0029142. It seems ugly and unnatural with such order fix. | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
|
My use case looks like this, the application is base on TObj package, TObj_TObject rely on AfterUndo() to recover object from death and My_AISPresentation rely on BeforeUndo() and AfterUndo() to do presentation update. My_AISPresentation is designed to depend on TObj_TObject. It will crash during presentation updating on undo/redo because AfterUndo() of TObj_TObject is not called before My_AISPresentation. |
|
|
Dear Vico, For such purpose, the BeforeUndo and AfterUndo methods return boolean values. If My_AISPresentation returns false, it will be called once again after TObj_TObject methods are called. To simplify implementation you may return false and do nothing in My_AISPresentation::BeforeUndo and My_AISPresentation::AfterUndo while forceIt argument is false. If it is true, perform the needed action (using the dependency on TObj_TObject) and then return true. Sorry for late response. Does this note help you? |
|
|
Dear mpv, Thanks for your response and help. I think it should work in my case.My simple dependancy can be corrected in this way. I would be better if the calling sequence BeforeUndo() and AfterUndo() obey the label tree structure.This rule is very useful in most situation during design application structure.It's a little tricky as you way during design application framework.I like a more general way. |
|
|
Dear Vico, I would disagree that order related to the labels structure is flexible and suitable enough for all cases. Depended objects may be located in any way: lower or upper in the tree or in a flat list of children. So, any approach here could not help everybody. But the current approach allows to keep dependency and the order of execution of undo/redo actions in any needed way and well-corresponds to the object-oriented approach. So, I'm closing this issue. |
|
|
Dear bugmaster, please close this issue. Fix is not needed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-06-20 10:56 | Vico Liang | New Issue | |
| 2018-06-20 10:56 | Vico Liang | Assigned To | => mpv |
| 2018-06-20 11:08 | Vico Liang | Relationship added | related to 0029142 |
| 2018-06-20 11:14 | Vico Liang | Note Added: 0076843 | |
| 2018-06-20 11:15 | Vico Liang | Note Edited: 0076843 | |
| 2019-07-10 09:01 |
|
Target Version | 7.4.0 => 7.5.0 |
| 2020-04-22 10:47 |
|
Note Added: 0091712 | |
| 2020-04-22 10:47 |
|
Assigned To | mpv => Vico Liang |
| 2020-04-22 10:47 |
|
Status | new => feedback |
| 2020-05-08 00:14 | kgv | Summary | Calling sequence of BeforeUndo() and AfterUndo() unpredictable => Application Framework - Calling sequence of BeforeUndo() and AfterUndo() unpredictable |
| 2020-05-08 15:06 | Vico Liang | Note Added: 0092012 | |
| 2020-05-08 15:16 | Vico Liang | Assigned To | Vico Liang => mpv |
| 2020-05-08 15:38 |
|
Note Added: 0092013 | |
| 2020-05-08 15:38 |
|
Status | feedback => resolved |
| 2020-05-08 15:39 |
|
Note Added: 0092014 | |
| 2020-05-08 15:39 |
|
Assigned To | mpv => bugmaster |
| 2020-05-08 15:39 |
|
Status | resolved => reviewed |
| 2020-05-08 18:31 | bugmaster | Status | reviewed => closed |
| 2020-05-08 18:31 | bugmaster | Resolution | open => no change required |
