how can i use 'undo' feature

MonkeyKing, I'm going to address your question in three parts:

Availability of CheckPointing Feature in Different DevForce Editions
Please note that Checkpointing is now available in all editions of DevForce - see the Compare Features chart for your edition of the product (e.g., http://www.ideablade.com/DevForceUniversal/DevForceUniversalEditionCompare.aspx for DevForce Universal).

Facilities for Undo

DevForce supports several forms of undo:

1. EntityManager.RejectChanges() restores all entities in an EntityManager's cache to their "Original" state; that is, their state when last retrieved from the data source.
2. anEntity.EntityAspect.RejectChanges() will do the same for any single Entity.
3. Checkpointing permits you to set cache state markers to which you can roll back. Thus you can set a checkpoint (or multiple nested checkpoints), make any number of changes of any kind to the entities in the cache, and then undo all of those changes by rolling back the cache to its state at the checkpoint.

Supporting Save-By-Form

For a use such as you describe however -- providing the end user the ability to cancel all changes made through a particular editing form -- the only really practical architecture is to use a separate EntityManager for each constellation of data for which you wish to support selective rollback. For example, suppose you have a Customer form that permits you to make changes to Customers, the Orders they placed, and the line items (OrderDetails) of those Orders. You have another form, for Sales Representatives, that permits you to make changes to SalesReps, the Orders they wrote, and the line items (OrderDetails) of those Orders.  You would need one EntityManager for the Customer/Order/OrderDetail complex and a different EntityManager for the SalesRep/Order/OrderDetail complex in order to permit the user selectively to undo changes made through the Customer and SalesRep forms.

Note also that a certain amount of complex data management is inherent in such a scheme. If both the Customer and SalesRep form permit editing of Orders and OrderDetails, there is every possibility that the same Order and/or OrderDetail entity could be change via both forms, in two different ways, in a single application session. A user could thus create a concurrency conflict with herself!

So you'lll have to decide how you want to handle this possibility. One option would be simply to keep the two sets of data (in the two caches) completely independent, so that a change to an Order through the Customer form would not show up in the SalesRep form -- even though the same Order were displayed there -- until and if the changes made in the Customer form were saved and the data in the SalesRep form was subsequently refreshed from the database. Another approach would be to watch the Orders carefully and convey any change made on any form to the copy of the same Entity displayed on any other form. That's probably a lot easier for users to understand, but it's also more difficult to write.