Community
Participate
Working Groups
CQ:WIND00231527 Build id: JEE-Helios (20100617-1415) When changing a single field in the design tab of the XML Editor, the editor isn't marked dirty. This is a usability problem, since users who only need to change a single field very easily forget to save, so loss of data may incur. Expected behavior: Mark editor dirty as soon as I start typing anything into any field. Workaround: Click or tab outside the modified field to have the field validated and the editor marked dirty. Steps to Reproduce: 1. File > New > Example... : Editing and Validating XML Files 2. Dbl click GolfCountryClub.xml 3. Switch XML editor to design tab 4. Expand tns... > Golf Course 5. Click into "Par" Field and change its value --> The editor isn't marked dirty and cannot be saved.
Problem was also observed in Galileo version.
Hi Martin, The content of the XML doesn't actually change until either you press Enter or change focus away from the cell itself (tab, change pages from design to source, etc). Since the content hasn't actually changed, the file won't be marked as dirty. I think this is fairly typical behavior for the cell editor to not modify content until verified through the return key. So I feel this works as designed. Hopefully I've understood your defect correctly.
Hi Nick, while your explanation is perfectly valid technically - this doesn't help our users. This issue has been reported multiple times, independently, so I do claim that this is a usability issue. Consider a text editor (not cell editor): As soon as you type a single char, the editor is dirty. Our users don't care how this editor has been implemented, and whether XML in its internal model has changed or not - they have typed something, so they expect the content to be changed (and saved when they close the editor).
I completely understand, Martin. We'll investigate for Indigo. Thanks for bringing this to our attention.
(In reply to comment #4) > I completely understand, Martin. We'll investigate for Indigo. Thanks for > bringing this to our attention. Nick, any progress on this one, how did the Indigo release affect this bug, is there any plan to fix this soon? TIA, Ciao, hh
Created attachment 199864 [details] patch Hi Helmut, Unfortunately, nothing was done during Indigo to thwart this problem. But, I've committed changes for the first service release. I'd rather focus on the problem of the cell value not being applied when closing the editor instead of the immediate application of typed characters to the model (outside of the form editors, I haven't seen this kind of functionality).
Code checked in.
(In reply to comment #6) > (outside of the form editors, I haven't seen this kind of functionality). Not sure what you mean with this, but any editor I know gets marked dirty as soon as you start typing, also form editors. Thus, this solution is not satisfying. The user expects to see that an editor is dirty, when its dirty. It seems I cannot reopen this defect. Please do so, whoever can.
I agree with Walter that the patch only addresses the most severe risk of data loss, but it doesn't address the usability issue outlined in the Summary and comment 0. When the user sees that an editor is dirty, he can choose to save at an appropriate time (which my be well before closing the editor... eg in order to dump XML to disk for some build process). Not seeing the editor dirty keeps it in a state the user may not understand. I'm not sure how this is related to "application of typed characters to the model" as per comment 6.
Created attachment 200307 [details] listener patch I'm sorry for the confusion. I've updated the cell modifier so that we now have a cell listener that updates the model upon the cell editor's value changing. I had some apprehension about this change due to the API stating that a listener should not update the model based on value change notifications. But I can see that we will probably be better of in this scenario. Thank you for your patience.
Created attachment 200308 [details] correct patch Added the wrong patch last time.
Most recent changes checked in. Typing in a cell will be immediately reflected in the model, causing the file to be flagged as dirty.
The fix introduces a new problem: If you start to edit, then immediately switch over to the source tab to revert the file, and then edit the same node again, the content of the node disappears. This was not the case before. Thus, the fix needs to be reworked.
(In reply to comment #13) > The fix introduces a new problem: > > If you start to edit, then immediately switch over to the source tab to revert > the file, and then edit the same node again, the content of the node > disappears. This was not the case before. > > Thus, the fix needs to be reworked. Hi, Walter. I tried reproducing this several times with Nitin today and we couldn't reproduce this. If you've recently brought in these changes to your workspace, have you restarted your target? If you have, we might need some more info on how to reproduce the problem.
Sorry, I was not clear about this one: 1. Start editing an existing attribute in the design tab. Editor goes dirty immediately (correct). 2. Switch to the source tab and revert the file. Dirty indication vanishes again (correct). 3. Go back to the design tab and start editing the same attribute. As soon as you click into the edit field, the whole value of the attribute is gone.
(In reply to comment #15) > Sorry, I was not clear about this one: > > 1. Start editing an existing attribute in the design tab. Editor goes dirty > immediately (correct). > 2. Switch to the source tab and revert the file. Dirty indication vanishes > again (correct). > 3. Go back to the design tab and start editing the same attribute. As soon as > you click into the edit field, the whole value of the attribute is gone. Following your revised steps, I am still unable to reproduce the problem. Were there any errors logged or any other outstanding things that you noticed that might help in reproducing this? Thanks!
Nevermind. It might well be, that my test environment is invalid, i.e. I only updated the affected plugin without synchronizing the whole WTP project.