Announcement

Collapse
No announcement yet.

Evaluate Call at Runtime?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Evaluate Call at Runtime?

    I'm pretty sure this is not possible with the Call statement:
    Code:
    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

  • #2
    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 )
    hellobasic

    Comment


    • #3
      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)

      Comment


      • #4
        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

        Comment


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

          Code:
          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
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            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
            thinBasic programming language
            Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

            Comment


            • #7
              >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
              Michael Mattias
              Tal Systems Inc. (retired)
              Racine WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                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? "

                Comment


                • #9
                  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.
                  thinBasic programming language
                  Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

                  Comment


                  • #10
                    > 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
                    Michael Mattias
                    Tal Systems Inc. (retired)
                    Racine WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      Full story here:
                      http://www.thinbasic.com/public/prod...l/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.
                      thinBasic programming language
                      Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

                      Comment


                      • #12
                        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?"
                        http://community.thinbasic.com/index...17904#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.
                        Last edited by Eros Olmi; 3 Jan 2009, 11:49 AM.
                        thinBasic programming language
                        Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

                        Comment


                        • #13
                          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
                          Tal Systems Inc. (retired)
                          Racine WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            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
                            Michael Mattias
                            Tal Systems Inc. (retired)
                            Racine WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              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, 01:38 PM.
                              thinBasic programming language
                              Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

                              Comment


                              • #16
                                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.
                                Michael Mattias
                                Tal Systems Inc. (retired)
                                Racine WI USA
                                [email protected]
                                http://www.talsystems.com

                                Comment


                                • #17
                                  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
                                  thinBasic programming language
                                  Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

                                  Comment


                                  • #18
                                    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

                                    Comment


                                    • #19
                                      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
                                      thinBasic programming language
                                      Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

                                      Comment


                                      • #20
                                        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
                                        Michael Mattias
                                        Tal Systems Inc. (retired)
                                        Racine WI USA
                                        [email protected]
                                        http://www.talsystems.com

                                        Comment

                                        Working...
                                        X