7.2.1

I have the need to "call" a function and get back the results. But, I don't know the name of the function until runtime and want the ability to add new functions without changing the main module (thus, don't want to use a giant CASE statement). It "appears" that callFunction() would work, which needs CreateQueue, which in turn needs CreateEngine. However, when I try to call CreateEngine (using a cut-and-paste from the online help), I get a load error:

equ CREATE_ENGINE_CREATE_NEW$ to 0x001

CreateEngine(Engine, "", @DBID CREATE_ENGINE_CREATE_NEW$, 1)

Error is SYS1000: Error loading program "CREATEENGINE"

My question is:

a) will using these three functions accomplish what I am attempting to do

b) are the programs supposed to still existing in OI and run?

If you can make the "functions" "subroutines" instead, you can do the following (note the call sentence)…

EVENTSUB=GET_PROPERTY(WINDOW,'@EVENTSUB')

IF EVENTSUB NE NOTHING$ THEN

  MESSAGE=NOTHING$

  CALL @EVENTSUB(SUCCESS,MESSAGE,'CLICK',CTRLENTID,CTRLCLASSID)

END

Karen,

Yes the functions should exist - do you have a $CREATEENGINE record in your SYSOBJ table? If not you may need to run Declare_Fcns against the DLL_OENGINE record in SYSPROCS to create the function stubs.

That aside - unless you really really need to have your function run in a separate process/thread use Richard's suggestion using the "call @procName" syntax. Also you can take a look at the function() function, which is similar to "call @" but returns a value.

eg.

funcName=MyFunction"

retVal=function( @funcName( var1, var2 ) )

The Sprezzatura Group

World leaders in all things RevSoft

Karen,

The Call @Program(…) and Function( @Function… ) call BASIC+ routines where the program names are not known in advance. If you look at the Manage/Processes/Reports and Manage/Processes/Processes windows of the ATLAS demo, you will see that subroutine and function calls are exposed and used as entered data for execution there.

The ATLAS framework contains statement interpreter routines and a command interpreter to PROC subroutines and functions as a shell around the @Program and @Function routines. And why do you need a shell? Because the number of parameters of the subroutine or function must be determined at runtime, as well as the program name.

Write me if you need more information about the PROC shell.

Gerald

[email protected]

Doing so would break a lot of other code (not to mention not following good programming practice). I suppose with a doubling of maintenance, duplicates could be created, but it isn't practical - these will all be functions and the number can be expanded later on with no need for the calling routine to know.

Gerald,

That did the trick (once I figured out the confusing syntax in the help screen). For some reason, examples of call @subr() were not linking to the function(@func()) help pages and I just could not find it.

In this particular case, multiple arguments are not necessary (blame legacy code, old AREV functions in some areas could only have one argument, so this series only ever has one and parses that function into all values any called function needs (I essentially, each acts as it's own smart interpreter, but they've worked for years and I'd rather not make changes, as all worked with just a quick recompile in OI (the user interface part of them is all kept in one function call, so only one piece of code needed changes for all to work with no other changes).

Nope, no $CreateEngine there (and no createqueue or callfunction or closequeue, so none of the code had a chance at working). I just checked my notebook - it was a clean install at 7.1 and updated to 7.2.1 (the other is a many times updated system). Neither have any of these functions in SYSOBJ. Should not these basic functions already be set up in SYSOBJ (especially as they are documented in the online help for use)?

Any tips on how to get them all declared?

And yes, in this instance, it turns out that function(@func()) will work – but I know that I'll want the other for a planned enhancement later on (if I get time to do it).

Glad I could help. Luckily you did not need a general PROC shell around arbitrary "Function(@Function…" or "Call @Program…" commands. The command interpretation can be messy.

Karen,

I am surprised that the SYSOBJ table does not have the necessary functions to use the OpenEngine. I will investigate and get them in for the next release.

If your DLL_OENGINE record in SYSPROCS contains the following:

VOID INTERNAL POINTER_02(VOID) AS RTP90

VOID INTERNAL POINTER_03(VOID) AS C_PACK

VOID INTERNAL POINTER_04(VOID) AS BLD_TEMPLATE

VOID INTERNAL POINTER_05(VOID) AS OEPUTDATA

VOID INTERNAL POINTER_06(VOID) AS OEREQINFO

VOID INTERNAL POINTER_07(VOID) AS OEPUTSTAT

VOID INTERNAL POINTER_08(VOID) AS OEGETCLIENTSTAT

VOID INTERNAL POINTER_09(VOID) AS RETSTACK

VOID INTERNAL POINTER_22(VOID) AS SET_BGND_IX_TIME

VOID INTERNAL POINTER_23(VOID) AS GETIOFLAG

VOID INTERNAL POINTER_24(VOID) AS SETIOFLAG

VOID INTERNAL POINTER_25(VOID) AS GETENGINEWINDOW

VOID INTERNAL POINTER_26(VOID) AS GETHANDLECOUNT

VOID INTERNAL POINTER_27(VOID) AS SETINITDIROPTIONS

VOID INTERNAL POINTER_28(VOID) AS ISEVENTCONTEXT

VOID INTERNAL POINTER_30(VOID) AS CREATEENGINE

VOID INTERNAL POINTER_31(VOID) AS CREATEQUEUE

VOID INTERNAL POINTER_32(VOID) AS CREATEREQUEST

VOID INTERNAL POINTER_33(VOID) AS POLLFORREPLY

VOID INTERNAL POINTER_34(VOID) AS WAITFORREPLY

VOID INTERNAL POINTER_35(VOID) AS GETREPLY

VOID INTERNAL POINTER_36(VOID) AS SENDRESPONSE

VOID INTERNAL POINTER_37(VOID) AS GETSTATUSTEXT

VOID INTERNAL POINTER_38(VOID) AS CLOSEREQUEST

VOID INTERNAL POINTER_39(VOID) AS CALLSUBROUTINE

VOID INTERNAL POINTER_40(VOID) AS CALLFUNCTION

VOID INTERNAL POINTER_41(VOID) AS CLOSEQUEUE

VOID INTERNAL POINTER_42(VOID) AS CLOSEENGINE

then in SYSPROG run the following command from the System Monitor:

RUN DECLARE_FCNS 'DLL_OENGINE' and that will create the SYSOBJ records for you.

If that is not your DLL_OENGINE then look at the help. In the OpenEngine book there is a section called Setup. An easy way to access this Help topic is to launch the Help from the Application Manager and do a search for "DLL_OENGINE". This will place you in the Setup book of the OpenEngine help file.

Sean

Looks like those are there (along with a couple of extras, that I hope will cause no harm). Will run the cmd in SYSPROG and see if all is well, Thx.

The function function?

myVar=SOME_FUNCTION_NAME"

retVal=function( @myVar( p1, p2… ) )

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Maybe I should read ahead more…

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Nah, reading ahead only leads to shorter msg threads.

Thanks, that is what I ended up using (and it worked just fine). I also had to compile a couple of missing dll declarations, in case I want to use some of the built-in functions later on.

Thx, K

View this thread on the Works forum...