Using External .p Functions in ABL Class

Posted by Ken Ward on 12-Jan-2017 16:16

I have a .p that defines some functions:

lib.p:

FUNCTION foo RETURNS INTEGER (INPUT ip-num AS INTEGER):

/* code here */

END FUNCTION.

in a separate file I have a CLASS defined that contains a private HANDLE variable and runs the .p with the PERSISTENT SET option.

CLASS blah INHERITS Form :

  DEF PRIVATE VAR hLib AS HANDLE NO-UNDO.

  CONSTRUCTOR PUBLIC blah( ):

     RUN lib.p PERSISTENT SET hLib.

  END CONSTRUCTOR.

  METHOD PUBLIC INTEGER doFunc(INPUT ip-num as INTEGER):

     RETURN foo(ip-num).

  END METHOD.

 
END CLASS.

The problem is I get this error:

** Unable to understand after -- "foo". (247)   

if I try "RETURN foo(ip-num) in hLib", I get this:

** Unable to understand after -- "ip-num)". (247)

if I try "RETURN foo in hLib (ip-num)", I get this again:

** Unable to understand after -- "foo". (247)

How do I do this?

Posted by Mike Fechner on 12-Jan-2017 16:30

CLASS Test.TestFun:
 
    DEFINE VARIABLE hLib AS HANDLE NO-UNDO.
 
    FUNCTION foo RETURNS INTEGER (INPUT ip-num AS INTEGER) IN hLib.
 
    METHOD PUBLIC INTEGER TestMethod():
 
        RETURN foo (42) .
 
    END METHOD.
 
END CLASS.
 
or
 
RETURN DYNAMIC-FUNCTION ("foo" IN hLib, 42) .
 
Von: Ken Ward [mailto:bounce-kward126@community.progress.com]
Gesendet: Donnerstag, 12. Januar 2017 23:18
An: TU.OE.Development@community.progress.com
Betreff: [Technical Users - OE Development] Using External .p Functions in ABL Class
 
Update from Progress Community
 

I have a .p that defines some functions:

lib.p:

FUNCTION foo RETURNS INTEGER (INPUT ip-num AS INTEGER):

/* code here */

END FUNCTION.

in a separate file I have a CLASS defined that contains a private HANDLE variable and runs the .p with the PERSISTENT SET option.

CLASS blah INHERITS Form :

  DEF PRIVATE VAR hLib AS HANDLE NO-UNDO.

  CONSTRUCTOR PUBLIC blah( ):

     RUN lib.p PERSISTENT SET hLib.

  END CONSTRUCTOR.

  METHOD PUBLIC INTEGER doFunc(INPUT ip-num as INTEGER):

     RETURN foo(ip-num).

  END METHOD.

 
END CLASS.

The problem is I get this error:

** Unable to understand after -- "foo". (247)   

if I try "RETURN foo(ip-num) in hLib", I get this:

** Unable to understand after -- "ip-num)". (247)

if I try "RETURN foo in hLib (ip-num)", I get this again:

** Unable to understand after -- "foo". (247)

How do I do this?

View online

 

You received this notification because you subscribed to the forum.  To stop receiving updates from only this thread, go here.

Flag this post as spam/abuse.

 

All Replies

Posted by Laura Stern on 12-Jan-2017 16:27

You need to declare the function locally within the class.  Like this:

FUNCTION foo RETURNS INTEGER IN hLib.

This does not have the body of the function.  It just tells the compiler about it.  This has to be above the call to foo().  In a Class this has to be outside any method.  Put it at the top - under the declaration of hLib.

Posted by Mike Fechner on 12-Jan-2017 16:30

CLASS Test.TestFun:
 
    DEFINE VARIABLE hLib AS HANDLE NO-UNDO.
 
    FUNCTION foo RETURNS INTEGER (INPUT ip-num AS INTEGER) IN hLib.
 
    METHOD PUBLIC INTEGER TestMethod():
 
        RETURN foo (42) .
 
    END METHOD.
 
END CLASS.
or
 
RETURN DYNAMIC-FUNCTION ("foo" IN hLib, 42) .
 
Von: Ken Ward [mailto:bounce-kward126@community.progress.com]
Gesendet: Donnerstag, 12. Januar 2017 23:18
An: TU.OE.Development@community.progress.com
Betreff: [Technical Users - OE Development] Using External .p Functions in ABL Class
 
Update from Progress Community
 

I have a .p that defines some functions:

lib.p:

