Evaluate Call at Runtime?

[Randal Lanning]

I'm pretty sure this is not possible with the Call statement:

Dim ProgramName$
ProgramName$ = "MyRoutine"
Call ProgramName$(1, 2, 3)

Sub MyRoutine(a, b, c)
  'do some stuff here
End Sub

Before I attempt to create something, I thought I would check to see if anyone had any ideas.

Thanks,

Randal

[Edwin Knoppert]

There are two options:

1) Export ALL the required functions and use the GetProcAddress() API to get a pointer to the function

2) Use Codeptr() (without export keyword) to obtain an address.

Then Use: Call Dword pAddress Using FunctionDeclaration( a, b, c )

[John Petty]

Seems like you are really talking about add in Dll's in which case not really very hard at all. Somewhere you need a list of all the add ins, say an INI file or they all must be in a specfic folder so they can be explicitaly loaded. Then it is easy to check whether a particular function is available in that DLL using GetProcAddress, if it is then you can use it with CALL DWORD whatever returned address USING . You can go to more esoteric possabilities but that means you are writing your own COM (which M$ has done several times)

[Randal Lanning]

Hi Edward and John,

Actually, I'm trying to do something pretty simple in concept. I've created something that works. It isn't elegant per se but it gets the job done. I'll explain what I need in more detail.

I'm writing a home automation system for myself and was doing it in Auto IT 3 which does a nice job but is slow and somewhat bulky which is why I decided to buy PowerBasic and translate it. Auto IT has a function named "CALL" which will evaluate, at run time, whatever value(s) are passed in and call an internal function or procedure.

Now, I have a set of database files that work together to take a spoken command ("How is the weather?" for example), look up a procedure from a table that will need to be run, and it has within it, GetWeather(). So in Auto IT, it would be a matter of CALL(cmd$) where cmd$ ends up as "GetWeather()" and runs the internal routine.

But I thought about it some more and realized I could just program a SELECT CASE and do some parsing to run the internal functions since anything internal anyway will have to be compiled.

What I might do in the future is make some kind of simple external scripting language for little things like this but that would be Version 2.0 at best. I'm thinking that others may like it one day when they come into my home and see it work but for now, it's just for me to play with.

That's what I'm trying to accomplish.

Thanks,

Randal

[Michael Mattias]

If autoit (I have a client who LOVES this) can run an external process via "SHELL" or equivalent, you can shell your PB program
**OR**
You can structure your functions to use the correct parameters (below) put 'em in a DLL, and SHELL "RunDLL32.Exe" to execute that function.

