Using External .p Functions in ABL Class - Forum - OpenEdge Development - Progress Community

Using External .p Functions in ABL Class

 Forum

Using External .p Functions in ABL Class

This question is answered

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?

Verified Answer
  • 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.

     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

All Replies
  • 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.

  • 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.

     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • 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.

     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

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

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • 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.

     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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.