Discussion :

[MiJack]

Bonjour,

Dans le développement d'un logiciel, je suis confronté au problème de sauvegarder l'historique des manipulations de l'utilisateur pour mettre en place un système de style Undo/Redo (Ctrl-Z, Ctrl-Y), je pense que vous voyez ce que je veux dire. Inutile de préciser que l'utilisateur peut effectuer une foule de manipulations différentes qu'il est difficile de "stocker".

J'aimerais savoir si l'un d'entre vous a déjà été confronté à ce type de réflexion et pouvais m'aiguiller dans mes recherches.
Merci d'avance

[LadyWasky]

En fait, il y a deux façons d'implémenter le Undo/Redo :

-Il y a la méthode différentielle qui n'enregistre que la modification elle même.

Avantage : l'implémentation Undo/Redo sur un grand nombre de modifications successive est possible.

Inconvénient : en général on doit calmer ses ardeurs et ne proposer qu'un nombre limité de types de modifications (copier, coller, effacer) différentes.

Le Undo consiste donc à effectuer l'opération inverse.


- Il y a la méthode statique qui consiste, avant chaque modification de sauver l'état complet du système (j'entend par là l'ensemble des propriétés d'un document par exemple).

Avantage : on se fiche complêtement du type de modification qui est responsable du changement d'état, celà autorise le Undo sur un très grand nombre de types de manipulation différents.

Inconvénient : Si le système est complexe, on se retrouve vite à sauvegarder une foultitude de paramètres qui remplissent un disque dur comme un rien. Ce qui limite le nombre de Undo successifs autorisés.

Sinon, je pense qu'il doit y avoir moyen de trouver un compromis entre les deux méthodes.

voilà, voilà.
Peut-être n'avais tu pas pensé à la seconde approche mais peut-être qu'elle ne répond pas tout à fait à tes attendes.

En tout cas, par expérience, les Undo/Redo, c'est génial, mais pas pour les usines à gaz...

[Caine]

De mémoire, il me semble qu'il existe un Design Pattern sur le sujet non?

Je crois me souvenir que dans ma première boîte c'est ce qu'ils utilisaient.

Ca ressemble à la deuxième méthode donnée par Waskol: Il y avait deux tables, Undo et Redo. Dans ces tables, ils sauvaient les objets modifiés.

Dans le même temps, l'application était accès graphies et traitement de texte, donc les objets à sauver étaient clairement identifiés.

[MiJack]

Dans mon cas, il y a énormément d'objets différents à sauvegarder. Je pense que je vais me tourner vers la première méthode. Cela signifie toutefois de clairement identifier chaque action de l'utilisateur et de savoir comment revenir en arrière.

Si je comprends bien, lorsque l'utilisateur clique sur un bouton par exemple, l'action effectuée est notée dans une table, et lorsque l'utilisateur appuie sur "Undo", il faut chercher la correspondance inverse de cette action pour l'exécuter. Donc cela implique de garder dans un certain endroit toutes les correspondances entre l'action et son contraire. Mon raisonnement est correct ?

[Caine]

Oui, c'est ça.

Il va falloir bien penser le système, et découper les actions en actions atomiques je pense.

Le mieux est peut être un mixage des deux méthodes.

[the big ben 5]

Je confirme qu'il y a un patenre undo oui oui :-)
et peut etre que http://www.codeproject.com/csharp/SharpEd.asp t aidera non?

[MiJack]

Merci pour vos réponses, elles devraient me permettre de traiter ce problème au mieux