Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] Problem with creating enumerated attribute definitions?
I found some other bugs in this code. Please test and let me know if it's ok now.
I discussed the attribute types with Randy. The reason he added StringSetAttributeDefinition was that an EnumeratedAttributeDefinition maps to an existing (Java) enumerated type. Since there is no existing enumerated type when you create an enumerated attribute definition from the proxy end, its not possible to use this type. A StringSetAttributeDefinition has similar characteristics to an EnumeratedAttributeDefinition, it is just not backed by a real enumerated type.
I'm not sure I like the idea of having some attribute definition types that can't be created from the proxy end, and would like to consider merging these back together. We will lose some functionality from the EnumeratedAttributeDefinition since it won't be a real enumerated type any more, but I'm not sure this will be a big problem. Do you have any thoughts one way or the other? 

Greg

On Jun 20, 2007, at 2:06 PM, Dave Wootton wrote:


Greg
Yes, that is what I am doing.
Dave



Greg Watson <g.watson@xxxxxxxxxxxx>
Sent by: ptp-dev-bounces@xxxxxxxxxxx
06/20/2007 02:24 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?






Just to clarify, you are creating an enumerated attribute definition
(using an ATTR_DEF event) that has only one value, and that is
causing a NPE?

I think that should be allowed, so it sounds like a bug. In fact, I
think you should be able to have an enumerated attribute definition
with no values (not sure what use it would be, but it should be
allowed at least).

I'll check out the code you mentioned...

Greg

On Jun 20, 2007, at 11:39 AM, Dave Wootton wrote:


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


_______________________________________________
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

Back to the top