Home » Eclipse Projects » Eclipse Platform » Best Practice for FormEditor's dirtyState/saving
| Best Practice for FormEditor's dirtyState/saving [message #333958] |
Wed, 14 January 2009 11:58  |
Eclipse User |
|
|
|
Hi,
I'm currently writing a formeditor and have a small problem updating the
dirty state as well as not saving in some cases.
The data for the editor comes from a model, which allows manipulation and
also has a listener-interface to notify about changes. The editor's GUI
elements now directly change the model and the editor gets notified as it
is a listener. So far no problem, now one of the GUI elements is a table
using cell editors and it turns out that those cell editors commit any
changes as soon as they loose focus. Most of the time that is ok, except
when they loose focus because the user clicked on the close button of the
editor.
I'm wondering now how others do this, I'd like to avoid creating a duplicate
of the model's data in memory, but thats the only viable option I see right
now.
Andreas
|
|
| |
| Re: Best Practice for FormEditor's dirtyState/saving [message #333964 is a reply to message #333958] |
Wed, 14 January 2009 12:48  |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 1/14/2009 11:58 AM, Andreas Pakulat wrote:
> Hi,
>
> I'm currently writing a formeditor and have a small problem updating the
> dirty state as well as not saving in some cases.
>
> The data for the editor comes from a model, which allows manipulation and
> also has a listener-interface to notify about changes. The editor's GUI
> elements now directly change the model and the editor gets notified as it
> is a listener. So far no problem, now one of the GUI elements is a table
> using cell editors and it turns out that those cell editors commit any
> changes as soon as they loose focus. Most of the time that is ok, except
> when they loose focus because the user clicked on the close button of the
> editor.
>
> I'm wondering now how others do this, I'd like to avoid creating a duplicate
> of the model's data in memory, but thats the only viable option I see right
> now.
The way we do it in Skyway is to override
org.eclipse.ui.part.EditorPart.isSaveOnCloseNeeded() and in there check
if one of this editor's widgets has focus; if so we force a focus-out event.
public boolean isSaveOnCloseNeeded() {
// If one of this editor's widgets has focus, make sure it fires change
notification to
// update the model before asking if save is needed.
Control focusedChild =
EclipseUIUtils.getFocusedChild(getActivePageInstance().getMa nagedForm().getForm());
if (focusedChild != null) {
focusedChild.notifyListeners(SWT.FocusOut, null);
}
return super.isSaveOnCloseNeeded();
}
Hope this helps,
Eric
|
|
|
| Re: Best Practice for FormEditor's dirtyState/saving [message #333986 is a reply to message #333964] |
Thu, 15 January 2009 06:20 |
| Eclipse User |
|
|
|
Eric Rizzo wrote:
> On 1/14/2009 11:58 AM, Andreas Pakulat wrote:
>> Hi,
>>
>> I'm currently writing a formeditor and have a small problem updating the
>> dirty state as well as not saving in some cases.
>>
>> The data for the editor comes from a model, which allows manipulation and
>> also has a listener-interface to notify about changes. The editor's GUI
>> elements now directly change the model and the editor gets notified as it
>> is a listener. So far no problem, now one of the GUI elements is a table
>> using cell editors and it turns out that those cell editors commit any
>> changes as soon as they loose focus. Most of the time that is ok, except
>> when they loose focus because the user clicked on the close button of the
>> editor.
>>
>> I'm wondering now how others do this, I'd like to avoid creating a
>> duplicate of the model's data in memory, but thats the only viable option
>> I see right now.
>
> The way we do it in Skyway is to override
> org.eclipse.ui.part.EditorPart.isSaveOnCloseNeeded() and in there check
> if one of this editor's widgets has focus; if so we force a focus-out
> event.
Well, that doesn't really help here. The focus loosing already works as
expected. The problem is that there doesn't seem to be a hook to do
something if the user chose "No" on the save-dialog, hence I cannot reset
my model for that case.
Andreas
|
|
| |
| Re: Best Practice for FormEditor's dirtyState/saving [message #333998 is a reply to message #333986] |
Thu, 15 January 2009 09:10 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 1/15/2009 6:20 AM, Andreas Pakulat wrote:
> Eric Rizzo wrote:
>
>> On 1/14/2009 11:58 AM, Andreas Pakulat wrote:
>>> Hi,
>>>
>>> I'm currently writing a formeditor and have a small problem updating the
>>> dirty state as well as not saving in some cases.
>>>
>>> The data for the editor comes from a model, which allows manipulation and
>>> also has a listener-interface to notify about changes. The editor's GUI
>>> elements now directly change the model and the editor gets notified as it
>>> is a listener. So far no problem, now one of the GUI elements is a table
>>> using cell editors and it turns out that those cell editors commit any
>>> changes as soon as they loose focus. Most of the time that is ok, except
>>> when they loose focus because the user clicked on the close button of the
>>> editor.
>>>
>>> I'm wondering now how others do this, I'd like to avoid creating a
>>> duplicate of the model's data in memory, but thats the only viable option
>>> I see right now.
>> The way we do it in Skyway is to override
>> org.eclipse.ui.part.EditorPart.isSaveOnCloseNeeded() and in there check
>> if one of this editor's widgets has focus; if so we force a focus-out
>> event.
>
> Well, that doesn't really help here. The focus loosing already works as
> expected. The problem is that there doesn't seem to be a hook to do
> something if the user chose "No" on the save-dialog, hence I cannot reset
> my model for that case.
I guess you'll have to try to explain your problem in a different way,
because it sounded to me that you were facing the problem that closing
the editor while a widget has focus is not triggering a focus-lost
event, but rather just going into the sequence that calls
isSaveAsCloseNeeded().
After re-reading your original question and the follow-up, I have no
idea the exact scenario you are trying to handle.
Eric
|
|
|
| Re: Best Practice for FormEditor's dirtyState/saving [message #334009 is a reply to message #333998] |
Thu, 15 January 2009 11:37 |
| Eclipse User |
|
|
|
Eric Rizzo wrote:
> On 1/15/2009 6:20 AM, Andreas Pakulat wrote:
>> Eric Rizzo wrote:
>>
>>> On 1/14/2009 11:58 AM, Andreas Pakulat wrote:
>>>> Hi,
>>>>
>>>> I'm currently writing a formeditor and have a small problem updating
>>>> the dirty state as well as not saving in some cases.
>>>>
>>>> The data for the editor comes from a model, which allows manipulation
>>>> and also has a listener-interface to notify about changes. The editor's
>>>> GUI elements now directly change the model and the editor gets notified
>>>> as it is a listener. So far no problem, now one of the GUI elements is
>>>> a table using cell editors and it turns out that those cell editors
>>>> commit any changes as soon as they loose focus. Most of the time that
>>>> is ok, except when they loose focus because the user clicked on the
>>>> close button of the editor.
>>>>
>>>> I'm wondering now how others do this, I'd like to avoid creating a
>>>> duplicate of the model's data in memory, but thats the only viable
>>>> option I see right now.
>>> The way we do it in Skyway is to override
>>> org.eclipse.ui.part.EditorPart.isSaveOnCloseNeeded() and in there check
>>> if one of this editor's widgets has focus; if so we force a focus-out
>>> event.
>>
>> Well, that doesn't really help here. The focus loosing already works as
>> expected. The problem is that there doesn't seem to be a hook to do
>> something if the user chose "No" on the save-dialog, hence I cannot reset
>> my model for that case.
>
> I guess you'll have to try to explain your problem in a different way,
> because it sounded to me that you were facing the problem that closing
> the editor while a widget has focus is not triggering a focus-lost
> event, but rather just going into the sequence that calls
> isSaveAsCloseNeeded().
> After re-reading your original question and the follow-up, I have no
> idea the exact scenario you are trying to handle.
My problem is that even if I manage to let the editor part know that its
dirty and might need saving, choosing "no" on the dialog doesn't call
anything on my editor class. However as the current implementation is I'd
need to have that, because I need to re-set the model to the original
state, as the model is changed with every change in my editor.
Andreas
|
|
|
| Re: Best Practice for FormEditor's dirtyState/saving [message #334085 is a reply to message #334009] |
Mon, 19 January 2009 16:31 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 1/15/2009 11:37 AM, Andreas Pakulat wrote:
> My problem is that even if I manage to let the editor part know that its
> dirty and might need saving, choosing "no" on the dialog doesn't call
> anything on my editor class. However as the current implementation is I'd
> need to have that, because I need to re-set the model to the original
> state, as the model is changed with every change in my editor.
So you have a in-memory model that is somehow shared or otherwise needs
to be revertable, correct?
I'd say in that case, you're going to need some kind of buffer in
between the "authoritative" model and the version that the editor is
working. (normally, memory is the buffer between persistence (ie, file
system) and the editor).
I don't think there is a simple solution to that problem, but JFace Data
Binding could probably help. Have you looked into it yet?
Eric
|
|
|
Goto Forum:
Current Time: Thu Oct 30 22:56:30 EDT 2025
Powered by FUDForum. Page generated in 0.04419 seconds |
Home