FUNCTION foo RETURNS INTEGER (INPUT ip-num AS INTEGER):

/* code here */

END FUNCTION.

in a separate file I have a CLASS defined that contains a private HANDLE variable and runs the .p with the PERSISTENT SET option.

CLASS blah INHERITS Form :

  DEF PRIVATE VAR hLib AS HANDLE NO-UNDO.

  CONSTRUCTOR PUBLIC blah( ):

     RUN lib.p PERSISTENT SET hLib.

  END CONSTRUCTOR.

  METHOD PUBLIC INTEGER doFunc(INPUT ip-num as INTEGER):

     RETURN foo(ip-num).

  END METHOD.

 
END CLASS.

The problem is I get this error:

** Unable to understand after -- "foo". (247)   

if I try "RETURN foo(ip-num) in hLib", I get this:

** Unable to understand after -- "ip-num)". (247)

if I try "RETURN foo in hLib (ip-num)", I get this again:

** Unable to understand after -- "foo". (247)

How do I do this?

View online

 

You received this notification because you subscribed to the forum.  To stop receiving updates from only this thread, go here.

Flag this post as spam/abuse.

 

Posted by Thomas Mercer-Hursh on 12-Jan-2017 16:54

And, since you have your answer, let me throw in a piece of bonus advice ... which no doubt someone will argue with.  My inclination is to avoid doing things in a constructor which might fail ... like RUN ... since they can leave you with a non-instantiated class to handle.  Better, to my taste, is to do such things in an initialize method so that one already has a valid class reference and it can then be more obvious and cleaner to handle possible errors.

Posted by Mike Fechner on 12-Jan-2017 17:00

Argued. The initialize method would just fail like the constructor would. Where’s the value in the difference?
 
Von: Thomas Mercer-Hursh [mailto:bounce-tamhas@community.progress.com]
Gesendet: Donnerstag, 12. Januar 2017 23:56
An: TU.OE.Development@community.progress.com
Betreff: RE: [Technical Users - OE Development] Using External .p Functions in ABL Class
 
Update from Progress Community
 

And, since you have your answer, let me throw in a piece of bonus advice ... which no doubt someone will argue with.  My inclination is to avoid doing things in a constructor which might fail ... like RUN ... since they can leave you with a non-instantiated class to handle.  Better, to my taste, is to do such things in an initialize method so that one already has a valid class reference and it can then be more obvious and cleaner to handle possible errors.

View online

 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

 

Posted by Thomas Mercer-Hursh on 12-Jan-2017 17:06

Providing error handling on a method invocation is natural, but doing so on a new is odd.

Posted by Mike Fechner on 12-Jan-2017 17:16

I can’t follow. Seems like a personal flavor to me.
 
You don’t refer to no-error and if error-status:error as error handling, right?
 
With structured error handling, errors are just to be handled (catch’ed) where there’s a useful alternative execution – or when you want to catch and rethrow a higher level error object. In in many cases, that’s just doing logging at a system’s boundary before returning the error to the calling system (client in many cases) or when on the UI at the end of an event handler.
And in that scenario,
 
o = NEW className () .
o:Initialize() .
 
FINALLY:
    IF VALID-OBJECT (o) THEN
         DELETE OBJECT o .
END FINALLY.
 
or
 
o = NEW className () .
o:Initialize() .
 
CATCH err AS Progress.Lang.Error:
   UNDO, THROW NEW UnableToInizializeMyDependencyException (err:GetMessage (1), err:GetMessageNum (1))) .
END CATCH .
 
FINALLY:
    IF VALID-OBJECT (o) THEN
         DELETE OBJECT o .
END FINALLY.
 
 
I can hardly see, why you’d have a preference for it failing at the second line vs. the first one.
 
Von: Thomas Mercer-Hursh [mailto:bounce-tamhas@community.progress.com]
Gesendet: Freitag, 13. Januar 2017 00:08
An: TU.OE.Development@community.progress.com
Betreff: RE: [Technical Users - OE Development] Using External .p Functions in ABL Class
 
Update from Progress Community
 

Providing error handling on a method invocation is natural, but doing so on a new is odd.

View online

 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

 

Posted by Ken Ward on 13-Jan-2017 13:16

Thank you for all your replies. Since I initially wrote this I decided to put these functions into a new CLASS as STATIC methods.

The methods will allow me to take advantage of some newer features such as void return type (without making a PROCEDURE) and function overloading.

I'll keep this in mind if it ever comes up in the future.

This thread is closed