|
|
|
Supreme Being
Group: Forum Members
Last Login: 2012-01-26 14:59:09
Posts: 242,
Visits: 828
|
|
| Hi, I exprerienced a strange problem using Undo-Service. Undo works quite fine, but after some Undo-levels it can happen, that corresponding Redo-blocks get lost. I invoke StartUndoBlock from within Idle-thread (CommandManager.RequerySuggested event in WPF), and that is my supposion for a possible reason. I observed in EcoDebugger the blocks get lost after a nested block is created in such manner. I have also impression, Undo-Redo block lists are rebuilt on idle. If it is difficult something to say anything from this description, I'll try to elaborate a compact sample.
/Efim
|
|
|
|
|
Supreme Being
Group: Administrators
Last Login: 2010-11-30 12:17:13
Posts: 1 230,
Visits: 1 382
|
|
The redo blocks are cleared whenever a new change happens anywhere in the cache.
* start an undo block
* Make some changes
* undo topmost block
now the changes will be in the redo-list
* make some other changes
now the redo-list will be empty.
If you still think there is a bug somwhere, I think I'm gonna need a sample project that shows the undesired behaviour.
/Jonas Hogstrom [CapableObjects]
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 2011-06-28 15:42:26
Posts: 487,
Visits: 1 277
|
|
Why not leave these blocks alone until a commit?
/mtiede
Environment:
Windows 7 Ultimate 64 bit
Delphi 6
Rad Studio 2010 Enterprise with Prism 2011
|
|
|
|
|
Supreme Being
Group: Administrators
Last Login: 2010-11-30 12:17:13
Posts: 1 230,
Visits: 1 382
|
|
This is the same behaviour as in most other undo-features I've seen
If you edit in Word, and then undo, you can redo the changes until you have made a new edit. In ECO, it would in teory be possible to only throw away the redo-blocks that conflicts with new edits in the ecospace, but I think it would be rather hard for the average user to understand what block to expect as the topmost redo-block if they can disappear from any location in the redostack.
/Jonas Hogstrom [CapableObjects]
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 2011-07-14 17:05:00
Posts: 290,
Visits: 2 617
|
|
I made a small app demonstrating the behaviour if you'd like to see it?
www.peterlesliemorris.com/blogfiles/ecoredoblocks.zip
====
Pete
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 2012-01-26 14:59:09
Posts: 242,
Visits: 828
|
|
* start an undo block
* Make some changes
* undo topmost block
now the changes will be in the redo-listI guess I know now where is the problem. As I do part of my application logic in "OnIdle", it comes to changes in ECO-Cache after undo topmost block is done, abnd then all redos are lost. In order to preserve my application logic I consider now to execute undo also OnIdle, after all logic changes are done. I'm not sure if the ECO-Cache changes during undos can also cause redo-blocks get lost?
/Efim
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 2012-01-26 14:59:09
Posts: 242,
Visits: 828
|
|
| If you edit in Word, and then undo, you can redo the changes until you have made a new edit Just tried it in Word2003. It is so if you do Redo after Undo. If you do Redo after a manual edit it is funny. If you type some text it will be replicated with each new Redo. If you deleted some characters, so many new characters will get deleted each time so you can end up with the empty page
/Efim
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 2012-01-26 14:59:09
Posts: 242,
Visits: 828
|
|
| Now I see the reason why Redo blocks get lost but don't see a way to solve it. I have a petrsistent attribute in my model that should be calculated via "push-logic": it is logically derived attribute, but derivation is hardly possible because of some dependencies on User Interface. The point is that I need to calculate it OnIdle to avoid unnecessary calculations. On Undo the calculation occurs sometimes *after* Undo is done and the just created Redo-block get lost. I created a WinForms-sample to demonstrate it. It has only one Class Person with attributes LastName and PresentationLength. The last holds the length of Label that contains current person's LastName. It depends on LastName itself and fonts properties (in my real situation there are much more dependencies). Scenario to reproduce the problem: 1. Add Person 2. Change LastName and or font several times -> you see in ECO Debugger some Undo blocks created 3. Press "Undo" several times: at some points invalidation flag isLengthInvalid is fired, and PresentationLength is recalculated -> Redo-information get lost. It is interesting if Undo is fired via EcoAction, not via event handle as in the sample, everything works correct. I'm not sure it is a real Eco bug, but my somehow incorrect implementation, because of that I have not yet put it in Mantis.
/Efim
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 2011-07-14 17:05:00
Posts: 290,
Visits: 2 617
|
|
Calculating on idle seems like the wrong approach to me.
I'd create a method into which you pass the relevant parameters
decimal CalculateSomething(decimal v1, decimal v2, decimal v2, etc)
{
}
In that I would calculate the output based on the parameters and object state. I'd store the result in a non-eco private member and also the values of the parameters. I'd also ensure that I nulled those values if a subscription notified me that any relevant object state changed.
When you next calculate you can simply return the cached result if it has not been set to null.
====
Pete
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 2012-01-26 14:59:09
Posts: 242,
Visits: 828
|
|
| Hi Pete, the approach you proposed would be not quite useful in this situation. I don't really need to recalculate the "derived" member after each change of it's dependencies, but rather after some action in UI. That is why I thought of Idle. As this calculation in my real appication is quite expensive, It is of importance to reduce the number of calculations as much as possible.
/Efim
|
|
|
|