perhaps someone could answer this question before I am so bold as to claim a bug find ...
given this code
METHOD PUBLIC ValueObject.ClientGroup GetUsingClientGroup( p_ClientGroup AS CHARACTER):
DEF VAR a AS ValueObject.ClientGroup.
DEF BUFFER ClientGroup FOR ClientGroup.
FIND FIRST ClientGroup WHERE ClientGroup.cClientGroup EQ p_ClientGroup NO-LOCK NO-ERROR.
IF NOT AVAIL ClientGroup THEN
DO:
a = NEW ValueObject.ClientGroup().
MESSAGE "#1" valid-object(a) a:ToString() VIEW-AS ALERT-BOX.
RETURN a.
END.
RETURN Get(ClientGroup.ClientGroupGUID).
END METHOD.
how is it possible for this message to be displayed
#1 no ValueObject.ClientGroup_1327
Sounds like a bug to me ...
- Does using r-code/not make a difference? (I've seen similar nasties where it does).
- Does the name of the variable make a difference? (I realise 'a' is just a placeholder, but maybe there's some faulty disambiguation going on?)
-- peter
yeah, if the r-code is removed, all is well.
However, it is the VALID-OBJECT call that fails - if I modify one of the properties and return the "invalid" object, this property is available and the same at the top end, although every call to VALID-OBJECT() on this object fails
Sorry, I meant to also reply that the original code simply said
RETURN NEW ValueObject.ClientGroup()
so the variable was just put in there to check for a VALID-OBJECT(). and it isn't. but it is .. :)
And just to narrow down the source of the bug .. is the r-code produced by OEA or the procedure editor, and does it make a difference?
It's a bug, IMO, and one that's bitten me and that I've not been able to narrow down enough (so you'd have at least one "like" for it .
-- peter
mmm. what is the _1327 number - is that the number of objects created
in the session so far ?
It is always consistent (same number).
If I add a new object anywhere before the offending line, then the new
object fails, and this one then works
Checking rcode now.
jmls wrote:
mmm. what is the _1327 number - is that the number of objects created
in the session so far ?
It is always consistent (same number).
If I add a new object anywhere before the offending line, then the new
object fails, and this one then works
Checking rcode now.
Basically these are the object references ("handles" if you will). They're always the same (or thereabouts) since you're probably running the same code in a new session every time. They start at 1 I guess and keep on adding up ... (look at SESSION:HANDLE some day, it's always the same value; same principle).
The Progress.Lang.Object ToString() method - which is what's showing the text you typically see when doing a MESSAGE on an object, even without an explicit ToString() call - shows the typename of the class + _
-- peter
right, so my point is that it always fails at this point. If I
create another clientgroup valueobject it fails at the new create
line. If, however, I create a different type of valueobject (say
account) then it fails at the original point again.
So, it is linked to the ClientGroup ValueObject itself in some respect.
Interesting. It seems related to inheritance as well. Remove the inheriting, and it works just fine. Put it back in, same problem, same place.
And r-code from the OE editor has the same problem