Hi Rob,
You wrote:
>How can I get return values from an external application?
>
>err = baRunProgram( externalApp, waitState )
>-- or
>err = baShell("open",externalApp,args,EMPTY,"normal" )
>
>Of course these BudAPI functions let me run an external app, and they
>return their own status values, but I need something like this:
>
>howMany = Run( "GetHowMany.exe", parm1, etc )
>
>What am I missing? Thanks for any direction.
I couldn't find any solution for your interesting question, but only one
possible explanation, limiting to Windows OS, of the behavior of Buddy API
about the return value.
Just as you noticed, the Buddy API docs report that the return value from the
two functions you mentioned is only an integer containing some info about the
success/fail of that operation performed by the Xtra.
Although we can't know the code internally used by the Xtra to launch an app,
we should be reasonably allowed to suppose it is based on Windows API standard
functions as WinExec() or CreateProcess().
Functions like these ones return values whose purpose is to inform the calling
program (the Xtra, in this case) about the success of the operation.
Whether Buddy API, so as it seems, relies upon them, it's possible it behaves
like them.
In respect with WinExec(), CreateProcess() fills also a structure, passed to it
by reference, with informations about the newly created thread. But anything
more can be found there about values (as howMany) coming from operations internal
to the new process. And so I think that such values can be shared between it and
the Xtra (and hence subsequently passed back by the Xtra to the Director app)
only by setting up some OLE/DDE technique.
Imo the reason of this limitation is because CreateProcess() can't expect to get
back a value from the application it's launching.
On the other hand, it can't neither pull out data from an application and then
put them into a structure because it doesn't a-priori know anything about type
and amount of bytes needed by the data: they would depend on how the app itself
was constructed.
But why can't CreateProcess() expect to get back a value from the return statement
of an application? Because it is possibly never executed. As an example, here a
sequence of possible events.
At the time the function Run() is called by:
howMany = Run( "GetHowMany.exe", parm1, etc )
it happens that the WinMain() function, inside GetHowMany.exe, is called by the
Xtra through a function like CreateProcess(). Then, after WinMain() ends with all
operations needed to create the new instance, it enters the loop of the so said
message pump, and exits it only when the application is requested to quit, which
might happen at any time:
WinMain() { // type and parms omitted
...
...
while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
The return statement at the end of WinMain() is executed only when "GetHowMany.exe"
quits, so CreateProcess() can't expect to receive a value from it neither while
launching the app nor after some defined time.
So far so good. Though, being things in these terms, it might seem that if one
writes the app code so to skip the message pump loop, this would allow him to
send back whichever value to the calling program:
...
...
howMany = 999;
return howMany;
}
A code like this could work. But, besides the fact that the app would quit
immediately, the point is that, neither in this case, howMany could be received
by CreateProcess() (that's by the Xtra). In facts the things seem structured in
such a way that "GetHowMany.exe", in so far as created by CreateProcess(), is
never a child process of the Xtra. It's a new thread controlled by the OS, as
TranslateMessage()/ DispatchMessage() indicate, and the return statement never
yelds to the app that created the thread. Instead, it yelds to the OS.
I think also that some "wait" behaviours of Buddy API around this matter are
achieved by the normal, but limited, windows messagery.
For example, if it's true that CreateProcess() create an indipendent thread,
we may suppose that the Xtra knows when it activates by getting a WM_ACTIVATEAPP
message - and this may happen much time after the running of CreateProcess().
This would let me think of a possible solution in the use of the function
baSendMsg(hWnd, msg, 0, 0, TRUE). It should send a message to the window of
"GetHowMany.exe" and try to trigger some action (i.e. writing howMany to the
clipboard and then getting it back by Lingo clipboard functions).
But this could reveal quite tricky and depend upon the amount of things you
know about "GetHowMany.exe".
In the end, it could be necessary having the source code of it. As to say:
if the Xtra can't be adapted to my app, my app could be written so to adapt
to the Xtra.
BTW, if you find a solution, please let me know.
Kind regards,
Franco
IFC Programming Consultant
http://www.chnexus.com/main.htm
Private mailto:[EMAIL PROTECTED]
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
