Community
Participate
Working Groups
Build id: 20130320-2352 Steps to reproduce: - Create a UML model - Add a class to the UML model, and add a property to that class - Try to edit the (literal string) default value of the property via the properties view (via the edit button). Type in a value -> The value gets lost. Editing the value via the (embedded textual) advanced property editor works fine.
I cannot reproduce the issue. I haven't noticed any issue related to the default value in the properties view recently. Maybe it occurs in really specific cases? Do you have an exception in your error log?
Created attachment 229329 [details] Screenshot Unfortunately, I don't have access to a MS Windows platform right now, so I cannot test it over there. For the rest, (as stated above) I can consistently reproduce this using a very basic model. See the screenshot in attach I get this window, I type in a value, and press OK. Nothing happens, the editor is not marked as "dirty", and I have no exception in the error log :-( _However_, and I noted this while taking the screenshot. If I wait _very_ long (around a minute, 30 seconds does not appear to be enough) between typing in the value and pressing the OK button, it _does_ work. Hmm, this looks like something ugly :-(
Hmmm it might be a lead. When you edit an element in a Dialog, the edition is done in real-time (i.e. you do not need to press "OK" to validate the changes, and that's why you can't press "cancel"). The value is validated in two cases: - The text widget loses focus - You press enter (for single-line text fields) or Ctrl + Enter (For multi line text fields) It may be that the "Close dialog" event is sent before the "Focus lost" even on some platform. In this case, it is too late to retrieve and validate the value, because then the text widget would have already been disposed (And the focus lost even maybe never occurs) Could you please try the following: - Edit the default value - Click in the "name" text field so that the default value is validated (The editor should become dirty at this point) - Then press OK It this works, then this is probably a mac-specific bug related to the order of events.
(In reply to comment #3) [...] > Could you please try the following: > > - Edit the default value > - Click in the "name" text field so that the default value is validated (The > editor should become dirty at this point) > - Then press OK > > It this works, then this is probably a mac-specific bug related to the order > of events. This works perfectly indeed...
Ok, I'll try to work on a solution then, although I don't have a Mac. This might take some time...
(In reply to comment #5) > Ok, I'll try to work on a solution then, although I don't have a Mac. This > might take some time... Hi Camille, I even noticed something more wierd. For an attribute typed as "Real", even the workaround fails: I cannot set its value to a literalReal at all using the property view. The only way I can set it is via the advanced property xtext editor (but then again, this one is currently not available in SysML models :-(
There is a bug for the Real. We're using a Float editor instead of a Double editor, and the edition fails. It will be fixed for SR1.
(In reply to comment #7) > There is a bug for the Real. We're using a Float editor instead of a Double > editor, and the edition fails. It will be fixed for SR1. Is there a bugzilla entry for that (searching within the papyrus bugs for "float" and "double" doesn't reveal anything it seems???)
(In reply to comment #8) > (In reply to comment #7) > > There is a bug for the Real. We're using a Float editor instead of a Double > > editor, and the edition fails. It will be fixed for SR1. > > Is there a bugzilla entry for that (searching within the papyrus bugs for > "float" and "double" doesn't reveal anything it seems???) Also, is there a link between this bug and <https://bugs.eclipse.org/bugs/show_bug.cgi?id=407908>?
> Is there a bugzilla entry for that (searching within the papyrus bugs for "float" and "double" doesn't reveal anything it seems???) > Also, is there a link between this bug and <https://bugs.eclipse.org/bugs/show_bug.cgi?id=407908>? Yes, Bug 407908 describes the issue for editing Real values in Papyrus (Because of the confusion between Float and Double)
(In reply to Camille Letavernier from comment #5) > Ok, I'll try to work on a solution then, although I don't have a Mac. This > might take some time... Seems to be still present in luna nightly build. Christian, can you also reproduce this?
Indeed, I can confirm that on Mac, the focus-lost event that the StringEditor depends on for committing changes is not invoked when the EditingDialog is closed.
This is, actually, a pervasive problem. I have developed a habit, in using EditionDialogs, of deliberately changing focus to some other control before pressing OK because otherwise the last edit made in the dialog never takes effect. This is a serious problem on Mac platform.
I have pushed a new branch bugs/404874-macfocus with a work-around in the EditionDialog class. This work-around focus the OK button to get focus when clicked, either explicitly or implicitly via press on the Enter/Return key. The expectation is that on non-Mac platforms, the OK button already has focus, so this should be harmless in those contexts. I would be grateful if a Windows user could confirm this. My work-around fixes not only the reported scenario, but also use cases that I have awkwardly worked around in webcast demonstrations by deliberate focus changes.
I can confirm that the workaround doesn't break anything on Windows
Thanks, Camille. I have pushed the fix to origin master.
*** Bug 456479 has been marked as a duplicate of this bug. ***
Hmm, Just as mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=456429#c5, I can also still reproduce the original bug using Papyrus UML 1.0.1.v201412240555 org.eclipse.papyrus.sdk.feature.feature.group Eclipse Modeling Project on OS X Yosemite (so that seems to be pretty much the same as Christian's environment...)
I don't know what to say, except that I still can't reproduce this (nor the problems from bug 456429 and bug 456479) in either the current Luna development branch nor in a new installation of Papyrus 1.0.1.v201412190917 (SR1a). Upgrading to 1.0.1.v201501151626, it is still not reproducible. I need more to go on. Is there anything in the log that is suggestive? (I wouldn't expect to see anything, because the original problem that I had fixed wasn't an exception scenario) Anything else that could be a factor? Or are you reproducing this in a fresh new install of Eclipse (Committers Luna SR1 package) and Papyrus (SR1a or later)? Anyways, I can't fix what I can't reproduce and debug, so somebody needs to provide more information.
I've been able to reproduce the issue today with a Mac user on Luna, so I can confirm the issue is still present somehow. There's not much more I can tell about this, since I couldn't actually debug it
(In reply to Christian W. Damus from comment #19) > I don't know what to say, except that I still can't reproduce this (nor the > problems from bug 456429 and bug 456479) in either the current Luna > development branch nor in a new installation of Papyrus 1.0.1.v201412190917 > (SR1a). Upgrading to 1.0.1.v201501151626, it is still not reproducible. > > I need more to go on. Is there anything in the log that is suggestive? (I > wouldn't expect to see anything, because the original problem that I had > fixed wasn't an exception scenario) Anything else that could be a factor? > Or are you reproducing this in a fresh new install of Eclipse (Committers > Luna SR1 package) and Papyrus (SR1a or later)? > > Anyways, I can't fix what I can't reproduce and debug, so somebody needs to > provide more information. Trying to answer your questions (a bit late :blush:) - Nothing appears in the logs - I can now say that I've been able to reproduce this consistently over all Papyrus versions since 2013, and mac os X versions up to yosemite Steps to reproduce: - Download and run papyrus-neon-2.0.2-macosx64.tar.gz - Startup with a clean and fresh workspace - Create a papyrus project and UML model with primitive types - Continu with the steps described in Comment 0 -> Potentially interesting: the model is marked as being dirty when pressing OK after typing in the value. Yet when saving, the default value remains at the old value. Note: also still valid as a workaround: just switching the focus to the 'name' field before clicking on OK, does result in the correct value being updated. (In the meanwhile, I'm running Sierra)
Returning this to the Papyrus inbox.
Hi Christian, (In reply to Christian W. Damus from comment #22) > Returning this to the Papyrus inbox. Just for my information: because you can't reproduce the problem anymore, or due to a lack of time/interest/priorities, or ...?
(In reply to Klaas Gadeyne from comment #23) > > Just for my information: because you can't reproduce the problem anymore, or > due to a lack of time/interest/priorities, or ...? I should have noticed much sooner that this was still assigned to me and so probably not on the radar of anyone that should be interested in fixing it. My focus for the foreseeable future is in the Papyrus-RT project, on the UML-RT semantics of inheritance in particular.