void CALLBACK EntryPoint(
  HWND hwnd,        // handle to owner window
  HINSTANCE hinst,  // instance handle for the DLL
  LPTSTR lpCmdLine, // string the DLL will parse
  int nCmdShow      // show state

In your case I'd imagine parameters 1,2, and 4 would be pretty useless.

Wait a minute....
SEE http://www.autoitscript.com/autoit3/docs/functions.htm

Both RUN* and ShellExecute* will run external programs.

There is a reference to "plug ins" but I can't find the detail doc on that. Maybe those allow you to store functions in a DLL and execute as though they were intrinsics.

MCM

[Eros Olmi]

AutoIt is a great language but quite slow.
thinBaisc is very similar to AutoIt in principle but it is much faster (x5 or x10 depending on the task) and as a CALL function able to evaluate the function name at runtime. This is a prerogative of interpreted languages: http://www.thinbasic.com/public/prod.../html/call.htm

Regards
Eros

[Michael Mattias]

>AutoIt is a great language but quite slow

Let's think about this for a moment.

What is the purpose of AutoIt? It is to REMOVE THE OPERATOR, ALLOWING THE PROGRAM TO RUN UNATTENDED.

So who cares if it is "slow?" It's not like there is anyone sitting there waiting on it!!!


MCM

[Cliff Nichols]

Ok I am confused???

Is the core point to "Script" a program? or to allow for "Add-In" options??? or maybe both????

Shelling or scripting to me are basically the same thing (Control the program at runtime via a series of steps)

Adding in options at runtime is another (aka: Add-ins, which I have no/little knowledge of, and have been meaning to ask MCM about a basic example)

COM and Automation and OCX type stuff, is a whole new world to me (minus my VB "Do NOT look at the man behind the curtain" stuff) so that could be altogether different

Possibly several answers depending on the route you are looking for...or maybe the question is "What ROUTE to look for???"

[Eros Olmi]

What is the purpose of AutoIt? It is to REMOVE THE OPERATOR, ALLOWING THE PROGRAM TO RUN UNATTENDED.

Very very limited view of what is AutoIt or in general a scripting language.
Maybe your sentence was true ... let's say 5 years ago when it was just an automation script engine used to execute other applications.

Now scripting languages are quite complex and (bealive me) you can program with them whatever you like. At that point execution speed is a point.

[Michael Mattias]

> Now scripting languages are quite complex

I'm still waiting for that API/DLL version of ThinBasic. That's what I wanted to use for a 'design your own reports' application. (Addon to The PPPS)

And since then I have another application in mind, one I'm going be working on heavily starting this upcoming week. Some kind of 'user-scripting' could be very useful for one of the modules I'd like to include with that offering.

But I will be honest, I have not looked at ThinBasic for a couple of years; for all I know there are other new features since then which would make it what I want 'off the shelf' today.

MCM

[Eros Olmi]

Full story here:

http://www.thinbasic.com/public/products/thinBasic/help/html/whatsnew.htm

A couple of years is a big jump in thinBasic release history.

But better to talk in another post (or in thinBasic forum) just not breaking the original question of the current post: dynamically calling functions using function name computed at runtime.

Going back to original question ...

I think that creating a dynamic CALL is quite easy if all possible functions have exactly the same parameters. You can create an hash table (or whatever other data structure able to quicly recall a value) storing the name of the function as key and the pointer to the real function as data. Than uses CALL DWORD ... using a function template.

If every function can have different parameters, things get more complex but not impossible. A SELECT CASE can choose the correct function but what about parameters? Maybe VARIANT can help.

[Eros Olmi]

I'm still waiting for that API/DLL version of ThinBasic. That's what I wanted to use for a 'design your own reports' application. (Addon to The PPPS)

It is in my "New Year resolutions regarding thinBasic?"

http://community.thinbasic.com/index.php?topic=2356.msg17904#msg17904

Also do not forget thinBasic can be expanded creating modules. You can always create your own thinBasic module using Power Basic and create your own keywords.
This would let you use PPPS system as an add-on of thinBasic.

[Michael Mattias]

Hmmm...

release thinBasic Core engine as independent engine to be used by 3rd party applications as internal script engine

That would be me. Yes, indeed.

Quite scared about it

Don't be. I know you "write good."

FWIW if you want ideas from a genuine third-party developer, I can probably find my old notes and maybe even update them. Just drop me a note when you get to this.

[Michael Mattias]

Probably just semantics, but...

This would let you use PPPS system as an add-on of thinBasic

Actually, the way I think, ThinBASIC would be an add-on to the PPPS(tm).

MCM

[Eros Olmi]

It can be the other way round too.
thinBasic modules can be DLL that just add few new command to the language or an entire full engine that adds to thinBasic the capabilities to interact with different aspects as a whole.

Anyhow, come to http://community.thinbasic.com and we can talk about that. I know you can give us a lot of suggestions and ideas. And we will be very happy to develop them.

[Michael Mattias]

I could agree PPPS is an add-on to ThinBasic ..... if I had spent 2500 hours over seven years on ThinBasic and not on PPPS.

[Eros Olmi]

I didn't want to say something to lower your PPPS, sorry.
I just wanted to say that things can be seen in different ways.

Anyhow, you know where to find me and I know where to find you. When I will have something to let you test on the scripting side (embedded) I will send you a PM.

Ciao
Eros

[Randal Lanning]

If every function can have different parameters, things get more complex but not impossible. A SELECT CASE can choose the correct function but what about parameters? Maybe VARIANT can help.

The parameters are a part of the AI script where maybe a zip code is stored within. It has something like:GetWeather,30032 where there are parameters after the comma which are also comma delimited. Parse the first as the command and the others as the parameters and pass them. That's how I ended up handling it.

Ok I am confused???

Is the core point to "Script" a program? or to allow for "Add-In" options??? or maybe both????

Shelling or scripting to me are basically the same thing (Control the program at runtime via a series of steps)

It does sound confusing, I know. Shelling to an executable is easy. The X-10 system that I use for operating the house has a command line program that takes parameters. However, shelling to an executable from Auto IT to PB is backwards and defeats the purpose of what I'm doing. I may use the former for automating something on my computer but it will be an exception at best. :ven:

Anyway, everyone is giving me some ideas and this is a good thing as I'm learning more about what can be done with PowerBasic.

Randal

[Eros Olmi]

Some time ago I wrote a function able to call DLL functions dynamically passing parameters as string array elements and than pushing parameters in the stack before calling the function. You can find sources at http://www.powerbasic.com/support/pb...hlight=calldll

Maybe you can adapt not to call external functions but functions inside the program. It should just be a matter of function pointers.

The method is the same used by AutoIt when it deals with external functions (I suppose).

Ciao
Eros

[Michael Mattias]

The method is the same used by AutoIt when it deals with external functions (I suppose

I deal with a number of software products which 'do something' using their own set of syntax rules (eg Mercator, Gentran). Many of these same products (eg Mercator, Gentran) provide explicit "user exit" or "hook points" where you can insert code either in--line (eg COGEN, LINC, and their upgrades) or via a DLL (eg Mercator, Gentran) .. or by running an external program ... which if you run "Rundll32.exe" and structure your function correctly, allows those exit functions to be stored in DLLs.

I kind of fell in love with this concept, so I design it into my own products.

The other 'stucture' I like a lot for 'library functions' is to support callbacks. Demos for the curious:
PB/WIN: Write your own ENUM functions to callback September 23, 2002

Enumerate System Threads To Callback November 25, 2002

Both EXITS and Callbacks provide options when you find yourself saying, "Gee, I should have allowed for <something> in this function." If your 'base' function has provided for a callback function with a user value ('lparam' or 'dwuser') you can extend the power of your functions without the need to change out the library file... a genuine issue if you have many users you would otherwise have to 'upgrade' and/or worry about them using incompatible modules.


MCM