Author |
Topic: Passing info between programs (Read 2168 times) |
|
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.
|
|
|
|
Alincon
Full Member
member is offline
Posts: 147
|
|
Re: Passing info between programs
« Reply #19 on: Feb 26th, 2015, 7:26pm » |
|
I figured that 'type mismatch' was not the real problem.
The included code now executes w/o an error message, but the listbox that the code is supposed to fill is empty. Maybe there is another scope problem, since it is a function.
Some times scope can be more of a problem than the code itself.
r.m.
|
|
Logged
|
|
|
|
|
