Home » Modeling » EMF » Distinguish between Default and Set value of EENum?
|
| Re: Distinguish between Default and Set value of EENum? [message #429681 is a reply to message #429678] |
Wed, 29 April 2009 10:02   |
 Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Morten,
Comments below.
Morten MacFly wrote:
> Dear all,
>
> as you know EEnum's usually have a default value (e.g. the first entry)
> which is set when "running" the model and creating such an EEnum
> attribute.
Yes, enums are treated like primitive types in that they have an
intrinsic default value, the first enumerator, much like int has the
intrinsic default 0.
> While this is OK I have a very special case where I would
> like to know if the default value was set during the initialisation or a
> specific value was set by the user (which might also be the default one).
>
You'll want an unsettable feature.
> I tried to use the specific generated isSet[...] method but it always
> returns true.
If you make it unsettable it should be false until you set it.
> This is due to the fact that when the default value gets
> applied the generated code sets the attribute's "isSet" value to true.
>
When any value is explicitly set, yes, isSet becomes true.
> Without modifiying the generated code (or the generator) is there a easy
> way to distinguish between the default (initialisation) value and the
> case where a user has manually set a enumeration value?
>
I'm not sure how you reached the conclusion you did...
> With best regards, Morten.
>
> Ps.: For the reference, this is the (generatd) method in question:
>
> public void setType(TYPETYPE newType) {
> TYPETYPE oldType = type;
> type = newType == null ? TYPE_EDEFAULT : newType;
> boolean oldTypeESet = typeESet;
> typeESet = true; // HERE IS THE "PROBLEM"
>
No matter what value the user sets it to, it will be set afterwards. To
have typeESet be false again, you'd have to call unsetType.
> if (eNotificationRequired())
> eNotify(new ENotificationImpl(this, Notification.SET,
> ThePackage.TYPE__TYPE, oldType, type, !oldTypeESet));
> }
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Distinguish between Default and Set value of EENum? [message #429710 is a reply to message #429681] |
Thu, 30 April 2009 09:24 |
Morten MacFly
Messages: 69
Registered: July 2009 |
Member |
|
|
Dear Ed,
thanks a lot for the explanations. Comments below...
> You'll want an unsettable feature.
In fact all my EENums *are* unsettable (the code is generated
appropriately). Buth as soon as I create the Element (thus initially
create the EEnum attribute) the setter method get's called which sets
the EEnum to "isSet". This happens e.g. if I create the node with the
EEnum in the generated editor. I debugged into the code to verify
accordingly.
Do I need to call the unset method "by hand" after initialisation?
With best regards, Morten.
Ed Merks wrote:
> Morten,
>
> Comments below.
>
> Morten MacFly wrote:
>> Dear all,
>>
>> as you know EEnum's usually have a default value (e.g. the first entry)
>> which is set when "running" the model and creating such an EEnum
>> attribute.
> Yes, enums are treated like primitive types in that they have an
> intrinsic default value, the first enumerator, much like int has the
> intrinsic default 0.
>> While this is OK I have a very special case where I would
>> like to know if the default value was set during the initialisation or a
>> specific value was set by the user (which might also be the default one).
>>
> You'll want an unsettable feature.
>> I tried to use the specific generated isSet[...] method but it always
>> returns true.
> If you make it unsettable it should be false until you set it.
>> This is due to the fact that when the default value gets
>> applied the generated code sets the attribute's "isSet" value to true.
>>
> When any value is explicitly set, yes, isSet becomes true.
>> Without modifiying the generated code (or the generator) is there a easy
>> way to distinguish between the default (initialisation) value and the
>> case where a user has manually set a enumeration value?
>>
> I'm not sure how you reached the conclusion you did...
>> With best regards, Morten.
>>
>> Ps.: For the reference, this is the (generatd) method in question:
>>
>> public void setType(TYPETYPE newType) {
>> TYPETYPE oldType = type;
>> type = newType == null ? TYPE_EDEFAULT : newType;
>> boolean oldTypeESet = typeESet;
>> typeESet = true; // HERE IS THE "PROBLEM"
>>
> No matter what value the user sets it to, it will be set afterwards. To
> have typeESet be false again, you'd have to call unsetType.
>> if (eNotificationRequired())
>> eNotify(new ENotificationImpl(this, Notification.SET,
>> ThePackage.TYPE__TYPE, oldType, type, !oldTypeESet));
>> }
>>
|
|
|
| Re: Distinguish between Default and Set value of EENum? [message #429713 is a reply to message #429710] |
Thu, 30 April 2009 10:51 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000904020603030403030905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Morten,
Comments below.
Morten MacFly wrote:
> Dear Ed,
>
> thanks a lot for the explanations. Comments below...
>
>
>> You'll want an unsettable feature.
>>
> In fact all my EENums *are* unsettable (the code is generated
> appropriately).
I know because you showed the code.
> Buth as soon as I create the Element (thus initially
> create the EEnum attribute) the setter method get's called which sets
> the EEnum to "isSet".
Who calls the setter? That must be you.
> This happens e.g. if I create the node with the
> EEnum in the generated editor. I debugged into the code to verify
> accordingly.
>
Again, by whom?
> Do I need to call the unset method "by hand" after initialisation?
>
No, you need to determine who is calling the setter and why. I don't
think the framework is doing that, unless of course if it's because
you're deserializing an instance with the value set in the
serialization, in which case you ought to expect that result.
> With best regards, Morten.
>
> Ed Merks wrote:
>
>> Morten,
>>
>> Comments below.
>>
>> Morten MacFly wrote:
>>
>>> Dear all,
>>>
>>> as you know EEnum's usually have a default value (e.g. the first entry)
>>> which is set when "running" the model and creating such an EEnum
>>> attribute.
>>>
>> Yes, enums are treated like primitive types in that they have an
>> intrinsic default value, the first enumerator, much like int has the
>> intrinsic default 0.
>>
>>> While this is OK I have a very special case where I would
>>> like to know if the default value was set during the initialisation or a
>>> specific value was set by the user (which might also be the default one).
>>>
>>>
>> You'll want an unsettable feature.
>>
>>> I tried to use the specific generated isSet[...] method but it always
>>> returns true.
>>>
>> If you make it unsettable it should be false until you set it.
>>
>>> This is due to the fact that when the default value gets
>>> applied the generated code sets the attribute's "isSet" value to true.
>>>
>>>
>> When any value is explicitly set, yes, isSet becomes true.
>>
>>> Without modifiying the generated code (or the generator) is there a easy
>>> way to distinguish between the default (initialisation) value and the
>>> case where a user has manually set a enumeration value?
>>>
>>>
>> I'm not sure how you reached the conclusion you did...
>>
>>> With best regards, Morten.
>>>
>>> Ps.: For the reference, this is the (generatd) method in question:
>>>
>>> public void setType(TYPETYPE newType) {
>>> TYPETYPE oldType = type;
>>> type = newType == null ? TYPE_EDEFAULT : newType;
>>> boolean oldTypeESet = typeESet;
>>> typeESet = true; // HERE IS THE "PROBLEM"
>>>
>>>
>> No matter what value the user sets it to, it will be set afterwards. To
>> have typeESet be false again, you'd have to call unsetType.
>>
>>> if (eNotificationRequired())
>>> eNotify(new ENotificationImpl(this, Notification.SET,
>>> ThePackage.TYPE__TYPE, oldType, type, !oldTypeESet));
>>> }
>>>
>>>
--------------000904020603030403030905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Morten,<br>
<br>
Comments below.<br>
<br>
Morten MacFly wrote:
<blockquote cite="mid:gtbqra$akd$1@build.eclipse.org" type="cite">
<pre wrap="">Dear Ed,
thanks a lot for the explanations. Comments below...
</pre>
<blockquote type="cite">
<pre wrap="">You'll want an unsettable feature.
</pre>
</blockquote>
<pre wrap=""><!---->In fact all my EENums *are* unsettable (the code is generated
appropriately).</pre>
</blockquote>
I know because you showed the code.<br>
<blockquote cite="mid:gtbqra$akd$1@build.eclipse.org" type="cite">
<pre wrap=""> Buth as soon as I create the Element (thus initially
create the EEnum attribute) the setter method get's called which sets
the EEnum to "isSet".</pre>
</blockquote>
Who calls the setter? That must be you.<br>
<blockquote cite="mid:gtbqra$akd$1@build.eclipse.org" type="cite">
<pre wrap=""> This happens e.g. if I create the node with the
EEnum in the generated editor. I debugged into the code to verify
accordingly.
</pre>
</blockquote>
Again, by whom? <br>
<blockquote cite="mid:gtbqra$akd$1@build.eclipse.org" type="cite">
<pre wrap="">
Do I need to call the unset method "by hand" after initialisation?
</pre>
</blockquote>
No, you need to determine who is calling the setter and why. I don't
think the framework is doing that, unless of course if it's because
you're deserializing an instance with the value set in the
serialization, in which case you ought to expect that result.<br>
<blockquote cite="mid:gtbqra$akd$1@build.eclipse.org" type="cite">
<pre wrap="">
With best regards, Morten.
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Morten,
Comments below.
Morten MacFly wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dear all,
as you know EEnum's usually have a default value (e.g. the first entry)
which is set when "running" the model and creating such an EEnum
attribute.
</pre>
</blockquote>
<pre wrap="">Yes, enums are treated like primitive types in that they have an
intrinsic default value, the first enumerator, much like int has the
intrinsic default 0.
</pre>
<blockquote type="cite">
<pre wrap="">While this is OK I have a very special case where I would
like to know if the default value was set during the initialisation or a
specific value was set by the user (which might also be the default one).
</pre>
</blockquote>
<pre wrap="">You'll want an unsettable feature.
</pre>
<blockquote type="cite">
<pre wrap="">I tried to use the specific generated isSet[...] method but it always
returns true.
</pre>
</blockquote>
<pre wrap="">If you make it unsettable it should be false until you set it.
</pre>
<blockquote type="cite">
<pre wrap=""> This is due to the fact that when the default value gets
applied the generated code sets the attribute's "isSet" value to true.
</pre>
</blockquote>
<pre wrap="">When any value is explicitly set, yes, isSet becomes true.
</pre>
<blockquote type="cite">
<pre wrap="">Without modifiying the generated code (or the generator) is there a easy
way to distinguish between the default (initialisation) value and the
case where a user has manually set a enumeration value?
</pre>
</blockquote>
<pre wrap="">I'm not sure how you reached the conclusion you did...
</pre>
<blockquote type="cite">
<pre wrap="">With best regards, Morten.
Ps.: For the reference, this is the (generatd) method in question:
public void setType(TYPETYPE newType) {
TYPETYPE oldType = type;
type = newType == null ? TYPE_EDEFAULT : newType;
boolean oldTypeESet = typeESet;
typeESet = true; // HERE IS THE "PROBLEM"
</pre>
</blockquote>
<pre wrap="">No matter what value the user sets it to, it will be set afterwards. To
have typeESet be false again, you'd have to call unsetType.
</pre>
<blockquote type="cite">
<pre wrap=""> if (eNotificationRequired())
eNotify(new ENotificationImpl(this, Notification.SET,
ThePackage.TYPE__TYPE, oldType, type, !oldTypeESet));
}
</pre>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------000904020603030403030905--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Distinguish between Default and Set value of EENum? [message #429863 is a reply to message #429713] |
Tue, 05 May 2009 15:37 |
Morten MacFly
Messages: 69
Registered: July 2009 |
Member |
|
|
Dear Ed,
thanks again for the answers. I'm afraid you are right - hence I don't
see who'se the "Setter" in my application. See comments below...
> Who calls the setter? That must be you.
I tried the following: I reduced the model to just one EEnum and created
a new EMF project out of it. After the code generation the generated
sample editor worked as expected! So it's not the way I model. Hence I
just don't know how to tell who's the "Setter". All I do is creating
another instance of the model - so no serialisation/de-serialisation at
that point, really. I set a breakpoint in the "Setter" method, but I
don't see who the caller is. I can't reach the relevant level (i.e. see
code) in the stack trace... I'll continue to investigate though... If
you have any hints how to tell the caller in the debugger easily let me
know. If not don't worry about it anymore - EMF works just fine it must
be my fault... :-(
With regards, Morten.
Ed Merks wrote:
> Morten,
>
> Comments below.
>
> Morten MacFly wrote:
>> Dear Ed,
>>
>> thanks a lot for the explanations. Comments below...
>>
>>
>>> You'll want an unsettable feature.
>>>
>> In fact all my EENums *are* unsettable (the code is generated
>> appropriately).
> I know because you showed the code.
>> Buth as soon as I create the Element (thus initially
>> create the EEnum attribute) the setter method get's called which sets
>> the EEnum to "isSet".
> Who calls the setter? That must be you.
>> This happens e.g. if I create the node with the
>> EEnum in the generated editor. I debugged into the code to verify
>> accordingly.
>>
> Again, by whom?
>> Do I need to call the unset method "by hand" after initialisation?
>>
> No, you need to determine who is calling the setter and why. I don't
> think the framework is doing that, unless of course if it's because
> you're deserializing an instance with the value set in the
> serialization, in which case you ought to expect that result.
>> With best regards, Morten.
>>
>> Ed Merks wrote:
>>
>>> Morten,
>>>
>>> Comments below.
>>>
>>> Morten MacFly wrote:
>>>
>>>> Dear all,
>>>>
>>>> as you know EEnum's usually have a default value (e.g. the first entry)
>>>> which is set when "running" the model and creating such an EEnum
>>>> attribute.
>>>>
>>> Yes, enums are treated like primitive types in that they have an
>>> intrinsic default value, the first enumerator, much like int has the
>>> intrinsic default 0.
>>>
>>>> While this is OK I have a very special case where I would
>>>> like to know if the default value was set during the initialisation or a
>>>> specific value was set by the user (which might also be the default one).
>>>>
>>>>
>>> You'll want an unsettable feature.
>>>
>>>> I tried to use the specific generated isSet[...] method but it always
>>>> returns true.
>>>>
>>> If you make it unsettable it should be false until you set it.
>>>
>>>> This is due to the fact that when the default value gets
>>>> applied the generated code sets the attribute's "isSet" value to true.
>>>>
>>>>
>>> When any value is explicitly set, yes, isSet becomes true.
>>>
>>>> Without modifiying the generated code (or the generator) is there a easy
>>>> way to distinguish between the default (initialisation) value and the
>>>> case where a user has manually set a enumeration value?
>>>>
>>>>
>>> I'm not sure how you reached the conclusion you did...
>>>
>>>> With best regards, Morten.
>>>>
>>>> Ps.: For the reference, this is the (generatd) method in question:
>>>>
>>>> public void setType(TYPETYPE newType) {
>>>> TYPETYPE oldType = type;
>>>> type = newType == null ? TYPE_EDEFAULT : newType;
>>>> boolean oldTypeESet = typeESet;
>>>> typeESet = true; // HERE IS THE "PROBLEM"
>>>>
>>>>
>>> No matter what value the user sets it to, it will be set afterwards. To
>>> have typeESet be false again, you'd have to call unsetType.
>>>
>>>> if (eNotificationRequired())
>>>> eNotify(new ENotificationImpl(this, Notification.SET,
>>>> ThePackage.TYPE__TYPE, oldType, type, !oldTypeESet));
>>>> }
>>>>
>>>>
|
|
|
| Re: Distinguish between Default and Set value of EENum? [message #429864 is a reply to message #429863] |
Tue, 05 May 2009 15:52 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Morten MacFly wrote:
> Dear Ed,
>
> thanks again for the answers. I'm afraid you are right - hence I don't
> see who'se the "Setter" in my application. See comments below...
>
>> Who calls the setter? That must be you.
> I tried the following: I reduced the model to just one EEnum and created
> a new EMF project out of it. After the code generation the generated
> sample editor worked as expected! So it's not the way I model. Hence I
> just don't know how to tell who's the "Setter". All I do is creating
> another instance of the model - so no serialisation/de-serialisation at
> that point, really. I set a breakpoint in the "Setter" method, but I
> don't see who the caller is. I can't reach the relevant level (i.e. see
> code) in the stack trace...
What do you mean when you say you can't see who the caller is? Are you
looking at the Debug view, which shows each level of the stack? You can
click a stack level to see the code at that level and you should be able
to go as far down the stack as necessary to understand the calling sequence.
Eric
> Ed Merks wrote:
>> Morten,
>>
>> Comments below.
>>
>> Morten MacFly wrote:
>>> Dear Ed,
>>>
>>> thanks a lot for the explanations. Comments below...
>>>
>>>
>>>> You'll want an unsettable feature.
>>>>
>>> In fact all my EENums *are* unsettable (the code is generated
>>> appropriately).
>> I know because you showed the code.
>>> Buth as soon as I create the Element (thus initially
>>> create the EEnum attribute) the setter method get's called which sets
>>> the EEnum to "isSet".
>> Who calls the setter? That must be you.
>>> This happens e.g. if I create the node with the
>>> EEnum in the generated editor. I debugged into the code to verify
>>> accordingly.
>>>
>> Again, by whom?
>>> Do I need to call the unset method "by hand" after initialisation?
>>>
>> No, you need to determine who is calling the setter and why. I don't
>> think the framework is doing that, unless of course if it's because
>> you're deserializing an instance with the value set in the
>> serialization, in which case you ought to expect that result.
>>> With best regards, Morten.
>>>
>>> Ed Merks wrote:
>>>
>>>> Morten,
>>>>
>>>> Comments below.
>>>>
>>>> Morten MacFly wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> as you know EEnum's usually have a default value (e.g. the first entry)
>>>>> which is set when "running" the model and creating such an EEnum
>>>>> attribute.
>>>>>
>>>> Yes, enums are treated like primitive types in that they have an
>>>> intrinsic default value, the first enumerator, much like int has the
>>>> intrinsic default 0.
>>>>
>>>>> While this is OK I have a very special case where I would
>>>>> like to know if the default value was set during the initialisation or a
>>>>> specific value was set by the user (which might also be the default one).
>>>>>
>>>>>
>>>> You'll want an unsettable feature.
>>>>
>>>>> I tried to use the specific generated isSet[...] method but it always
>>>>> returns true.
>>>>>
>>>> If you make it unsettable it should be false until you set it.
>>>>
>>>>> This is due to the fact that when the default value gets
>>>>> applied the generated code sets the attribute's "isSet" value to true.
>>>>>
>>>>>
>>>> When any value is explicitly set, yes, isSet becomes true.
>>>>
>>>>> Without modifiying the generated code (or the generator) is there a easy
>>>>> way to distinguish between the default (initialisation) value and the
>>>>> case where a user has manually set a enumeration value?
>>>>>
>>>>>
>>>> I'm not sure how you reached the conclusion you did...
>>>>
>>>>> With best regards, Morten.
>>>>>
>>>>> Ps.: For the reference, this is the (generatd) method in question:
>>>>>
>>>>> public void setType(TYPETYPE newType) {
>>>>> TYPETYPE oldType = type;
>>>>> type = newType == null ? TYPE_EDEFAULT : newType;
>>>>> boolean oldTypeESet = typeESet;
>>>>> typeESet = true; // HERE IS THE "PROBLEM"
>>>>>
>>>>>
>>>> No matter what value the user sets it to, it will be set afterwards. To
>>>> have typeESet be false again, you'd have to call unsetType.
>>>>
>>>>> if (eNotificationRequired())
>>>>> eNotify(new ENotificationImpl(this, Notification.SET,
>>>>> ThePackage.TYPE__TYPE, oldType, type, !oldTypeESet));
>>>>> }
>>>>>
>>>>>
|
|
|
| Re: Distinguish between Default and Set value of EENum? [message #429865 is a reply to message #429863] |
Tue, 05 May 2009 15:54 |
Morten MacFly
Messages: 69
Registered: July 2009 |
Member |
|
|
....just one more thing:
It seems this is rerlated to the (generated) wizard. After the wizard
finsihes it indeed seems to load the resource through XML. I see a lot
of XMLHelper, SAXXMLHandler etc. classes there.
They are being called when The editor calls "createPages()" which calls
"createModel()" which does:
resource = editingDomain.getResourceSet().getResource(resourceURI, true);
In the ResourceImplementation a "load" is performed on an input stream
which "comes" from the wizard. Then a XML stream is parsed and so on...
No I wonder: I have created the wizard using the sample provided with
eclipse. this calls:
page.openEditor(new FileEditorInput(modelFile),
workbench.getEditorRegistry().getDefaultEditor(modelFile.get FullPath().toString()).getId());
in "performFinish()". Am I doing this wrong? Should I *not* open the
editor here? But it seems to be done exactly the same way in the wizard
that is being generated?!
I am sure I am missing something... this drives me mad... :-(
With regards, Morten.
Morten MacFly wrote:
> Dear Ed,
>
> thanks again for the answers. I'm afraid you are right - hence I don't
> see who'se the "Setter" in my application. See comments below...
>
>> Who calls the setter? That must be you.
> I tried the following: I reduced the model to just one EEnum and created
> a new EMF project out of it. After the code generation the generated
> sample editor worked as expected! So it's not the way I model. Hence I
> just don't know how to tell who's the "Setter". All I do is creating
> another instance of the model - so no serialisation/de-serialisation at
> that point, really. I set a breakpoint in the "Setter" method, but I
> don't see who the caller is. I can't reach the relevant level (i.e. see
> code) in the stack trace... I'll continue to investigate though... If
> you have any hints how to tell the caller in the debugger easily let me
> know. If not don't worry about it anymore - EMF works just fine it must
> be my fault... :-(
>
> With regards, Morten.
>
> Ed Merks wrote:
>> Morten,
>>
>> Comments below.
>>
>> Morten MacFly wrote:
>>> Dear Ed,
>>>
>>> thanks a lot for the explanations. Comments below...
>>>
>>>
>>>> You'll want an unsettable feature.
>>>>
>>> In fact all my EENums *are* unsettable (the code is generated
>>> appropriately).
>> I know because you showed the code.
>>> Buth as soon as I create the Element (thus initially
>>> create the EEnum attribute) the setter method get's called which sets
>>> the EEnum to "isSet".
>> Who calls the setter? That must be you.
>>> This happens e.g. if I create the node with the
>>> EEnum in the generated editor. I debugged into the code to verify
>>> accordingly.
>>>
>> Again, by whom?
>>> Do I need to call the unset method "by hand" after initialisation?
>>>
>> No, you need to determine who is calling the setter and why. I don't
>> think the framework is doing that, unless of course if it's because
>> you're deserializing an instance with the value set in the
>> serialization, in which case you ought to expect that result.
>>> With best regards, Morten.
>>>
>>> Ed Merks wrote:
>>>
>>>> Morten,
>>>>
>>>> Comments below.
>>>>
>>>> Morten MacFly wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> as you know EEnum's usually have a default value (e.g. the first entry)
>>>>> which is set when "running" the model and creating such an EEnum
>>>>> attribute.
>>>>>
>>>> Yes, enums are treated like primitive types in that they have an
>>>> intrinsic default value, the first enumerator, much like int has the
>>>> intrinsic default 0.
>>>>
>>>>> While this is OK I have a very special case where I would
>>>>> like to know if the default value was set during the initialisation or a
>>>>> specific value was set by the user (which might also be the default one).
>>>>>
>>>>>
>>>> You'll want an unsettable feature.
>>>>
>>>>> I tried to use the specific generated isSet[...] method but it always
>>>>> returns true.
>>>>>
>>>> If you make it unsettable it should be false until you set it.
>>>>
>>>>> This is due to the fact that when the default value gets
>>>>> applied the generated code sets the attribute's "isSet" value to true.
>>>>>
>>>>>
>>>> When any value is explicitly set, yes, isSet becomes true.
>>>>
>>>>> Without modifiying the generated code (or the generator) is there a easy
>>>>> way to distinguish between the default (initialisation) value and the
>>>>> case where a user has manually set a enumeration value?
>>>>>
>>>>>
>>>> I'm not sure how you reached the conclusion you did...
>>>>
>>>>> With best regards, Morten.
>>>>>
>>>>> Ps.: For the reference, this is the (generatd) method in question:
>>>>>
>>>>> public void setType(TYPETYPE newType) {
>>>>> TYPETYPE oldType = type;
>>>>> type = newType == null ? TYPE_EDEFAULT : newType;
>>>>> boolean oldTypeESet = typeESet;
>>>>> typeESet = true; // HERE IS THE "PROBLEM"
>>>>>
>>>>>
>>>> No matter what value the user sets it to, it will be set afterwards. To
>>>> have typeESet be false again, you'd have to call unsetType.
>>>>
>>>>> if (eNotificationRequired())
>>>>> eNotify(new ENotificationImpl(this, Notification.SET,
>>>>> ThePackage.TYPE__TYPE, oldType, type, !oldTypeESet));
>>>>> }
>>>>>
>>>>>
|
|
| |
| Re: Distinguish between Default and Set value of EENum? [message #429869 is a reply to message #429865] |
Tue, 05 May 2009 17:36 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Morten,
Comments below.
Morten MacFly wrote:
> ...just one more thing:
> It seems this is rerlated to the (generated) wizard. After the wizard
> finsihes it indeed seems to load the resource through XML. I see a lot
> of XMLHelper, SAXXMLHandler etc. classes there.
>
Well yes, the wizard create a resource serializes it to the workspace
and then opens the editor on that serialized resource, which then
deserialize it...
> They are being called when The editor calls "createPages()" which calls
> "createModel()" which does:
> resource = editingDomain.getResourceSet().getResource(resourceURI, true);
> In the ResourceImplementation a "load" is performed on an input stream
> which "comes" from the wizard. Then a XML stream is parsed and so on...
>
Indeed.
> No I wonder: I have created the wizard using the sample provided with
> eclipse. this calls:
> page.openEditor(new FileEditorInput(modelFile),
> workbench.getEditorRegistry().getDefaultEditor(modelFile.get FullPath().toString()).getId());
> in "performFinish()". Am I doing this wrong?
Nothing. That's what's supposed to happen.
> Should I *not* open the
> editor here? But it seems to be done exactly the same way in the wizard
> that is being generated?!
>
What's wrong?
> I am sure I am missing something... this drives me mad... :-(
>
Sure, share the madness! :-P
> With regards, Morten.
>
> Morten MacFly wrote:
>
>> Dear Ed,
>>
>> thanks again for the answers. I'm afraid you are right - hence I don't
>> see who'se the "Setter" in my application. See comments below...
>>
>>
>>> Who calls the setter? That must be you.
>>>
>> I tried the following: I reduced the model to just one EEnum and created
>> a new EMF project out of it. After the code generation the generated
>> sample editor worked as expected! So it's not the way I model. Hence I
>> just don't know how to tell who's the "Setter". All I do is creating
>> another instance of the model - so no serialisation/de-serialisation at
>> that point, really. I set a breakpoint in the "Setter" method, but I
>> don't see who the caller is. I can't reach the relevant level (i.e. see
>> code) in the stack trace... I'll continue to investigate though... If
>> you have any hints how to tell the caller in the debugger easily let me
>> know. If not don't worry about it anymore - EMF works just fine it must
>> be my fault... :-(
>>
>> With regards, Morten.
>>
>> Ed Merks wrote:
>>
>>> Morten,
>>>
>>> Comments below.
>>>
>>> Morten MacFly wrote:
>>>
>>>> Dear Ed,
>>>>
>>>> thanks a lot for the explanations. Comments below...
>>>>
>>>>
>>>>
>>>>> You'll want an unsettable feature.
>>>>>
>>>>>
>>>> In fact all my EENums *are* unsettable (the code is generated
>>>> appropriately).
>>>>
>>> I know because you showed the code.
>>>
>>>> Buth as soon as I create the Element (thus initially
>>>> create the EEnum attribute) the setter method get's called which sets
>>>> the EEnum to "isSet".
>>>>
>>> Who calls the setter? That must be you.
>>>
>>>> This happens e.g. if I create the node with the
>>>> EEnum in the generated editor. I debugged into the code to verify
>>>> accordingly.
>>>>
>>>>
>>> Again, by whom?
>>>
>>>> Do I need to call the unset method "by hand" after initialisation?
>>>>
>>>>
>>> No, you need to determine who is calling the setter and why. I don't
>>> think the framework is doing that, unless of course if it's because
>>> you're deserializing an instance with the value set in the
>>> serialization, in which case you ought to expect that result.
>>>
>>>> With best regards, Morten.
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>
>>>>> Morten,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Morten MacFly wrote:
>>>>>
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> as you know EEnum's usually have a default value (e.g. the first entry)
>>>>>> which is set when "running" the model and creating such an EEnum
>>>>>> attribute.
>>>>>>
>>>>>>
>>>>> Yes, enums are treated like primitive types in that they have an
>>>>> intrinsic default value, the first enumerator, much like int has the
>>>>> intrinsic default 0.
>>>>>
>>>>>
>>>>>> While this is OK I have a very special case where I would
>>>>>> like to know if the default value was set during the initialisation or a
>>>>>> specific value was set by the user (which might also be the default one).
>>>>>>
>>>>>>
>>>>>>
>>>>> You'll want an unsettable feature.
>>>>>
>>>>>
>>>>>> I tried to use the specific generated isSet[...] method but it always
>>>>>> returns true.
>>>>>>
>>>>>>
>>>>> If you make it unsettable it should be false until you set it.
>>>>>
>>>>>
>>>>>> This is due to the fact that when the default value gets
>>>>>> applied the generated code sets the attribute's "isSet" value to true.
>>>>>>
>>>>>>
>>>>>>
>>>>> When any value is explicitly set, yes, isSet becomes true.
>>>>>
>>>>>
>>>>>> Without modifiying the generated code (or the generator) is there a easy
>>>>>> way to distinguish between the default (initialisation) value and the
>>>>>> case where a user has manually set a enumeration value?
>>>>>>
>>>>>>
>>>>>>
>>>>> I'm not sure how you reached the conclusion you did...
>>>>>
>>>>>
>>>>>> With best regards, Morten.
>>>>>>
>>>>>> Ps.: For the reference, this is the (generatd) method in question:
>>>>>>
>>>>>> public void setType(TYPETYPE newType) {
>>>>>> TYPETYPE oldType = type;
>>>>>> type = newType == null ? TYPE_EDEFAULT : newType;
>>>>>> boolean oldTypeESet = typeESet;
>>>>>> typeESet = true; // HERE IS THE "PROBLEM"
>>>>>>
>>>>>>
>>>>>>
>>>>> No matter what value the user sets it to, it will be set afterwards. To
>>>>> have typeESet be false again, you'd have to call unsetType.
>>>>>
>>>>>
>>>>>> if (eNotificationRequired())
>>>>>> eNotify(new ENotificationImpl(this, Notification.SET,
>>>>>> ThePackage.TYPE__TYPE, oldType, type, !oldTypeESet));
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 16:55:57 GMT 2024
Powered by FUDForum. Page generated in 0.03324 seconds |
] 
Search
Help
Register
Login
Home
