Home » Modeling » Graphiti » Custom feature always marks editor as dirty
| | | | | |
| Re: Custom feature always marks editor as dirty [message #653530 is a reply to message #653136] |
Thu, 10 February 2011 06:51   |
 Volker Wegert
Messages: 182
Registered: July 2009 |
Senior Member |
|
|
Tim,
after some digging, I found out that the problem is actually a
CommandStackListener that is notified whenever a transaction is commited, then
checks whether the command stack needs saving and flags the editor as dirty if
appropriate. (This is a multi-page editor with two pages containing Graphiti
editors, the other pages are "classic" editors - so I need something that
works for all pages.). At that time, the transaction is not undone, so the
editor is marked dirty. :-(
At the moment, the only thing I can think of as a partial solution would be
something like a "delayed check" - in the listener implementation, wait half a
second before checking the status of the command stack. Is there a better way
to do this?
Thanks
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
"Wir müssen lernen, gegenseitig unsere Theorien umzubringen statt uns selbst."
(Karl Popper)
|
|
| | |
| Re: Custom feature always marks editor as dirty [message #653842 is a reply to message #653795] |
Fri, 11 February 2011 13:47 |
Volker Wegert
Messages: 182
Registered: July 2009 |
Senior Member |
|
|
Michael,
thanks for the time you're taking for this.
"Michael Wenz" <michael.wenz@sap.com> writes:
> actually, there is a similar pattern in the Graphiti editor as well: we also
> have a command stack listener (FWCommandStackListener) that triggers the
> editor being marked dirty. But that happens via Display.asyncExec (the
> marking anyway needs the UI thread). In the async exec we do a
> firePropertyChange that again triggers isDirty in the editor; there the
> command stack is queried. At the time the async exec runs tha command stack
> is clean again.
For some reason, this does not work within my editor. I've even added a delay
of several seconds, to no avail - after the aborted action, the command stack
alway insists on isSaveNeeded(). The WCSI checks for an undoable operation and
receives my feature operation (that did nothing). It is (understandably)
unable to determine that this operation didn't change anything and has to
assume that something has happened.
> I just noticed that after the romoval of the command from the stack we call
> notifyListeners(Command, int) which only notifies the registered
> CommandStackEventListeners but not the CommandStackListeners; the latter
> would be done by calling notifyListeners() (no parameters), but this method
> is deprecated in the GEF command stack, no idea why. But this is probably
> the reason why we don't call that method.
I don't think I can use that - I've got a mixed editor with GEF and non-GEF
parts. As far as I can see, CommandStackEventListeners are GEF-only stuff
while the CommandStackListeners are attached to the underlying EMF domain
model.
I'm still unsure about this, but I think a feature should be able to signal to
the framework "User pushed the Big Red Button, undo the entire transaction"
somehow...
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
"Wir müssen lernen, gegenseitig unsere Theorien umzubringen statt uns selbst."
(Karl Popper)
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 08:53:59 GMT 2024
Powered by FUDForum. Page generated in 0.04506 seconds |
] 
Search
Help
Register
Login
Home
