Embedded - supported or not?

Quote:

Originally Posted by gddeluca

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

Dear George,

I just released thinBasic Beta 1.9.6.0
With this release I hope I fixed the problem you mentioned.

I also added two options that can be useful.
When you call thinBasic_RUN please indicate as Option parameter the following: 1 Or 2
Option parameter is a bit flag used to pass multiple options.
1 Or 2 means switch bit 1 and 2
1 = to consider as base directory the one of the executable running thinBasic_Run and not thinBasic itself
2 = in case of script run-time error, do not close calling application too. If this option is omitted, thinBasic runtime error engine will fire a PostQuitMessage in case of runtime error.

Below an example:

Code:

thinBasic_RUN( _ 0& , _ 'Will be used in future release sEmbedded_Script_Main , _ 'File name or string Buffer 1& , _ '0 = previous string is a File Name, 1 = previous string is a string Buffer 1 Or 2 , _ 'Options, set it to zero %FALSE , _ 'Debug Mode %TRUE/%FALSE %FALSE , _ 'Log Mode %TRUE/%FALSE %FALSE , _ 'Obfuscate Mode %TRUE/%FALSE 0& , _ 'Calling Program 1=thinBasic, 2=Console %FALSE _ 'Dependancy Mode %TRUE/%FALSE ) To lRet

Let me know if problems related to modules are now solved.
Remember to put modules you want to distribute into one of the following path:

<yourapplicationpath>\mod\
<yourapplicationpath>\lib\

Ciao
Eros

Eros: Regarding the new Options flag setting on the RUN call. I guess I'm not getting this. Are they bit flags within a LONG parameter. I've tried all flavors of passing values, and I cannot seem to get any through (e.g. the PostQuit message is always sent on a syntax error).

I've tried passing simple literal values, I've tried setting up an Options variable and setting various bits in it and passing the variable. Nothing seems to have any effect.

I'd like to utilize both Options 1 and 2, what exactly should be coded? I'm stumped.

George

They are Bit flags inside a LONG parameter.
To use both you need to pass: 1 OR 2

Eros: Here's what I'm trying.

Code:

CALL DWORD hProc_thinBasic_Run USING thinBasic_RUN( _ 0& , _ 'Will be used in future release BasicPgm , _ 'File name or string Buffer %thinBasic_BufferType_IsScript , _ '0 = previous string is a File Name, 1 = previous string is a string Buffer (1 OR 2) , _ 'Options %FALSE , _ 'Debug Mode %TRUE/%FALSE %FALSE , _ 'Log Mode %TRUE/%FALSE %FALSE , _ 'Obfuscate Mode %TRUE/%FALSE 1& , _ 'Calling Program 1=thinBasic, 2=Console %FALSE _ 'Dependancy Mode %TRUE/%FALSE ) TO lRet

I still get a popup from PowerBasic giving a RUNTIMEERROR 1 message; which is, I assume, triggered by the PostQuitMessage; indicating it is still being issued. I'm doing the thinBasic call from a thread of my main program in case that matters at all. I do that so I can monitor for possible loops in the macro code and give my user a chance to terminate the embedded macro instead of having to cancel my whole application, which for an editor, is not too cool an option.

Also, my PB program is written in DDT not SDK mode if that makes any difference.

Right now this is only a nuisance, clicking OK on the RUNTIMEERROR popup dismisses it and my program continues OK But it would be nice to get rid of it.

George

Please check this bug reported immediately by Petr. We fixed it very soon but I suppose you download version 1.9.6 just before. So please download thinBasic beta 1.9.6 again and let me know. http://www.thinbasic.com/community/p...d=398#note2430

Eros: Yes indeed, now runs just fine. Many, many thanks.

George

Eros: Sorry to keep popping back in here. I think there is a problem in thinBasic cleanup when running embedded. I haven't got a repeatable example (yet) that I can provide, but I've seen instances where a small test macro runs and does a MSGBOX to display the result of some function. Then a different small test macro is run doing a similar small test and MSGBOX display. And the 2nd run, after its normal termination, ends up doing the MSGBOX display from the 1st macro's execution. !! ?? There have been other 'weirdnesses' happening, but this was the most obvious and identifiable.

My main App does call

Code:

CALL DWORD hProc_thinBasic_Release USING thinBasic_Release(0& _ 'Will be used in future release ) TO lRet

after each RUN.

Any thoughts?

George

Hi George,

can you please tell me what's inside the message box?

Thanks
Eros

Eros: The extraneous MSGBOX that appears looks exactly like it did when the first macro executed. Same text exactly, so it looks like the thinBasic variables passed to the MSGBOX function are still around. It almost seems as if the thinBasic program and variable pool are still in existence and have somehow been 'merged' (if that's the right word) with the 2nd macro invocation.

The macros in question did not terminate with a STOP, they were simple 3-4 line test scripts. Maybe that's a clue? Execution 'falling into' old text storage? I've subsequently made sure a STOP is inserted as the last line passed to RUN, but since this is an intermittent problem, I'm not sure if that has had any effect. (yet) I thought I'd bring it up with you as it certainly looks like old data from a RUN execution is still in existence somewhere.

George

get ready & jump into Rapid Application Developementß - fasten yoour seatbelts!

Thats an old thread. But it provides the required information on its first page. May i introduce the Ring-language here?

Probably merits a thread of its own.

Its a cross-platform language- interpreter ,
i just make it quick:

It can embed itself. Or embed thinBasic. Or thinbasic can embed it. or embed it twice or trice -
It has no "end function", no case sensitivity, no end of possibilities,

It comes with plenty of features, runs in any environment from desktop-console, Windows-UI, 2D, 3D, as web-app or on mobile phones.
It knows only 1 numeric variable: number
Strings yes, literal or binary memory content
arrays? 1-based lists.

check it out here: https://ring-lang.github.io/

download there: https://sourceforge.net/projects/ring-lang/

__________________________________________________________________________________

As a precaution have a look at this:

1.ThinBASIC Language > thinBasic Functions > Application functions > APP_MutexCreate

2.ThinBASIC Language > thinBasic Functions > Application functions > APP_MutexClose

3.What's new > 2007 - version history > Version 1.5.0.0

Even if sharing memory is possible between different threads of a process - make sure not to access it at same time.