Been chasing this "feature" around for a while - I managed to get a workaround without understanding the problem, as it was buried deep in the application classes.
however, I've finally managed to get a small, reproducible use case, so thought that I would share it.
take the following class:
CLASS foo:
DEF PUBLIC STATIC PROPERTY instance AS foo NO-UNDO
GET():
IF NOT VALID-OBJECT(instance) THEN
do:
instance = NEW foo().
instance:INIT().
END.
RETURN instance.
END GET . PRIVATE SET.
DEF PUBLIC PROPERTY TestDate AS DATE NO-UNDO
GET():
RETURN TODAY.
END GET . PRIVATE SET.
METHOD PUBLIC VOID INIT():
MESSAGE CAN-FIND(FIRST Customer) VIEW-AS ALERT-BOX.
END METHOD.
END CLASS.
and run this test program
FOR EACH order WHERE Order.OrderDate LE (foo:instance:TestDate) NO-LOCK:
END.
MESSAGE "hello" VIEW-AS ALERT-BOX.
So, what happens is that you get a "no" (in the class init() ) followed by nothing.
change the test program to
foo:instance:TestDate.
FOR EACH order WHERE Order.OrderDate LE (foo:instance:TestDate) NO-LOCK:
END.
MESSAGE "hello" VIEW-AS ALERT-BOX.
and everything works as expected ("yes", followed by "hello").
it turns out that the problem is in the init() method, because of the Customer reference.
if you replace the can-find() with a simple FIND FIRST Customer NO-LOCK. you now get an error message 7254 (Illegal FIND, FOR EACH or OPEN QUERY in User-defined function INIT foo)
What really got me about this was that the error handling didn't seem right - there was no message, just a silent failure of the class.
The workaround worked because the init method was being called outside of a loop, and therefore this error never got raised.
Anyhow, just thought I'd throw that out there and solicit comments
if you replace the can-find() with a simple *+FIND FIRST Customer NO-
LOCK+*. you now get an error message 7254 (Illegal FIND, FOR EACH or
OPEN QUERY in User-defined function INIT foo)
What really got me about this was that the error handling didn't seem
right - there was no message, just a silent failure of the class.
The workaround worked because the init method was being called
outside of a loop, and therefore this error never got raised.
Anyhow, just thought I'd throw that out there and solicit comments
Sounds like a bug to me.
Can you catch either error?
-- peter
what's a bug ? the 7254 error happening when it shouldn't, or the
error not being raised when it should ?
Checking the catch problem now.
what's a bug ? the 7254 error happening when it shouldn't, or the
error not being raised when it should ?
Yes
7254 or equivalent not being raised bears investigation by PSC.
-- peter
Possibly both. Worth checking on the bug, but I would also say Don't Do That!™
load and clear
On 1 July 2011 17:39, Thomas Mercer-Hursh