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

[Greg Watson <g.watson@xxxxxxxxxxxx>]

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