Re: [ptp-dev] Problem with creating enumerated attribute definitions?

[Dave Wootton <dwootton@xxxxxxxxxx>]

Greg
I found what I think may be another bug with enumerated attribute 
definitions, although in this case, I might be abusing the concept of an 
enuerated attribute.

I am trying to remove coding of specific values related to attributes 
defined by my proxy from my implementation of 
AbstractRMLaunchConfigurationDynamicTab. I have this working fine for 
default attribute values, and by use of enumerated attribute definitions, 
I have this working for attributes where I have a boolean selection such 
as yes/no. I realized I could build on this and use enumerated attribute 
definitions to specify the set of allowable selections that get added to a 
Combo box, and now have that working, except :-) for one attribute, where 
I have an editable Combo box where the user makes a choice of the single 
enumeration ('max') or types in a number to specify the value. For this 
one case, the enumerated attribute definition value set has only one 
value, which kind of stretches the concept of enumeration. 

The problem is that code near AbstractProxyRuntimeSystem line 832  does 
not accept an event with only a single enumeration value, and line 842 
fires a RuntimeMessageEvent. This goes somewhere, and I end up getting a 
null pointer exception.

I can code around this by including a dummy enumeration value, like '???' 
and having the code which creates the Combo box ignore the '???' when 
adding items to the combo box, but I wanted to get your opinion first.

Dave



Greg Watson <g.watson@xxxxxxxxxxxx> 
Sent by: ptp-dev-bounces@xxxxxxxxxxx
06/20/2007 11:25 AM
Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>


To
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
cc

Subject
Re: [ptp-dev] Problem with creating enumerated attribute definitions?






Agreed. It seems like they're both bugs. Hopefully Randy might be 
able to shed some light on this.

Greg

On Jun 20, 2007, at 8:45 AM, Dave Wootton wrote:

> Greg
> I was more concerned with the problem of not picking up the 2nd
> enumeration value from the enumeration attribute definition event the
> proxy sent to the front end than I was with getting a
> StringSetAttributeDefinition object generated by the front end 
> instead of
> the EnumeratedAttributeDefinition object that I was expecting to 
> get. I
> agree that getting back a StringSetAttributionDefinition object back
> instead or an EnumeratedAttributeDefinition object is likely a bug.
> Dave
>
>
>
> Greg Watson <g.watson@xxxxxxxxxxxx>
> Sent by: ptp-dev-bounces@xxxxxxxxxxx
> 06/19/2007 04:13 PM
> Please respond to
> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
>
>
> To
> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [ptp-dev] Problem with creating enumerated attribute definitions?
>
>
>
>
>
>
> Dave,
>
> You're so polite. It's highly likely to be a bug. If you're sending
> an ENUMERATED attribute type, then that's what you should get, not a
> StringSetAttribute.
>
> The StringSetAttribute is a new one on me. Anyone know what this is
> for? How does it differ from an ArrayAttribute?
>
> Greg
>
>
> On Jun 19, 2007, at 10:42 AM, Dave Wootton wrote:
>
>> I've made a change to my proxy to send enumerated attribute 
>> definition
>> events to the front end. My intent is to use these attribute
>> definitions
>> to set the labels on a pair or radio buttons representing a boolean
>> option. I've created a function in my proxy that sends the event to
>> the
>> front end in what I believe is the correct format <1, <n>, <id>,
>> ENUMERATED, <short_name> <long_name> <default> <attr> <attr> ...>
>> where
>> <n> is the number of following tokens (5 + number of enumerations)
>>
>> I did have a problem where even though I was sending across 2
>> enumerations, the StringSetAttributeDefinition that gets created
>> has only
>> the first enumeration. I found a line of code in
>> AbstractProxyRuntimeSystem line 832 which read 'if (pos < end) {'
>> which
>> was resulting in picking up only the first enumeration. If I
>> changed the
>> '<' to '<=' then I get a StringSetAttributeDefinition with the two
>> enumeration values.
>>
>> This is in the latest PTP code, since I updated my code this morning.
>>
>> Is this a problem with the AbstractProxyRuntimeSystem code, or have
>> I done
>> something wrong in my proxy?
>>
>> Also, when I send across an enumeration attribute definition, is it
>> supposed to result in the creation of a StringSetAttributeDefinition
>> object? I was expecting to see an EnumerationAttributeDefinition
>> object
>> created, but when I got a class cast exception based on that
>> assumtion, I
>> tracked down the code where the StringSetAttributeDefinition was
>> created.
>>
>> Generation of an EnumerationAttributeDefinition or a
>> StringSetAttributeDefinition is fine either way. Leaving the code
>> as-is
>> means I don't have to get the attribute definition and then create
>> a dummy
>> attribute to get the value, but that's not frequently called code
>> so isn't
>> a big deal.
>> Dave
>> _______________________________________________
>> ptp-dev mailing list
>> ptp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>>
>
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>
>
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev