Invoking One .tbasic Program From Another .tbasic Program

[gungadout]

Hi Folks,

I've probably missed the relevant entry in the documentation and examples.

If I have ProgramA.tbasic and ProgramB.tbasic, what instruction(s) should I use in ProgramA to fire ProgramB up?

The idea is that ProgramB will retain compulsory focus until it terminates, at which time the focus will return to ProgramA.

I have tried various things such as ProgramB(), ProgramB.tbasic() and CALL ProgramB(), but with no success. I have also tried including statements such as USES "ProgramB.tbasic".

Both programs exist in the same folder. I am running ProgramA from within thinAir, and ProgramB has not been compiled or obfuscated.

(I assume I'll be able to share variables such as the open TCP port variable (as evaluated by TCPFreeFIle = TCP_FREEFILE and TCPOpenError = TCP_Open(%PortNumber, "", TCPFreeFile, 1000)) by defining them as GLOBAL.)

Once again, all tips will be appreciated.

Regards,

Peter H. (gungadout)

[Michael Clease]

Look at the "OS" module

n = OS_Shell(Command[, WindowStyle[, Mode]])

I think thats what your looking for.

[gungadout]

Hi Michael,

Thanks for the suggestion.

I've tried it, but it seems to pertain to invoking operating system commands only, unless I'm applying it incorrectly.

If I issue the command n = OS_Shell("cmd",,%OS_SHELL_SYNC), the Windows command window opens.

If I issue the command n = OS_Shell("ProgramB",,%OS_SHELL_SYNC) or n = OS_Shell("ProgramB.tbasic",,%OS_SHELL_SYNC), nothing happens.

In all three cases, the returned value in the variable n is zero.

So I'm still in the Twilight Zone, somewhat.

Is there something else I can try, or am I just not using the instruction correctly?

Regards,

Peter H.

[Michael Clease]

oops your right...save the 2 files in the same location and they should work.

[gungadout]

Thanks, Michael.

Your examples worked well.

Two things I've noticed.

-------------------------------------

The first (which someone else may need to look at) is, that whatever value I place in the ShowCmd parameter, the calling program (Program1.tbasic) keeps on executing instead of waiting for the called program (Program2.tbasic) to terminate.

-------------------------------------

The second is, that my called program does not display or function at all unless there is a MSGBOX instruction before the first dialog instruction.

I guess I have to define some parameter within, or related to, the dialog instructions, but I'm not sure what.

-------------------------------------

Once again, all help will be appreciated.

Regards,

Peter H. (gungadout)

[gungadout]

Hi Folks,

I'm also finding that my GLOBAL TCPFreeFile variable has a value of 1 in my calling program, but 0 in my called program.

Is there an equivalent to the "named common" functionality in other Basic languages, which permits a variable evaluated in one program to have that value preserved in a program that it invokes, and a program that the invoked program then invokes, etc.?

E.g. (from a Basic I am used to):

Program 1 COMMON Variable1, Variable2, Variable3
Variable1 = "Red"
CALL Program2
PRINT Variable3 ("Blue" is printed)

Program2 COMMON Variable1,Variable3
PRINT Variable1 ("Red" is printed)
Variable3 = "Blue"

I know I can pass parameters in the OS_ShellExecute command (how does one retrieve them in the called program?), but that can be very awkward if many variables need to be passed. Also, can those parameters be passed bi-directionally, i.e. can the ByRef specification or an equivalent be used?)

Sorry for asking so many questions, but these things are not self-evident to me.

Regards,

Peter H.

[gungadout]

Hi Folks,

I've found out how to retrieve parameters passed by OS_ShellExecute. One uses OS_GetCommands and OS_GetCommand.

However, it seems that only literals can be passed.

If I run a program (Program1.tbasic) containing OS_ShellExecute("Open", APP_ScriptPath+"\Program2.tbasic", "AAA BBB", "", 1), the results I get in Program2 (parameters 2 & 3) are "AAA" and "BBB". Parameters 0 & 1 are as expected.

If I try to assign values to variables AAA and BBB in Program1 and use the command OS_ShellExecute("Open", APP_ScriptPath+"\Program2.tbasic", AAA BBB, "", 1), Program1 gets upset about the presence of BBB and falls over.

If I issue the command OS_ShellExecute("Open", APP_ScriptPath+"\Program2.tbasic", AAA, "", 1), where AAA is defined as LONG = 2476, Program2 receives the following values in parameters 0, 1, and 2, (using STR$() to display them) respectively: " 0", " 0", " 2476".

(I am going to use [ and ] as opening and closing quotes in my text below because the normal " character existed in the parameter displays.)

FYI, Issuing the command OS_ShellExecute("Open", APP_ScriptPath+"\Program2.tbasic", AAA, "", 1), where AAA is defined as LONG = 2476, Program2 receives the following values in parameters 0, 1, and 2, (without using STR$() to display them) respectively: [@1 "D:\thinBasic\00 Development\Program2.tbasic" ], [@1], ["D:\thinBasic\00 Development\Program2.tbasic"].


I know I could potentially convert everything to a concatenated string, pass that, then decode it in the receiving program, but one parameter I do need to pass is the FreeFile value, which I doubt can be transformed.


I guess the question remains:
(a) Is there a mechanism equivalent to the "named common" facilities in other Basic languages?
(b) Is there a way of passing multiple variable names of varying types in the OS_ShellExecute command or equivalent, especially bi-directionally, as is available in other Basic languages?
(c) If neither of the above is true, what else can I do, bearing in mind the FreeFile variable I need to pass?


Thanks,

Peter H. (gungadout)

[gungadout]

Hi Folks,

On _retesting_, the OS_ShellExecute("Open", APP_ScriptPath+"\Program2.tbasic", AAA, "", 1), where AAA is defined as LONG = 2476, Program2 __now consistently__ receives the following values in parameters 0, 1, and 2, (without using STR$() to display them) respectively: ["D:\thinBasic\00 Development\Program2.tbasic" 2476], ["D:\thinBasic\00 Development\Program2.tbasic"], [2476].

I've used [ and ] as my opening and closing quotes as explained in the previous post.

Using STR$() to display the results still results in " 0", " 0", " 2476".

Regards,

Peter H.

[Petr Schreiber]

Hi Peter,

I got a bit lost in your posts, but one thing has easy solution:


If I try to assign values to variables AAA and BBB in Program1 and use the command OS_ShellExecute("Open", APP_ScriptPath+"\Program2.tbasic", AAA BBB, "", 1), Program1 gets upset about the presence of BBB and falls over.


Sure it does not work, as 3rd parameter of OS_ShellExecute must be string.
If you need to pass multiple values from numeric variables, you can try:


OS_ShellExecute("Open", APP_ScriptPath+"\Program2.tbasic", strFormat$("{1} {2}", AAA, BBB), "", 1)


which will pass AAA as parameter1 and BBB as parameter2 in one string.

Windows are based on idea that one process cannot do any change to other process memory. That is why when you run two scripts with same names of variables, you will not see any interference. ( Simplified view on the problem of course )

To make programs communicate, it is recommended to use TCP commands, or memory files or processing WM_COPYDATA message.
From these, the TCP way seems the most typical to me.

I must admit I haven't seen any BASIC where variable interprocess sharing is possible, could you point me to some help files and examples of doing so? Maybe it will inspire some module... Still I consider it quite dangerous.

What happens when two scripts in mentioned languages attempt to write value to same variable at same time? Are there any syncing mechanisms?


I hope it helps,
Petr

[Petr Schreiber]

For example of memory mapped files, please visit this thread:
http://community.thinbasic.com/index.php?topic=1778.msg12925#msg12925

It is very simple way to communicate. To avoid the critical situation of two files writing to same place, I recommend to setup:

one file to read from program1 in program2
one file to read from program2 in program1
one file to write from program1 to program2
one file to write from program2 to program1


As all files exist in memory, the interaction is fast. I think this mechanism could be solution for your script if you need to talk in realtime. If you need to just pass multiple parameters, simply use strFormat$ way.


Petr

[Michael Clease]

you could pass the address of one variable to another program as a text string.

[Michael Hartlef]

you could pass the address of the one variable to another program as a text string.


Besides that this is evil as it could be it would only work for memory that is located outside an apps reserved heap space. At least i think so. But maybe it would work.

[gungadout]

Hi Petr & Michael,

Thanks for your responses and tips.

Michael, I'm unsure how to pass the address of the one variable to another program as a text string. Could you give me an example, please. Hopefully, values can be passed bi-directionally that way.

Petr, the overall idea is that when one program calls another, the calling program stays inactive until the subsidiary (called) program terminates. (Think of MSGBOX - the box retains control until it disappears. You cannot get back to the issuing program any other way. OS_ShellExecute is supposed to permit that, but in my testing based on Michael's programs, that functionality seemed not to work.)

The Calling can happen down a number of levels. There are no synch problems. The programs are not running in parallel. The only program that is active is the program at the bottom of the chain of calls.

This style of control and parameter passing is native to many Basic languages. Some of the databases which have such Basics include:
- Universe and Unidata, marketed by IBM;
- D3 and others, marketed by TigerLogic;
- Jbase.

An explanation of Calling can be found at http://www.mannyneira.com/universe/basic-subroutines.html. Ignore the section referring to cataloging.

As you will see, the concept and the syntax are both quite simple.

Regards,

Peter H. (gungadout)

[Michael Clease]

you could pass the address of the one variable to another program as a text string.


Besides that this is evil as it could be it would only work for memory that is located outside an apps reserved heap space. At least i think so. But maybe it would work.


@MIke - It should work because we can pass variables byref to a module, but I will investigate when I get home.

@Peter - you should use OS_Shell if you want it to wait.

[gungadout]

Hi Folks,

If you are familiar with the MDI functionality in the .NET environment, that gives you an idea of what I'm talking about.

A parent can call children. Each program opens "in the same window". Parameters can be passed back and forward. The currently active child (or parent) is the only one that can be seen. There are no sync problems. The window expands and contracts as appropriate for the active program.

(For thinBasic, that means that only the program with current focus would have a visible window.)

Unfortunately, MDI is a gross complication of something inherently simple. You have to jump through flaming hoops and crawl over broken bottles to get it to work.

What could be simpler than syntax such as (e.g. using SHARED and CALLCHILD because COMMON, COM and CALL are already employed):

Program1 SHARED Variable1, Variable2, Variable3 ' normally, system-wide variables such as FreeFile
Variable1 = "Red"
CALLCHILD Program2.tbasic [(other specific parameters if required)]
Console_Writeline Variable3 ' "Blue" is displayed

Program2 SHARED Variable1, Variable3, Variable4
Console_Writeline Variable1 ' "Red" is displayed
Variable3 = "Blue"

If simple syntax like that could be impemented flexibly (no restriction on children invoking children of their own), I suspect a lot of significant, character-based ("legacy") systems would move to the thinBasic fold.

I think that would be a very positive move.

Regards,

Peter H. (gungadout)

[gungadout]

Hi Folks,

OK. I'll try to write my own functions in thinBasic to replicate the simplicity found in the majority of business-orientated basics.

However, I still have the problem of suspending a calling program when it fires up another one. In business applications, calling programs often need to wait for results from the programs they invoke. That is why MDI functionality was developed.

Based on the examples kindly provided by Michael Clease, I have tried various experiments. See the code insertions below. (I hope I'm inserting the code properly - I haven't tried this before.)

You can see the various alternatives I have tried. Somehow, I need a way to make Program1 wait until Program2 does its job and terminates.

Program1.tbasic



USES "OS"

DIM AAA AS LONG = 2476
DIM n as long

Msgbox 0, "Program 1 Started"

'OS_ShellExecute("Open", APP_ScriptPath+"\Program2.tbasic", "", "", 0)
'OS_ShellExecute("Open", APP_ScriptPath+"\Program2.tbasic", AAA, "", 1)

'n = OS_ShellExecute("Open", "D:\thinBasic\Program2.tbasic", AAA, "", 0) ' does not suspend Program1
'n = OS_ShellExecute("Open", "D:\thinBasic\Program2.tbasic", AAA, "", 1) ' does not suspend Program1
'n = OS_ShellExecute("Open", "D:\thinBasic\Program2.tbasic", AAA, "", 2) ' does not suspend Program1
'n = OS_ShellExecute("Open", "D:\thinBasic\Program2.tbasic", AAA, "", 3) ' does not suspend Program1
'n = OS_ShellExecute("Open", "D:\thinBasic\Program2.tbasic", AAA, "", 4) ' does not suspend Program1
'n = OS_ShellExecute("Open", "D:\thinBasic\Program2.tbasic", AAA, "", 5) ' does not suspend Program1
'n = OS_ShellExecute("Open", "D:\thinBasic\Program2.tbasic", AAA, "", 6) ' does not suspend Program1
'n = OS_ShellExecute("Open", "D:\thinBasic\Program2.tbasic", AAA, "", 7) ' does not suspend Program1
'n = OS_ShellExecute("Open", "D:\thinBasic\Program2.tbasic", AAA, "", 8) ' does not suspend Program1
'n = OS_ShellExecute("Open", "D:\thinBasic\Program2.tbasic", AAA, "", 9) ' does not suspend Program1

'CALL "D:\thinBasic\Program2.tbasic" ---- only works with internal functions or thinBasic commands, it seems

n = OS_Shell("D:\thinBasic\Program2.tbasic") ' fails to start Program2.tbasic,
' yet typing D:\thinBasic\Program2.tbasic at the command prompt
' in the cmd popup window, works like a charm

Msgbox 0, "Program 1 Back"



Program2.tbasic



USES "OS"
USES "CONSOLE"

DIM NumberOfCommands AS LONG
DIM Count AS LONG


Msgbox 0, "Hello Program 2"


'---Returns the number of commands specified
NumberOfCommands = os_getcommands

'---Show all parameters
FOR Count = 0 TO NumberOfCommands
Console_WriteLine(FORMAT$(Count, "00") & " [" & STR$(os_getcommand(Count)) & "]" & $CRLF)
NEXT

waitkey


All wisdom will be received with gratitude.

Regards,

Peter H. (gungadout)

[Petr Schreiber]

Hi Peter,

thank you for this example, now I see where the problem lies.
In the following I presume Program1.tbasic and Program2.tbasic are in the same directory, I did not hardcoded "D:\.." path as it is DVD drive on my PC.

Problem #1 - launching script in OS_Shell
- Script is executed by thinBasic.exe - thinBASIC installation path is returned by APP_PATH
- It must run in sync mode - lets use OS_Shell parameters


So following is correct:


n = OS_Shell(APP_PATH+"thinbasic.exe "+APP_SourcePath+"Program2.tBasic "+format$(AAA), _
%OS_WNDSTYLE_NORMAL, _
%OS_SHELL_SYNC)


Problem #2 - retrieving parameters
- they start from 1
- on the position #1 there will be always the name of script
- other positions are user defined
- Os_GetCommand returns string, so STR$(Os_GetCommand) is not necessary, even not good idea

So here is working set of Program1 and Program2 for you:
Program1.tBasic


' -- Program 1
USES "OS"

DIM AAA AS LONG = 2476
DIM n as long

Msgbox 0, "Program 1 Started"

n = OS_Shell(APP_PATH+"thinbasic.exe "+APP_SourcePath+"Program2.tBasic "+format$(AAA), _
%OS_WNDSTYLE_NORMAL, _
%OS_SHELL_SYNC)

Msgbox 0, "Program 1 Back"


Program2.tBasic


' -- Program 2
USES "OS"

'---Returns the number of commands specified
DIM NumberOfCommands AS LONG = os_getcommands
DIM Count AS LONG
Dim sString AS STRING = "Hello this is Program 2, parameters ("+format$(NumberOfCommands)+"):"+$CRLF

'---Show all parameters
FOR Count = 1 TO NumberOfCommands
sString += FORMAT$(Count, "00") & " [" & os_getcommand(Count) & "]" & $CRLF
NEXT

msgbox 0, sString


Let me know, I am 99.99% sure it will work.
Do not forget to have scripts in same directory, else you would have to adjust paths.


Petr

[gungadout]

Thanks, Petr.

That works beautifully.

BTW, I've just noticed there's an MDI facility in thinBasic, too. I flashed past it many times on the thinBasic help index while looking for particular instructions, without noticing it. I'll do some homework on that later, out of interest. However, what you've shown me is exactly what I was looking for.

I have a number of other questions queued up, but I'm trying to find the solutions myself before I bother the forum.

Thanks again to all who offered help.

Kind regards,

Peter H. (gungadout)

[Petr Schreiber]

I am happy it worked!

[Michael Clease]

I've been working on a script when time was available to do this and got to where you were petr.

I thought that there was no reason why if I passed the address as a string then pointed a variable at that address in the second script that both scripts could modify its value, this would be the same as a module doing byref ??

I cant seem to get it to work but I dont use pointers very often so it could be me.

[Petr Schreiber]

Hi Michael,

I am hardly expert on Windows memory model, but I think the following rules apply:
- if I have program, and use DLL in it (early or late binding), both modules ("Program" and "DLL") share the memory "pool", so at given address they see the same. That is why BYREF is no problem. (?)

- if I have 2 separate programs, they cannot write/read each other memory, unless hack like memory mapped file (http://community.thinbasic.com/index.php?topic=1778.0) is used.
That is because address is not absolute in terms of whole RAM, but address seems to be process memory "pool" local (???)

[gungadout]

Hi Folks,

I may have found a solution to the FreeFile problem I was having. My testing showed that each new process which started, had to establish its own TCP connection to the database and go through the login process. (There was no way to pass the open connection status between processes.) That was too time consuming.

However, if two conditions can be fulfilled, I might have found something that will work. If I create a thinBasic program that does nothing but TCP communication with the database, and which can be called from multiple other thinBasic programs using OS_Shell, the need to have the TCP connection persist across multiple processes, disappears.

This will work as long as the following two conditions can be made true:

1. The called program can be made to persist (stay alive even if dormant) between calls from other programs. (E.g. the login program asks it to create the TCP connection and then asks it to do some I/O; other programs thereafter ask it to do I/O from time to time on the persisting open connection.

2. The size of the memory-mapped communication areas can be made longer than 1024 bytes. The only efficient way to pass records back to the calling programs seems to be via memory-mapped files. Sometimes the record sizes are in excess of 1024 bytes. My experimenting, using variables other than %FILE1_MAXSIZE and %FILE2_MAXSIZE, has been unsuccessful. (I believe I have matched the sizes in the communicating programs properly.)

Does this sound practical, or am I barking up the wrong tree?

Regards,

Peter H.

[Michael Clease]

1. The called program can be made to persist (stay alive even if dormant) between calls from other programs. (E.g. the login program asks it to create the TCP connection and then asks it to do some I/O; other programs thereafter ask it to do I/O from time to time on the persisting open connection.

2. The size of the memory-mapped communication areas can be made longer than 1024 bytes. The only efficient way to pass records back to the calling programs seems to be via memory-mapped files. Sometimes the record sizes are in excess of 1024 bytes. My experimenting, using variables other than %FILE1_MAXSIZE and %FILE2_MAXSIZE, has been unsuccessful. (I believe I have matched the sizes in the communicating programs properly.)


Q1 - If you use OS_ShellExecute the tcp program will run forever, even if you close the calling script. You could make the communication program a gui that is hidden and get its handle and passes it back to the calling window then get a control id (to a hidden control) passed back as well and use this control (a label?) to control the tcp functions and tell it if the main script has closed.

Q2 - Can we see your program ?

[gungadout]

Hi Folks,

Michael, thanks for your thoughts.

I must confess that the terminology used in "get its handle and passes it back to the calling window then get a control id (to a hidden control) passed back as well and use this control (a label?) to control the tcp functions" escaped me a little. I'll pick the terminology up as I go along.

However, I found that the second problem I was having was related to timing. I had to start the two programs (basically the ones Petr kindly provided), and reactivate the first, within a reasonably narrow time frame for them to work. So that problem is solved.

I've been doing a lot of experimenting based on firing up the second program using OS_ShellExecute instead of starting it manually. The program now fires up OK, and I've been able to establish two-way communication. I've also got the OS_Shell command with the %OS_SHELL_ASYNC option working.



As an extension, I've tried creating both of the memory-resident files (originally featured in Petr's programs) in the calling program. Unfortunately, I have not been successful in establishing communication that way.

Creating both of the memory-resident files just the once in the top-level calling program, would seem sensible for what I wish to do.

This is especially true because the calling sequences will sometimes span multiple hiearchical levels. (E.g. Prog1 calls Prog2 which calls Prog3 which calls prog4, any or all of which could call Prog5, being the shared database I/O function.)

Once again, all wisdom and suggestions will be welcome.



For the convenience of anyone who would like to look, I've attached the calling and called programs (and the include). I have delimited the code changes (the differences between what works to what does not), by '<<< and '>>>. I think I've marked them all.


Regards,

Peter H. (gungadout)

(This is my 3rd attempt to post. I forgot to zip the .inc file first time. It rejected my subsequent attempt to post just the include, even though I used different wording. So I've gone back out and come back in. Fingers crossed.)

[Petr Schreiber]

Hi Peter,

you had there just a little problem in access rights in ProgramIntercomm2Lc.tbasic.

You mapped hMapOut as READ but then you tried to write to it.

The simple fix to this problem is:


hMapOut = OpenFileMapping(%FILE_MAP_WRITE, %FALSE, $FILE2)


Also why wait 5 seconds, when you can detect the program running using WIN_FINDBYTITLE.

So here I copy both program1 and 2 listings, to make sure I did not forget something:


' Program ProgramInterConnect1Lc.tbasic
' Automatically invokes ProgramInterconnectL2c.tbasic
' Create both sending and receiving memory-mapped files, but only place data in the sending file.

Uses "Console", "OS", "UI"

#include "MemoryMappedFile_Minimum.inc"

dim hMapIn as dword
dim pBufIn as dword
dim hMapOut as dword
dim pBufOut as dword
dim Text1 as asciiz * %FILE1_MAXSIZE
dim n AS WORD
dim Reply as string
dim t1 as long

console_setTitle("Program 1")
hMapOut = CreateFileMapping(&h0FFFFFFFF, 0, %PAGE_READWRITE, 0, %FILE1_MAXSIZE, $FILE1)
'<<<
hMapIn = CreateFileMapping(&h0FFFFFFFF, 0, %PAGE_READWRITE, 0, %FILE2_MAXSIZE, $FILE2)
'>>>
n = OS_ShellExecute("Open", "ProgramIntercomm2Lc.tbasic", "", "", 1)
' n = OS_Shell(APP_PATH+"thinbasic.exe "+APP_SourcePath+"ProgramIntercomm2Lc.tBasic ", _
' %OS_WNDSTYLE_NORMAL, _
' %OS_SHELL_ASYNC)
while WIN_FindByTitle("Program 2") = 0
sleep 0
wend
'<<<
'hMapIn = OpenFileMapping(%FILE_MAP_READ, %FALSE, $FILE2)
'>>>
if hMapIn <> 0 and hMapOut then
'<<<
' pBufIn = MapViewOfFile(hMapIn, %FILE_MAP_READ, 0, 0, 0)
pBufIn = MapViewOfFile(hMapIn, %FILE_MAP_READ, 0, 0, %FILE2_MAXSIZE)
'>>>
pBufOut = MapViewOfFile(hMapOut, %FILE_MAP_WRITE, 0, 0, %FILE1_MAXSIZE)
if pBufIn <> 0 and pBufOut <> 0 then
Text1 = "HELLO FROM PROG1. This message is longer than 1024 bytes " & STRING$(1000,"=") & " Yahoo!"
' -- Loads string contents at address of memory mapped file
poke$(asciiz, pBufOut, Text1)

t1 = gettickcount
do
Reply = trim$(PEEK$(asciiz, pBufIn, %FILE2_MAXSIZE))
if LEFT$(Reply,16) = "HELLO FROM PROG2" then
console_printline("-- Program 2 is alive, what a noticable event ( received: "+Reply+" )")
exit do
elseif getTickCount > t1 + 10000 then
console_printline("Oh no, program 2 did not responded even after 10 seconds of waiting... :(")
exit do
endif
loop

UnmapViewOfFile(pBufIn)
UnmapViewOfFile(pBufOut)
else
console_printline("- Could not map view of file")
endif
else
console_printline("- Could not create/open file mapping")
endif

console_printline("Press any key to quit")
CloseHandle(hMapIn)
CloseHandle(hMapOut)
console_waitkey




' Program ProgramInterConnect2Lc.tbasic
' Automatically invoked by program ProgramInterConnect1Lc.tbasic
' Assumes both sending and receiving memory-mapped files are initially created in ProgramInterconnect1Lc.tbasic
' Only the memory-mapped file to be read, is expected to contain data.

Uses "Console"

#include "MemoryMappedFile_Minimum.inc"

dim hMapIn as dword
dim pBufIn as dword
dim hMapOut as dword
dim pBufOut as dword
dim Text2 as asciiz * %FILE2_MAXSIZE
dim Reply as string
dim t1 as long


console_setTitle("Program 2")
console_printLine("Started...")
hMapIn = OpenFileMapping(%FILE_MAP_READ, %FALSE, $FILE1)
'<<<
'hMapOut = CreateFileMapping(&h0FFFFFFFF, 0, %PAGE_READWRITE, 0, %FILE2_MAXSIZE, $FILE2)
hMapOut = OpenFileMapping(%FILE_MAP_WRITE, %FALSE, $FILE2)
'>>>
if hMapIn <> 0 and hMapOut then
pBufIn = MapViewOfFile(hMapIn, %FILE_MAP_READ, 0, 0, 0)
pBufOut = MapViewOfFile(hMapOut, %FILE_MAP_WRITE, 0, 0, %FILE2_MAXSIZE)
if pBufIn <> 0 and pBufOut <> 0 then

Text2 = "HELLO FROM PROG2. This message is longer than 1024 bytes " & STRING$(1000,"-") & " NineMSN!"

t1 = gettickcount
do
Reply = trim$(PEEK$(asciiz, pBufIn, %FILE1_MAXSIZE))

if LEFT$(Reply,16) = "HELLO FROM PROG1" then
console_printline("-- Program 1 is alive, I will send him HELLO too ( received: "+Reply+" )")
POKE$(asciiz, pBufOut, Text2 )
exit do
elseif getTickCount > t1 + 10000 then
console_printline("Oh no, program 1 did not responded even after 10 seconds of waiting... :(")
exit do
endif
loop


UnmapViewOfFile(pBufIn)
UnmapViewOfFile(pBufOut)
else
console_printline("- Could not map view of file")
endif
else
console_printline("- Could not create/open file mapping")
endif

console_printline("Press any key to quit")
CloseHandle(hMapIn)
CloseHandle(hMapOut)

console_waitkey



Petr

[gungadout]

Hi Petr,

Thanks for your help.

I did not know about WIN_FINDBYTITLE. If it is in the sample scripts, I missed it. There's so much I know I need to learn.

It's getting late here now, so I'll pursue this tomorrow.

Thanks again and Regards,

Peter H. (gungadout)

[gungadout]

Hi Petr,

Thanks again for your help. Your changes were spot on.

I need to ask a few more things.


First of all, my next version of ProgramInterConnect2Lc.tbasic (or equivalent) needs to stay in place, waiting for requests to be received in pBufIn.

The program needs to inspect pBufIn in a loop, or else wait for some kind of interrupt before looking again.

If a loop is required, ProgramInterConnect2Lc.tbasic needs to be able to write say, blanks into the first part of pBufIn. If the contents remain unchanged, the original request will still be there when the program loops, and the request will be actioned again.

Is there an &H number which could be used to evaluate a %FILE_MAP_READ_WRITE variable? I've tried the following type of logic, but pBufIn retains its original value.



dim hMapIn1 as dword
dim hMapOut1 as dword
dim hMapOut2 as dword

dim pBufIn1 as dword
dim pBufOut1 as dword
dim pBufOut2 as dword

dim ReplyToSend as asciiz * %FILE2_MAXSIZE
dim RequestArea as asciiz * %FILE1_MAXSIZE
.
.
hMapIn1 = OpenFileMapping(%FILE_MAP_READ, %FALSE, $FILE1)
hMapOut1 = OpenFileMapping(%FILE_MAP_WRITE, %FALSE, $FILE1)
hMapOut2 = OpenFileMapping(%FILE_MAP_WRITE, %FALSE, $FILE2)
.
.
do
RequestReceived = trim$(PEEK$(asciiz, pBufIn1, %FILE1_MAXSIZE))
Request = PARSE$(RequestReceived, zAM, 1)

IF Request = "CONNECT" THEN
ConnectAndLogin()
RequestArea = " "
POKE$(asciiz, pBufOut1, RequestArea) ' this appears not to change the contents of FILE1.
POKE$(asciiz, pBufOut2, ReplyToSend) ' this returns the value "Ready for I-O" to the invoking program OK.
END IF
.
.
FUNCTION ConnectAndLogin()
ReplyToSend = "Ready for I-O"
END FUNCTION



Secondly, if I'm using the construction



while WIN_FindByTitle("TcpIoControlMVB") = 0
sleep 0
wend


I know I can use Console_SetTitle to name a console program and WIN_SetTitle to name a window program. I assume the latter will work with any .tbasic program, even if the program does not display anything. Am I correct?

Also, in the Win_SetTitle(hWnd, WinTitle) statement, I am unsure how to obtain the hWnd variable.

Please point me in the right direction.

Thanks in advance,

Peter H. (gungadout)

[Petr Schreiber]

Hi Peter,

regarding communication, I would recommend to have some "acknowledge" channel (extra file).
That means - once program receives "message" in inBuffer, it would set some special file contents to "READY" once ready and "BUSY" is processing request.

To find application which has no specific window title, I have not much experience in this area so I am sorry but with this I cannot help.

-> Win_SetTitle(hWnd, WinTitle)
... hWnd means "handle of window" and it is unique identifier of window.

You can receive it like:
hWnd = WIN_FindByTitle("TcpIoControlMVB")
or
hWnd = WIN_GetForeground

... or simply using any function which returns window handle. Handle variable should be of DWORD or LONG datatype.

-> %FILE_MAP_READ_WRITE
I think the following could do the job (but never used it):
%FILE_MAP_ALL_ACCESS = &h0F001F

I hope it helps,
Petr

[peter]

Hi,

I was saying already, not Peter rather PeterH.
Why is it so unfriendly in this forum?
I think always that this writing is for me!
I was at first here!

Regards
Peter

[Petr Schreiber]

ALIAS User.peter AS peter
ALIAS User.gungadout AS Peter

Hi peter,

well, as our parents did not named us using GUID ( I always wanted to be called {01E36124-4665-4B93-8CE5-BE34873A212E} ), it happens from time to time people with the same name appear.

And as there was only one Peter asking a question in this thread, I found it natural to name him like that, as there was no need to differentiate ... until your last post which doubled the number of Peters in this thread.

In case our two Michaels, Clease and Hartlef, appear in same post, I use differentiation mechanism to avoid confusion, in other cases it seems little bit redundant to me.

I hope you can understand. I think using just first name is more friendly, using complete name is not common in communication, looks odd and "official".


Petr

[Petr Schreiber]

Peter,

I am afraid my advice with all access does not solve the issue, studying MSDN (http://msdn.microsoft.com/en-us/library/aa366761%28VS.85%29.aspx) gave me following information:


FILE_MAP_ALL_ACCESS
A read/write view of the file is mapped. The file mapping object must have been created with PAGE_READWRITE or PAGE_EXECUTE_READWRITE protection.

When used with the MapViewOfFile function, FILE_MAP_ALL_ACCESS is equivalent to FILE_MAP_WRITE.


So you will need one file for reading and another for writing. I am sorry.


Petr

[peter]

Okay, if you mean that.

[gungadout]

Hi Petr,

Thanks for doing the homework on my behalf. I wouldn't have known where to start.

I'll try to find a work-around.

Regards,

Peter H. (gungadout)

[ErosOlmi]

Hi gungadout,

I'm sorry I was not able to help on this matter because I was out for holidays.
I've bookmarked this thread and will go though next days trying to see if I can help in some way.

Anyway, in general 2 thinBasic scripts running at the same time are executed by two separated thinBasic process. Every process has its own virtual memory space (around 2Gb each) and that space cannot be shared with other process (whatever they are). Every process memory mapping addresses are logical and not physical. It is the operating system that handle and protect this memory schema. For this reasons it is not possible to share variables between 2 different thinBasic applications.

The same apply if we create a common DLL that is loaded by the two different thinBasic process simultaneously. Image of the DLL is loaded just once by the operating system but each process creates its own distinct data.

I do not think that there are other programming languages able to generate applications that can exchange memory areas while executing in different process, at least under 32bit Win OS.

Of course there can be some work around to this situation:

memory mapping files
disk files
a personalized Tcp/Udp protocol in place by the two (or more) process
an application developed as system service that act as glue
merge the two separated applications in one single application that does the job of the two
consider a programming language able to create different threads (thinBasic can just create single thread scripts).
Every thread can do its won job but because they are in the same process they share the same virtual memory
... some other tricks ...


I will try to help more when I will have some spare time to better read all posts in this thread and understand what you want to achieve.
I'm quite intrigued by your needs and I've the feeling I can produce something that can help you and others.

Ciao
Eros

[gungadout]

Hi Folks,

(Eros: thanks for your input. I read your post after I'd written most of my post below, and your post might have already answered some of my questions in the negative. But I'll post the questions anyway.)

I've been looking into the MDI functionality as a potential solution.

Three questions have popped up in this regard.

Q1. Every example I've found of MDI usage in thinBasic so far, carries the comment "Must be MODELESS dialog without a message loop". I need to use the MDI feature in both modal and modeless fashion. Is that possible, and if so, are there examples I have missed?

Q2. In every example I've found of MDI usage in thinBasic so far, the logic for the parent form and the logic for the child forms are embedded in the one thinBasic program. I need the functionality found in VB, where each form is a separate program, yet the forms link together seamlessly in the MDI environment. Once again, have I missed some thinBasic examples?

Q3. In VB, passing data back to the parent program from a child program is achieved without using user-defined memory-mapped files. Is this possible in thinBasic? (The question assumes that independent MDI parent and child programs can be created).



An example of my thoughts can be found in the "Return Value From Modal Form Demo" at URL http://www.mvps.org/vbvision/Sample_Projects.htm. The example is written in VB5, so the functionality has been around for some time.


I realise that once again I might be coming at thinBasic from an unusual direction, but what I'm trying to do is find a way to replicate functionality that is inherent in other environments.

I like the look of thinBasic, which is why I am persevering and hoping that a solution can be found.


Thanks in advance for all feedback, and repeated thanks for all the help so far.

Regards,

Peter H. (gungadout)

[ErosOlmi]

gungadout

regarding thinBasic MDI functionality it was introduced not much time ago. Maybe some options are missing but I think you can do all what you need with it.

To be sure we are aligned, be sure to have latest thinBasic beta installed. You can get it from there: http://community.thinbasic.com/index.php?topic=2588.0
This version has the latest so far updated/fixed features

After that, you can find some MDI script test in directory \thinBasic\SampleScripts\UI\MDI\



Q1. Every example I've found of MDI usage in thinBasic so far, carries the comment "Must be MODELESS dialog without a message loop". I need to use the MDI feature in both modal and modeless fashion. Is that possible, and if so, are there examples I have missed?

Of course it is possible to have modal and modeless dialogs and each with its callback function to handle events but you must be aware that when you show a dialog in modal way it stop program execution till dialog is destroyed while modeless dialogs con exists, operate and their callback function works simultaneously. Usually a MDI child is always created in modeless way. Modal show is reserved to message box, configuration windows or more in general to windows that must be sure user cannot avoid to confirm.



Q2. In every example I've found of MDI usage in thinBasic so far, the logic for the parent form and the logic for the child forms are embedded in the one thinBasic program. I need the functionality found in VB, where each form is a separate program, yet the forms link together seamlessly in the MDI environment. Once again, have I missed some thinBasic examples?

We have to agree about terms: program, process. A program is a single executable on disk. When it executes, it creates a process. More execution of the same program creates different processes unless the program is programmed in such a way that it recognize it is already running so when executed the second time it just pass some info to the first process and stop.

Is it possible to have two different process and the second one inject a MDI child window into the MDI parent window of the first one. It is just a matter of windows handlers. But this situation is quite complex to manage and will sure create many problems.



Q3. In VB, passing data back to the parent program from a child program is achieved without using user-defined memory-mapped files. Is this possible in thinBasic? (The question assumes that independent MDI parent and child programs can be created).

Yes, sure. I will prepare an example in few days.



An example of my thoughts can be found in the "Return Value From Modal Form Demo" at URL http://www.mvps.org/vbvision/Sample_Projects.htm. The example is written in VB5, so the functionality has been around for some time.

At first sight it seems just a window creating a second dialog box getting few data back. And this is quite simple to achieve.
Anyway, I will check it in next days and prepare an example.

Sorry I cannot help immediately but today I restarted my real life job and I can only work on thinBasic during spare time or night (CET time)

Ciao
Eros

[gungadout]

Hi Eros,

Thanks for your continuing interest.

I look forward to seeing the examples whenever you have a chance to prepare them.

Regards,

Peter H. (gungadout)

[ErosOlmi]

It is a pleasure if I can help.

Requests like yours let me understand if there are problems or if some functionality is missing.
People feedback and listening to problems/requests is the best way I have to improve thinBasic the level I would like to bring it.

Sometimes I can help quite quickly, sometimes I have to ask to way a little. But be sure I will try my best.

Ciao
Eros

[ErosOlmi]

Ok, I had a chance to look at the mentioned VB example.

That example does not have anything to share with MDI window concept but it is just a main dialog (form) that pass some data to a modal second dialog and waits for data to return. I've tryed to replicate the same code as close as possible.

Attached to this post you can find thinBasic source code script.

Let me know if I missed something.

Ciao
Eros

[gungadout]

Hi Eros,

This has turned out to be a long post. Sorry. I've tried to be concise.

---------------------------------------------------

Your reply and example (appreciated) confirmed something I had suspected for a while (and I think others tried to tell me).

I had seen a number of examples featuring multiple "screens" which shared data flexibly. Each example had all the related screens coded into the one thinBasic program. Traditionally, other non-Windows environments would have allowed them to be independent programs.

I did some more homework on the Windows environment. I found that apparently independent forms in say, VB, must be compiled together into the one .exe or .dll to be able to share data.

It finally sank in that flexible, dynamic data sharing, such as is available in other environments, is not available in the Windows environment at all.

(Being someone who is accustomed to seeing that functionality as a fundamental feature, I found it difficult to grasp that an advanced operating system like Windows could be so deficient in that respect.)


Therefore, I perceive that I have two possible approaches with respect to developing systems which have a large number of interacting screens and background functions:
- code them all into the one thinBasic program (with "independent" screens etc. possibly being built as includes for the main control program);
- code them as truly independent programs, and (reverse-)communicate via the memory-mapped files technique that Petr (and possibly others) showed me.

Each of the above approaches has generated its own questions, which I probably need to address before deciding on which approach to adopt.

---------------------------------------------------

Approach 1 - Code everything into the one "ginormous" program.

Q1. What is the maximum practical size of a thinBasic program? Information of relevance could include:
- a reasonably sized system may have hundreds of screens, some with complex coding;
- such screens can have up to (and even over) 1,000 lines of code each;
- it appears that at times, thinBasic (VB too) takes multiple lines of code to achieve what takes 1 line of code in other environments.

Q2. What would the effect be on the loading speed, and on the execution speed, of such a humungous program?

---------------------------------------------------

Approach 2 - Code each screen separately and use memory-mapped files for inter-communication.

Q1. The only question I can quantify at the moment relates to a shared TCP communication function (process). It establishes the FreeFile connection when first invoked, then sends data streams to the database on request and receives data in return. It has to be stand-alone because it is shared by many screens. It uses a memory-mapped file to ferry data back to the requesting screens.

Hopefully there is a way for that process to make itself dormant, but remain memory-resident, until the next screen requests its services. If someone has shown me how to do that already, I plead idiocy and request clemency, because I missed it. I also missed it in the examples, if it is there.

I know how to invoke the TCP communication function initially. I am unsure how to get that process to make itself dormant. I am also unsure how to wake the process up to service subsequent requests.

Also, each request to the TCP communication process has to act modally - the invoking process has to wait for the returned data prior to continuing its execution. The TCP comms process itself has to be modeless, because it has to remain alive between service requests made upon it. I am unsure how to achieve that.

(If the invoking process (or the TCP process) goes into a hard loop checking its inward memory-mapped buffer, that would be detrimental to performance. If the process checks that buffer in a delayed loop (SLEEP milliseconds), overall perfomance would also be impacted negatively.)

---------------------------------------------------

I hope I'm not trying to apply thinBasic beyond its reasonable limits. I believe that thinBasic has the potential to gain significant recognition, including the area of porting "legacy systems" to the Windows environment. (There are a lot of "legacy systems" out there that service their companies much better than modern "ERP" systems possibly could. They just look tired and unimpressive because of their "green screen" technology.)

As I see it, We just need to nail this one issue down. I hope we can.


Regards, and thanks again for your help.

Peter H. (gungadout)

[ErosOlmi]

Hi gungadout,

In general, I will never say thinBasic (or other programming languages) can do all. My job is handling a team of people to manage IT stuff of the company I work for. Every day I take decision on what is the best environment when to develop a solution and we have not found so far a single environment able to be used all the time. So I appreciate a lot your "questions before go". You have to understand if thinBasic (or other environments) can do the job and you are making very pertinent questions.



I did some more homework on the Windows environment. I found that apparently independent forms in say, VB, must be compiled together into the one .exe or .dll to be able to share data.
It finally sank in that flexible, dynamic data sharing, such as is available in other environments, is not available in the Windows environment at all.

In the past (Win95, Win98 and in general 16 bits environment) single memory handling model was the cause of absolute instability of the OS: one single bad written application would have crash the entire system. With current OSs, memory is not anymore shared but virtualized. Every process is like to be on a sandbox and (generally speaking) talks only to the OS. When a process crash the OS is able to release its virtual space and the OS continue to work. Do you want to go back? I suppose not. So different approaches as to be found.



(Being someone who is accustomed to seeing that functionality as a fundamental feature, I found it difficult to grasp that an advanced operating system like Windows could be so deficient in that respect.)

I can understand. In the past I was used to program the same way.
But at that time this approach was used due to the limitation of the OS (16 bit) and the fact that memory was to little so programming environments found a way (if I remember it was called CHAIN by many languages) to free one program from memory (leaving some common shared variables) and CHAIN to the other. In my company we still use some applications acting in that way (DOS applicatrions).
I do not know what dev. environment are still working in this way so far. If you can give some that is already under maintenance/development, I can try to understand more.




Therefore, I perceive that I have two possible approaches with respect to developing systems which have a large number of interacting screens and background functions:
- code them all into the one thinBasic program (with "independent" screens etc. possibly being built as includes for the main control program);
- code them as truly independent programs, and (reverse-)communicate via the memory-mapped files technique that Petr (and possibly others) showed me.

There are some other techniques (I've tried to list some in my previous post) but all depends on what you have to do.





Approach 1 - Code everything into the one "ginormous" program.

Q1. What is the maximum practical size of a thinBasic program? Information of relevance could include:
- a reasonably sized system may have hundreds of screens, some with complex coding;
- such screens can have up to (and even over) 1,000 lines of code each;

As far as I know the biggest source code I've see developed in thinBasic is TAB from catventure user. It is a single source code file of around 12000 lines of code. Its execution is almost immediate. I have personally tested scripts to up 35000 lines of code and again execution is quite fast even if interpreted (less than 1 second to start on a Core Duo cpu)




- it appears that at times, thinBasic (VB too) takes multiple lines of code to achieve what takes 1 line of code in other environments.

This is something I'm very interested because I was thinking exactly the contrary. If you can give me a compare environment I can check
But it depends on what you compare. thinBasic is full text environment (you have to code all), VB is a visual designer (you mainly drag visual elements and than code). Personally I can be proud to see thinBasic compared to VB but honestly you cannot compare them so directly.
Can you list some examples of 1 line of code in other environments go into multiple lines of thinBasic?




Q2. What would the effect be on the loading speed, and on the execution speed, of such a humungous program?

See above reply on script size.


---------------------------------------------------



Approach 2 - Code each screen separately and use memory-mapped files for inter-communication.

That is not the only one method you can think about.



Q1. The only question I can quantify at the moment relates to a shared TCP communication function (process). It establishes the FreeFile connection when first invoked, then sends data streams to the database on request and receives data in return. It has to be stand-alone because it is shared by many screens. It uses a memory-mapped file to ferry data back to the requesting screens.

Hopefully there is a way for that process to make itself dormant, but remain memory-resident, until the next screen requests its services. If someone has shown me how to do that already, I plead idiocy and request clemency, because I missed it. I also missed it in the examples, if it is there.

I know how to invoke the TCP communication function initially. I am unsure how to get that process to make itself dormant. I am also unsure how to wake the process up to service subsequent requests.

Also, each request to the TCP communication process has to act modally - the invoking process has to wait for the returned data prior to continuing its execution. The TCP comms process itself has to be modeless, because it has to remain alive between service requests made upon it. I am unsure how to achieve that.

(If the invoking process (or the TCP process) goes into a hard loop checking its inward memory-mapped buffer, that would be detrimental to performance. If the process checks that buffer in a delayed loop (SLEEP milliseconds), overall perfomance would also be impacted negatively.)

Do not know if it can help but you can find a TCP example under \thinBasic\SampleScripts\TcpUdp\
See file "UDP_Notify_Client.tbasic" and "UDP_Notify_Server.tbasic".
Run the Server and click on "I'm a Server"
Run one client and click on "Find server"
Than move around client window. It will communicate with server telling it to move too.
Run more client and do the same.
...it is just an example on the many tcp/udp way you can find to create a personalized protocol.




I hope I'm not trying to apply thinBasic beyond its reasonable limits. I believe that thinBasic has the potential to gain significant recognition, including the area of porting "legacy systems" to the Windows environment. (There are a lot of "legacy systems" out there that service their companies much better than modern "ERP" systems possibly could. They just look tired and unimpressive because of their "green screen" technology.)

Thanks for your word. We are trying to improve it every day also thanks to the help of many people here.
Of course thinBasic has many limits for the field you are asking for. The fact that it is interpreted in for sure a limit for what you are trying to achieve.
I'm quite in the field of ERP. I've been an SAP consultant for 2 years. I'm in the middle of an ERP software selection (SAP, Dynamics, Oracle) so I quite well know what you are talking about. Also consider in my company we still program using DOS environment: a language called CBasic that translates to C and compile under Turbo C 2.0, so something around in 1990 or so.


As a last indication about thinBasic that can help you to take a decision: thinBasic is a modular language.
It means it is not limited to what we develop but you can extend it developing your own compiled modules.
thinBasic as a set of SDK that let everyone create personalized or dedicated compiled modules that add new functionalities to the language. If you have already a lot of code, you can think to translate some code into modules that add new functionalities to thinBAsic language and than call that module functions from your scripts. All thinBasic modules are done in this way.


Hope I was able to reply to some of your doubts.

Eros

[Charles Pegge]

Hi Peter,

This is an interesting subject. - Multitasking with a mix of persistent and transient activities.

A looping structure is inevitable but this need not be inefficient if each cycle is triggered by a windows WM_TIMER message. You can service any number of activities by setting up a functions for each of them. and invoke them all on the timer event cycle.

I have found it is also very easy to create Dialogs and then controls inside dialogs on the fly. Then delete them when no longer required. The dynamic formation of dialogs gives you great flexibility.

So no need to think about running separate processes at the OS level.

Charles

[gungadout]

Hi Folks,

Thank you (in reverse order of recent help offered) Charles, Eros and Petr. I appreciate your willingness and endeavours to help.

Charles, your ideas sound interesting, but I haven't the background to even start to try coding what you've suggested. Are there any samples in existence that I could use as a basis for understanding?

I've attached a description of the type of environment and interaction I'm looking at, in case it may help focus your thought processes in what might be a more general area.

Once again, a big thank you to all who have contributed.

Regards,

Peter H> (gungadout)

[Charles Pegge]

Hi Peter H,

This is a play piece exploring the ideas I was referring to. There is no TCP in it but the main dialog represents an enduring process. You will find one of the buttons invokes a modeless second dialog which has access to many of the state variables of the main dialog while this continues to run in the background. For simplicity I am using global variables but these could be better encapsulated in a more developed environment.

The second (child) dialog is almost empty at present but I'll be putting in various controls shortly - mostly edit boxes. You will see that it has its own message processing system and has almost te same capabilities as its parent. This is very much a learning process for me but I think it has the essential properties you are looking for.

Charles

PS: The windows timer event ensures that the program executes very efficiently - the PC is never kept waiting in a redundant loop.


http://community.thinbasic.com/index.php?topic=2890.0

[gungadout]

Hi Folks,

It's been a while, but I haven't actually gone away. thinBasic still has my attention.

First of all, thank you Charles (Pegge) for your most recent suggestion.

Secondly, I believe I am probably constrained to use discrete thinBasic processes because the system I am considering has:
- 1,218 distinct programs;
- 583,640 lines of source code;
- 21,218,905 bytes of source code.

I not really sure that that would practically fit into the one thinBasic process. There may also be security issues.

I've been doing some homework, and might have found something.

I have tracked down a number of links with samples of inter-process communication, on the web.

The attached document contains one link which could be relevent, and another link just in case.

(I'm hoping one or more of the techniques used might be adaptable to the thinBasic environment.)

It also contains a diagram of the environment I need to replicate, as well as a few important considerations.

I'd appreciate a few people having a look at the document, and checking major link in case there are one or two gems there.

If it turns out to be old hat, I apologize in advance for time wasting.

Regards,

Peter H. (gungadout)

[ErosOlmi]

Peter,

sorry for the delay in replying to your post.

I've see your document and I've now an idea of what you are trying to do. It is a very interesting challenge, those challenges I really like.
But to be realistic (and 100% honest with you), what you need seem too complex to be developed using thinBasic or any other programming language like thinBasic, I mean interpreted and single threaded.
Maybe some parts can even be done but I'm quite sure that as soon as the project goes on, if you go with something like thinBasic you will face unsurmountable problems.

To me the way to go is something like .Net languages (any) or Java. And this can be more true if you consider that a project like that needs skilled people so it would be easier to find them if you go with a well known tool.

That said, as soon as I will start thinBasic 2.x development line I will come back to this post because a fast inter process communication module specific for thinBasic is something I'm very interested to add to thinBasic arsenal and something that can bring more power to thinBasic applications.

Thank a lot for your professional posts and requests.
Eros

[gungadout]

Hi Eros,

Thanks for your continuing interest and your comments.

One of the potential advantages of thinBasic that I see, is greater compatibility between releases than exists between releases of VB.NET. If one is planning to automatically convert programs from one environment to another, stability and inter-release compatibility in the target environment is of paramount importance.

I'm looking forward to seeing what you manage to include in thinBasic 2.x. Preserved backwards compatibility is one of my hopes.

(If we can handle the I/O to the database, as per my diagram, efficiently, thinBasic will warrant my continued attention, and I'll move onto the next challenge - emulating some other functionality that is inherent in advanced legacy systems, but difficult to achieve in VB.NET.)

Regards,

Peter H. (gungadout)