Embedded - supported or not?

Hi Eros,

Exactly how I am using it. I'm using it as the macro engine for an Editor. A variety of user functions are used to provide the API between the script and the application itself. It works very well. Even before, when using BInt32, it was more than capable of handling the scripting requirements. Now that I have thinBasic running as the engine, it's even more powerful. But I've uncovered one oddity. If I issue a USES to bring in another module (like FILE) it works fine. But if I simply re-run the macro/script again, the USES fails with a return code of -3 saying the module is already loaded. It seems thinBasic_Release() is not releasing the DLL. Even though -3 says it's still loaded, it actually isn't and an attempt to use, say, FILE_Exists fails.

So right now, other than using the CORE functionality (which is still great!) access to all the other modules is effectively curtailed as it requires a restart of the main App to get rid of the FILE DLL. Is this just a code oversight? Or a design flaw?

Beyond that, it seems to run embedded exactly as I would like and has been extremely simple to create the interface. It is a joy to work with.

George

Quote:

---

Originally Posted by ErosOlmi

Great.

If you like, giving more details on how you use thinBasic as embedded language can give me more info on how to improve thinBasic Core engine.
In my mind, the idea to embed a programming language into a main application is to perform operations on the main application.
More or less like having VBA in Office applications (pass me the comparison: VBA is much powerful than thinBasic).

Is this the case?

Thanks
Eros

---

Do you Init/Run/Release every time you execute a script?

Hi,
Yes, Init, a bunch of LoadSymbols, Run, and Release. It is basically the sample code you provided, including the FreeLibrary of thinCore.DLL at the end.

In my test script, the return code from USES for the first run is 20 (?) and for a second run is -3.

George

Quote:

---

Originally Posted by ErosOlmi

Do you Init/Run/Release every time you execute a script?

---

Ok, thanks.

so you are developing your internal functions and mapping them using thinBasic_LoadSymbol after thinBasic_Init.
Theoretically it should work ;)
I say "Theoretically" because no-one reported me so far to have tried that way.

20 as return code is not good.


I need few more info:

1. what modules are you loading with USES ...
2. where are you placing thinBasic modules relatively your main Application?
   I mean, if your application is placed in something like C:\MyApp\MyEditor.exe
   where are thinBasic module placed? C:\MyApp\.....

You should place the thinBasic modules you need under your main Application directory under one of the following directories:
"Lib\"
"Bin\"
"Mod\"


Thanks
Eros

PS: I will move this thread under another forum: http://www.thinbasic.com/community/f...-thinBasic-SDK

Hi,

Is there a preferred sequence for Init/LoadSymbol/Run? It seems to work just fine as I'm doing it.

If RC=20 is not good, it doesn't seem to affect use of the DLL functions. I'm doing a USES "FILE" and then calling FILE_Exists and it seems to work just fine.

Not having USES right now is not a serious problem, the functions in CORE are all that is truly NEEDED. I just wanted to try out USES so that I'd know any implications before questions start coming in from my own users.

I originally had just thinCore.DLL in the same folder as my own App EXE, but when I was going to try out the USES facility, I thought it better to leave them in your thinBasic install locations. So I have added the thinBasic folder and thinBasic\LIB folders to my PATH. I thought it best for final installer considerations to just tell my users to install thinBasic as normal, add them to the path, and then do the install of my App. Do you have any concerns, ideas, etc. as to what would be the best method of coordinating this? I can, of course just place everything in my own install directories, but I thought it best to keep thinBasic and my own Apps modules apart for maintenance reasons.

George

Quote:

---

Originally Posted by ErosOlmi

Ok, thanks.

so you are developing your internal functions and mapping them using thinBasic_LoadSymbol after thinBasic_Init.
Theoretically it should work ;)
I say "Theoretically" because no-one reported me so far to have tried that way.

20 as return code is not good.


I need few more info:

1. what modules are you loading with USES ...
2. where are you placing thinBasic modules relatively your main Application?
   I mean, if your application is placed in something like C:\MyApp\MyEditor.exe
   where are thinBasic module placed? C:\MyApp\.....

You should place the thinBasic modules you need under your main Application directory under one of the following directories:
"Lib\"
"Bin\"
"Mod\"


Thanks
Eros

PS: I will move this thread under another forum: http://www.thinbasic.com/community/f...-thinBasic-SDK

---

The correct situation for developers wanting to use thinBasic as embedded engine should be:

1. distribute thinCore.dll with your application placing it in the same directory of your main app.
2. distribute the thinBasic modules you want distribute placing them into one of the following sub-directories under your main application directory: "Lib\" or "Bin\" or "Mod\"

So (for example) something like the following:

.\MyApplication.exe
.\thinCore.dll
.\Bin\thinBasic_UI.Dll
.\Bin\thinBasic_Trace.Dll

Anyway, I will make some test application embedding thinCore.dll and see.

Thanks for using thinBasic.

Ciao
Eros

Eros: Any news at all as to why I cannot USE any of the other modules other than CORE more than once? I can survive using only CORE functions, but I'm sure my users, once they start exploring thinBasic usage as an embedded macro language, are for sure going to ask why they can not have access to the remaining set of modules.

Is there any release/free function I could insert in my main code? I could certainly scan for the USES and determine what modules need to be processed.

George

George,

did you follow my indication to create a \Bin\ directory under you main EXE and place module in there?

Was that indication working or not?

Let me know.
Eros

Eros:

If I put the module's DLL in a /Bin directory under the EXEPath directory, then thinBasic does not seem to find the DLL at all.

If I put the module's DLL directly IN the EXEPath directory, then the DLL is found and a call to a function within it works perfectly.

e.g. my app calls thinBasic to run the script, the script successfully USES and calls a function in the module's DLL, and the script terminates normally via a STOP command.

If I then, without restarting my main app, repeat the call to run the script, the call to the DLL module fails.

If I restart my app again, I can invoke the script, with its USES DLL call once and only once. As I indicated earlier, the error is returned by the USES command (the USES fails with a return code of -3 saying the module is already loaded), which seems to indicate that thinBasic has not quite cleaned up the linkages from the first use of the DLL.

George

Just some experience - won't interfere - so don't bother if not of your interest.

My safe way to create .exe of something that needs a "foreign" dll:

Add .dll to bundle, (sometimes .dll disappears after bundling - but then i just replace it) - sometimes does not disappear - I don't care - I'm used to it.
But as long as .dll is in same path as .tBasic-script is - and also if .dll gets bundled into the .exe I have no problems.
If I ship .dll seperate from bundled exe or .dll is not at same path as .tBasic-script - does not work always as expected - so I stick to keep .dll next to .tBasic-script on same path, and if bundling - always add .dll into the bundle. Never had any problems that way.