Author |
Topic: Passing info between programs (Read 2165 times) |
|
Alincon
Full Member
member is offline
Posts: 147
|
 |
Re: Passing info between programs
« Reply #4 on: Feb 13th, 2015, 4:09pm » |
|
I was thinking more of calling a program that does a common task and sends back the result. I have one that is called from programs that need standard state abbreviations. It presents a list box of State names and returns the corresponding abbreviation for the chosen state.
I have another called program that verifies login and password.
The calling program sends a name, the called program requests log in and password, and returns pass/fail.
In the second case using the clipboard might compromise security.
Using a common file might require timing to ensure the called program has finished before the calling program tries to use the requested data.
r.m.
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Passing info between programs
« Reply #5 on: Feb 13th, 2015, 5:27pm » |
|
on Feb 13th, 2015, 4:09pm, Alincon wrote:| I was thinking more of calling a program that does a common task and sends back the result. |
|
I would have thought the 'standard' way of doing that (in general, unrelated to LB/LBB) is to use files. The vast majority of data processing and conversion programs I use take their input from one file and send their output to another file.
Apart from being such a commonplace method, using files for input and output may make it easier to debug because you can examine the files afterwards. I can't see any benefit in 'reinventing the wheel'.
Richard.
|
|
Logged
|
|
|
|
Phineas Freak
New Member
member is offline
Gender: 
Posts: 18
|
|
Re: Passing info between programs
« Reply #6 on: Feb 14th, 2015, 08:26am » |
|
Take a look at the Memory Mapped Files demo from LBPE. You can probably transfer any kind of data between two or more program instances and without writting to the hard drive.
Note: I compliled it under linux. It runs but you cannot run a second instance and when you try to change the data on the first instance it complains about a "type mismatch". Commenting this line:
Code:g.caption$ = "Local string = " + str$(Shared.strVar.struct)
allows the first instance to change the data but i had no luck running a second instance to fully test it :-[ .
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Passing info between programs
« Reply #7 on: Feb 14th, 2015, 10:14am » |
|
on Feb 14th, 2015, 08:26am, PreciseTiming wrote:| Take a look at the Memory Mapped Files demo from LBPE. |
|
Memory-mapped files (more accurately called 'shared memory' in this context) have the issue that I mentioned before: they are ideal for transferring a state but problematical for transferring a data stream. At least the communication is bi-directional so it would be possible to devise some kind of handshaking protocol.
Incidentally I think the code at LBPE is over-complicated. Whenever I've used shared memory (in BBC BASIC, I've never tried it in Liberty BASIC) I've not found it necessary to use the map-copy-unmap sequence for each transaction as recommended there. Leaving the structure mapped for the entire duration of the program has always worked for me:
http://bb4w.wikispaces.com/Sharing+a+structure+between+processes
Richard.
|
|
Logged
|
|
|
|
Alincon
Full Member
member is offline
Posts: 147
|
|
Re: Passing info between programs
« Reply #8 on: Feb 21st, 2015, 11:45pm » |
|
I have succeeded in passing information between programs by using a small file. My small file is sequential, not random, but it works.
I had concerns about this quote from the LB4 help file:
"Execution of an external program does not cause the calling Liberty BASIC program to cease executing."
But, at least in my case, it appears that the calling program does wait for the called .tkn program to finish.
r.m.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Passing info between programs
« Reply #9 on: Feb 22nd, 2015, 07:04am » |
|
on Feb 21st, 2015, 11:45pm, Alincon wrote:| But, at least in my case, it appears that the calling program does wait for the called .tkn program to finish. |
|
Sounds very risky to me. The RUN statement definitely doesn't wait; on a single-core CPU it may be a few milliseconds before it returns but you can't rely on it.
You say '.TKN'; was this using LB4 or LBB? In LBB you would need to use the WAIT qualifier to the RUN command.
Richard.
|
|
|
|
Alincon
Full Member
member is offline
Posts: 147
|
|
Re: Passing info between programs
« Reply #10 on: Feb 22nd, 2015, 12:31pm » |
|
Here's my code:
Code:
run "c:\libbas\_mylibbas\personnel\lookupNames.tkn ";"*.sal"
open "C:\libbas\_mylibbas\personnel\fileNamePass.txt" for input as #pnt
input #pnt, fileName$
close #pnt
The calling program passes a file type (via command line), and, presto! the file name is immediately available in the common file.
The called program fills an array for a list box and when the user makes a selection, passes back a file name.
Why would this be risky?
BTW: Is there any advantage in using a random file?
r.m.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Passing info between programs
« Reply #11 on: Feb 22nd, 2015, 1:08pm » |
|
on Feb 22nd, 2015, 12:31pm, Alincon wrote:
It's risky because if the file fileNamePass.txt is being created by the program lookupNames.tkn there's no reason at all to expect the file to have already been created when the RUN command returns.
The RUN command simply 'launches' the external program; then both that program and yours run concurrently. The degree of concurrency is of course dependent on your PC's architecture: if you have two or more CPU cores the programs may well be running literally simultaneously. If you have only one core they will be time-shared by Windows, but that is out of your control. Either way, the file may be created some time after the RUN command has returned.
But anyway this is evidently not LBB code ('RUN lookupNames.tkn' cannot work in LBB, unless you've associated the TKN extension with run404.exe), so you may want to raise the issue on one of the Liberty BASIC support forums.
Incidentally the ' ";" ' in your command string achieves nothing; you might as well (and more simply) use:
Code: run "c:\libbas\_mylibbas\personnel\lookupNames.tkn *.sal"
Richard.
|
|
Logged
|
|
|
|
Alincon
Full Member
member is offline
Posts: 147
|
|
Re: Passing info between programs
« Reply #12 on: Feb 23rd, 2015, 5:55pm » |
|
Chris Iverson (on the LB msg board) says my code works for .tkn, but it won't work for .exe. That makes sense to me.
r.m.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Passing info between programs
« Reply #13 on: Feb 23rd, 2015, 6:43pm » |
|
on Feb 23rd, 2015, 5:55pm, Alincon wrote:| Chris Iverson (on the LB msg board) says my code works for .tkn, but it won't work for .exe. |
|
He seems to think that a TKN is run not as an 'external' program at all, but using the same runtime engine as the calling program. That may be true but AFAIK it's a completely undocumented feature. I wouldn't want to rely on it.
Certainly, LBB doesn't have a comparable capability (it could do in principle, but as it's so easy to compile a sub-program to a compact EXE you might just as well run it as a 'proper' external program). I could easily add a wait option to LBB's RUN command if that would be helpful*.
One thing I don't understand is why you're calling a sub-program at all. If it's also written in Liberty BASIC, why isn't it just implemented as a subroutine (in LBB it could be an 'included' library subroutine)?
*Edit: I've decided that I will add a wait option to the RUN statement in the next release of LBB. This will be mutually exclusive with the other modes (so you won't be able to wait and hide).
Richard.
|
|
|
|
Alincon
Full Member
member is offline
Posts: 147
|
|
Re: Passing info between programs
« Reply #14 on: Feb 24th, 2015, 12:01am » |
|
As to 'including', instead of 'calling', I guess I'm still thinking in LB4 terms; I chose calling because more than one program calls the routine
Thanks for offering to add a wait option to the run command, but if I'm the only one requesting it...
r.m.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Passing info between programs
« Reply #15 on: Feb 24th, 2015, 08:15am » |
|
on Feb 24th, 2015, 12:01am, Alincon wrote:| Thanks for offering to add a wait option to the run command, but if I'm the only one requesting it... |
|
I'm not adding it for you, I'm adding it because I think it's a good idea (it's only doing internally what the 'cheat' code I listed does anyway, so it's just syntactic sugar).
Richard.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Passing info between programs
« Reply #16 on: Feb 24th, 2015, 4:23pm » |
|
Richard, thank you for adding good stuff just because it's a good idea.
|
|
Logged
|
|
|
|
Alincon
Full Member
member is offline
Posts: 147
|
|
Re: Passing info between programs
« Reply #17 on: Feb 25th, 2015, 11:24pm » |
|
I want to try the LBB approach of 'including' sub-programs instead of calling them. What I get is a "type mismatch" error message.
the called sub-program:
Code:
function lookUpName$(typ$)
files deptPath$, info$(
fc = val(info$(0, 1)) ' folder count
for cf = 1 to fc
foldName$ = info$(cf, 0)
files foldName$, info2$(
fc2 = val(info2$(0,1))
for cf2 = 1 to fc2
fold2Name$ = info2$(cf2,0)
files fold2Name$, typ$, info3$(
fc3 = val(info3$(0,0)) 'file count
for cf3 = 1 to fc3
x$ = info3$(cf3,0)
if (right$(x$,3) = "sal" or right$(x$,3) = "hly") then
y$ = getFldr$(foldName$)
z$ = getFldr$(fold2Name$)
n = n + 1
emps$(n) = tb$(x$,28) + y$ +"\"+ z$ + "\"
end if
next cf3
next cf2
next cf
WindowWidth = 220: WindowHeight = 400
BackgroundColor$ = "cyan"
ListboxColor$ = "cyan"
statictext #elist.st1, "Employees", 60,5,55,20
listbox #elist.lb1, emps$(,[getEmp],2,24,217,375
Stylebits #elist.lb1, 0, _LBS_DISABLENOSCROLL, 0, 0
button #elist.btn1, "X", [noSelect],UL, 195,2,20,20
open "Employee List" for window_popup as #elist
#elist, "trapclose [empsClose]"
#elist, "font consolas 9"
#elist.lb1, "singleclickselect"
sort emps$(,1,n
#elist.lb1, "reload"
wait
[getEmp]
#elist.lb1, "selection? emp$"
fileName$ = deptPath$ +"\"+ mid$(emp$,29) + left$(emp$,28) ' 28 is forced length of emp name
goto [empsClose]
[noSelect]
fileName$ = "none"
[empsClose]
lookUpName$ = fileName$
close #elist
end function
the calling program (including old run statement, etc)
Code:
' run "c:\libbas\_mylibbas\personnel\tokens\lookupNames.tkn ";"*.sal"
' open "C:\libbas\_mylibbas\personnel\fileNamePass.txt" for input as #pnt
' input #pnt, fileName$
' close #pnt
fileName$ = lookUpName$("*.*") ' the error line
if fileName$ = "none" then wait
goto [getCommon]
and the 'include statement (starting in col 1)
Code:
'include lookupNamesIncl.bas
r.m.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Passing info between programs
« Reply #18 on: Feb 26th, 2015, 08:56am » |
|
on Feb 25th, 2015, 11:24pm, Alincon wrote:| I want to try the LBB approach of 'including' sub-programs instead of calling them. What I get is a "type mismatch" error message. |
|
It works for me. A 'Type mismatch' error is what you would get if the included file was not found since, in the absence of the FUNCTION definition, lookUpName$( looks like an array!
So, check that the included file has the correct name and that it is stored in the same directory as the calling program.
I deliberately arranged that 'include doesn't throw an error if the file isn't found, in case a program happened to have a 'regular' comment line starting with the word include. However that does mean that you can get an 'unexpected' error (such as your 'Type mismatch') rather than a more straightforward 'Include file not found'.
Richard.
|
|
|
|
|
