Hi,
Were using a class based implementation of the OERA and run into a problem skipping the creation of a temp-table record after examining database buffers.
According to the ProDataSets documentation creation can be skipped by using the RETURN NO-APPLY statement in the BEFORE-ROW-FILL event.
But compiling the code shown below generates the following error message:
Cannot RETURN a value from a void method. (13454)
/* Start of code */
&SCOPED-DEFINE PACKAGE-NAME common
&SCOPED-DEFINE ENTITY-NAME client
USING oera.base.*.
CLASS curaservices.common.daclient INHERITS dataaccessobject:
/ds.i &REFERENCE-ONLY=REFERENCE-ONLY}
METHOD PUBLIC OVERRIDE VOID attachDatasource():
DEFINE VARIABLE cFieldMapping AS CHARACTER NO-UNDO EXTENT 1.
ASSIGN cFieldMapping[1] = ...
bufferDatasource(...).
hdsDataset::ttClient:SET-CALLBACK('BEFORE-ROW-FILL':U,
'beforeRowFillClient':U).
END METHOD.
...
METHOD PUBLIC VOID beforeRowFillClient(DATASET ds):
...
RETURN NO-APPLY.
END METHOD.
End CLASS.
/* End of code */
Could someone help me to tackle this problem?
OpenEdge 10.1B01
Windows XP SP2
Is it necessary to use NO-APPLY? Would a simple "LEAVE" do the same thing?
Tim,
Replacing the RETURN NO-APPLY statement with a LEAVE or UNDO, LEAVE statement did not prohibit the temp-table row to be created.
In that case it may be necessary to change your method to a non-void return type. This shouldn't be an issue as the ABL throws away function calls that return values that aren't assigned to something.
For instance, code can do this:
function-call(x,y,z).
and that'll compile and work fine. I would expect the same is possible for a method call, ie:
class-instance:method-name(x,y,z).
Changing return type in CHARACTER or LOGICAL combined with "RETURN NO-APPLY", "LEAVE" or "UNDO, LEAVE" statements did not work.
Then I'm guessing your next stop is to ping PSC TS.
It has been a while since I've played with this, but wasn't it supposed to be a RETURN-ERROR from the event handler to abort it? I will check to make sure...
Wouldn't return-error have other implications if the only requirement was to avoid making this TT record?
Using RETURN ERROR results in a crash and error message 735!
At least you know your TT record wasn't created.
Yes, I was wrong. The documentation is correct that the event handlers use RETURN NO-APPLY to abort the handler. This is what we've used before. Now that was procedural code, will have to check further for OO based coding. Sorry for the confusion. My memory addressing is somewhat flakey lately :-)
Maybe you should change your Avatar from a wizard to that of a standup comedian.
It wouldn't be the first time I've run into situations where the only redeeming value of some code was that it worked.
OK. There is a bug logged for this actually! It is scheduled to be fixed in the OpenEdge 10.2A release. The bug is the problem you mentioned that the RETURN NO-APPLY does not compile in a VOID method.
So if you need this functionality (BEFORE-ROW-FILL), maybe you can create an external event handler (persistent procedure) that handles this (breaks encapsulation I know) *or* move it to the AFTER-ROW-FILL and take the extra processing of creating a TT row and maybe delete it afterwards...
Frank,
Thanks for the tip. Using an external event handler did the trick!
Anyone who's interested can contact me for some code samples.
OK very good!
I would like to ask you to still contact Technical Support to let them know you ran into this problem. It is important for Progress to keep track of issues and who ran into them. Like everything else, bug fixing is a case of priorities and having more people wait for a fix will certainly help trying to get it fixed.
I've filed an issue yesterday with case number W712200039.
OK. Excellent! Thank you!
Hi, we are suffering the same issue. The workaround was to make a .p with an input parameter (the object that actually wants to attach to an event) and four procedures (after-fill, before-fill, after-row-fill, before-row-fill) that calls an object method to actually do the job. If the object method returns 'NO-APPLY' then the procedure does an RETURN NO-APPLY.
Attached is the code.
David.
PD: I've found that with this workaround you can't use RETURN statements in any callback method. If you do so, Progress explodes with a Memory Violation (49) the second time you do a FILL. Use conditional logic instead of RETURN statements and it will work fine.
Mensaje editado por:
David Abdala