Hi,
To make it even worse:
you can also do 'accept' on a workspace -- with no other effect than
that the 'modified' marker will vanish and that any further 'cancel's
will  just be interpreted as no-ops. So the quick fix would be to do
an accept on every workspace open.
The slighlty cleaner fix would be to remove _both_ entries from the menu
so people don't get irritated any more.
The right thing to do would certainly be to add a 'lastAcceptedText'
instVar to
Workspace so that accept updates this text, cancel reverts.

More to the point:
Do not expect the menu choice 'cancel' to do nothing. It is meant to
cancel
some operation that is in progress. In the case of a workspace that
would
be the editing operation and so it _is_ reasonable behavior to revert to
the
empty text when no 'accept' has taken place since the workspace was
opened.
(note i said reasonable, not desirable). If you're in the process of a
method
accept and are given the menu choice to 'cancel' this will mean you back
out
of the accept but the edits are not reverted. I think users should be
able to deal
with these 'modes' (and have been since the dawn of squeak).
I've attached my accepting workspace fwiw.

HTH,
Torge

Markus Fritsche <Fritsche.Markus at gmx.net> wrote:
> Hi!
> 
> Is it right, that (windows-) right-click (should I buy nail polish for 
> my mouse buttons?) on a workspace and select "cancel" (when I want to 
> cancel the menu - I got used to cancel unwanted menus with "cancel", 
> call me windows infected if you like), the workspace is cleared. No undo 
> (cmd-z) is possible.
> 
> Is this the expected behaviour?
> 
> Regards, Markus
> 
> -- 
> http://reauktion.de/archer/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AcceptingWorkspace.2.cs.gz
Type: application/octet-stream
Size: 946 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20021229/4c6f1f02/AcceptingWorkspace.2.cs.obj