en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en nl en en en en en en en en en de en en en en en nl en en en en en en en en en en en en en en nl en en en en en en en en en en nl en en en en en en en en en en en en en en en en en en nl en en en hu en en en en en en en en en en en fr en da en en tr en en en en nl en en en en en it en en en en en en en nl vi en en en en en en en en fr en da en en en en en en en nl en en en en en en en en en en en en en en tr en en en en nl fr en en en en en en en en en en en en en nl en cs en en en en en en en fr en da en en tr en en en en nl en cs en en en en en en en en en tr en en en en nl en en en en en en en en en en en en en en en en nl en en en en en en en en en en fr en da en en en en en en en nl en en en en en en en en fr en da en en tr en en en en nl en en en en en en en en en en en en en nl en en en en en fr en da en en tr en en en en nl en en en en en it it en en en en en en en nl en en en en en en en en en en en en tr en en en en nl de en en en en it it en en en en en en en nl en de en en en en en en en en en en fr en da en en en en de en en en fr en en en en en en en en en pt en en en en en en
By logging into your account, you agree to our Privacy Policy, personal data processing and storage practices as described therein.
Forgot password or user name?
Search in titles only Search in Programming only
You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
All Time Today Last Week Last Month
All Discussions only Photos only Videos only Links only Polls only Events only
Previous 1 2 template Next
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.
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 )
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 specific 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)
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.
Join Date: Aug 1998
2 Jan 2009, 02:34 PM
If autoit (I have a client who LOVES this) can run an external process via "SHELL" or equivalent, you can shell your PB program
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.
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.
Port Washington WI USA
Join Date: Oct 2001
2 Jan 2009, 04:14 PM
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
Join Date: Aug 1998
2 Jan 2009, 06:07 PM
>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!!!
Port Washington WI USA
Join Date: Aug 2006
2 Jan 2009, 06:40 PM
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???"
Engineer's Motto: If it aint broke take it apart and fix it
"If at 1st you don't succeed... call it version 1.0"
"Half of Programming is coding"....."The other 90% is DEBUGGING"
"Document my code????" .... "WHYYY??? do you think they call it CODE? "
Join Date: Oct 2001
3 Jan 2009, 02:11 AM
Originally posted by Michael Mattias View Post
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.
Join Date: Aug 1998
3 Jan 2009, 10:19 AM
> 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.
Port Washington WI USA
Join Date: Oct 2001
3 Jan 2009, 10:43 AM
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.
Join Date: Oct 2001
3 Jan 2009, 10:45 AM
Originally posted by Michael Mattias View Post
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?"
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.
Last edited by Eros Olmi; 3 Jan 2009, 10:49 AM.
Join Date: Aug 1998
3 Jan 2009, 11:50 AM
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.
Port Washington WI USA
Join Date: Aug 1998
3 Jan 2009, 11:52 AM
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).
Port Washington WI USA
Join Date: Oct 2001
3 Jan 2009, 12:18 PM
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.
Last edited by Eros Olmi; 3 Jan 2009, 12:38 PM.
Join Date: Aug 1998
3 Jan 2009, 03:18 PM
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.
Port Washington WI USA
Join Date: Oct 2001
3 Jan 2009, 03:23 PM
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.
Join Date: Dec 2008
3 Jan 2009, 04:52 PM
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.
Join Date: Oct 2001
4 Jan 2009, 02:46 AM
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).
Join Date: Aug 1998
5 Jan 2009, 09:53 AM
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   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.
Port Washington WI USA
Previous 1 2 template Next
Copyright © 1998-2022 PowerBASIC Tools, LLC - All Rights Reserved.
Powered by vBulletin® Version 5.7.0
Copyright © 2022 vBulletin Solutions, Inc. All rights reserved.
All times are GMT-5. This page was generated at 02:26 AM.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.