Yes it is the undo/redo states which are the biggest pain and is where Demento steps in to help out. It handles the undo stack automatically and keeps a track of any invalidated entries etc. The rest of it, i.e. the application dependant part of the undo/redo should be taken into account in the design of the host application and the design of the state-objects. Once you have figured out the info you need to store in the state-objects then you are half-way there. This information will essentially comprise that which you will have been using anyhow in your own implementations of undo/redo.
In terms of 1) do this... 2) do that... I can summarise thus... 1) take a look at the existing demo!
If you have written your own undo/redo in the past then you will have absolutely no problem figuring out how to use Demento and whether it will be of any use etc.
I may look like a mule, but I'm not a complete ass.
Beta 2 is effectively a completely new version of Demento. The earlier version didn't quite sit right with me.
It also comes with a detailed user guide (pdf format) which outlines the steps involved in using Demento to assist with the implementation of an undo/redo facility.
In terms of the biggest difference between beta 1 and beta 2 (which will only be of interest to those who delved head first into the first version) I would point out that this new version does not allocate any memory itself. Not a bean! There is no longer the danger of Demento running out of memory when hundreds and thousands of undo actions are being recorded etc. because it does not allocate any! Instead it works with a 'virtual undo stack' which makes a lot more sense given the generic nature of Demento itself.
This new version also encourages the host application to allocate larger chunks of memory in which to store multiple state-objects which makes for a much more efficient use of memory etc. You can see this with the new demo program. You will also see (in the demo) how Demento notifies the host that it can claim memory back under certain conditions etc.
Beta 2 just makes the whole business easier (when compared to the first beta!)
The manual discusses state-history and state-objects in some depth and I hope goes some way to making this utility easier to understand and indeed easier to use.
I may look like a mule, but I'm not a complete ass.
Srod, I have a couple of questions.
Can I use the structure pointers to fragments of memory?
Obviously I can. But it is not clear how to free and allocate.
After all the control in the hands Demento.
And another question. How do I make navigating through the history?
How this is done in Photoshop and other similar editors?
(how do you know the number of elements undo and make the current any? )
Yes pointers to 'fragments' of memory, as you put it, are not a problem.
If you look at my demo you will see that, when you create your Demento object, you specify an initial size for the 'state history' (i.e. the number of undo/redos you can store). In the demo I specify an initial history size of 100. This value is a guarantee to Demento that there is sufficient memory put aside for 100 state-objects. Indeed, look above this line in the demo and you will see that I allocated enough memory for 100 state-objects (in the demo a state-object equates to a 20-byte stateObject structure).
The point is that you should allocate some memory first (or disc space etc.) and then create your Demento object only if the allocation is successful. During the life of your Demento object, you will be sent notifications of when this memory needs to be increased or can be safely decreased etc.
When an individual state-object is to be freed (because the undo/redo entry it contains has been invalidated) then your Demento callback is sent a #DEMENTO_DESTROYSTATEOBJECT notification with wParam the index of the element to be freed. Now in the case that you have allocated a huge block of contiguous memory to hold your state-objects (as with the demo) then you probably do not want to free the underlying memory for the individual state-object because you will undoubtedly like to reuse it as required for a different undo action etc. Instead, you would take steps to just clear the memory of any dynamic strings etc. (use ClearStructure() for example) but otherwise do not free the memory so that you can reuse it.
In the demo, you will see that I do nothing in response to the #DEMENTO_DESTROYSTATEOBJECT notification because the underlying stateObject structures do not contain any dynamic strings etc. They just hold integers. At the program's end I free the entire block of memory holding all of the state-objects in one go.
My Pyrex designer, for example, uses Demento for multiple undo/redos and, in this case, I again use a contiguous block of memory to hold the state-objects and in this case the state-objects do contain dynamic strings. When Pyrex then receives a #DEMENTO_DESTROYSTATEOBJECT notification, it uses ClearStructure() on the appropriate memory address to wipe out these strings, but does not free the memory. Again, all state history memory is freed when the appropriate report object is destroyed etc.
As for navigating through the history... Demento does not offer that facility up front. However, there's nothing stopping you doing this by requesting multiple undos via the \GetUndo() method. This method of course doesn't actually undo anything, it just returns the appropriate state-object index etc. So, if you invoke this method repeatedly, then you will be furnished with the appropriate indexes which you can use to construct the history yourself. Just remember to match all undo's with a redo unless you actually decide to undo the actions in question through the host application etc.
I may look like a mule, but I'm not a complete ass.
The earlier version didn't quite sit right with me.
