I have been hacking away at Foxpro since the DOS days but am not really a programmer. I have a VFP6 project I've been running for years and would now like to update it to VFP9. My question is this. I saw a thread for running a vbSCRIPT with VFP but is there a way to run a full blown VBasic.exe without exiting Foxpro? Thanks!
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Running VB6 within VFP9
- Thread starter Jim T
- Start date
Mike Lewis
Programmer
I'm not sure what a VBasic.EXE is, but if it is a normal EXE that you can run from Windows or DOS, then you can run it from within VFP.
There are two way of doing that. You can either use VFP's native RUN command, or you can use the Windows ShellExecute() function. Either way, you can pass parameters to the EXE through the normal command-line mechanism, but you can't trap a returned value from the EXE.
If the executable runs under DOS rather than Windows, you need to run CMD.EXE, which in turn will launch your program.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
There are two way of doing that. You can either use VFP's native RUN command, or you can use the Windows ShellExecute() function. Either way, you can pass parameters to the EXE through the normal command-line mechanism, but you can't trap a returned value from the EXE.
If the executable runs under DOS rather than Windows, you need to run CMD.EXE, which in turn will launch your program.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
My question is this....
Did or does your VFP6 application run the VBssic.exe (whatever that is) that you are asking about?
If not, they why would you want a VFP9 application to do so?
Keep in mind that, in general, whatever a VBasic.exe application do, VFP9 can, in most cases, also do without needing to branch 'outside' to VB.
If your VFP6 application is already running it, then you will be able to run it in the same manner as you do in VFP6. However what Mike says above it true.
Good Luck,
JRB-Bldr
Olaf Doschke
Programmer
You can run any executable - no matter in what language it is written in - by running/shellexecuting it or CreateProcess API function. And any language can run EXEcutables, because any language can use these or one of these Windows OS built in API functions to run something. In regard of "without exiting Foxpro", what should that mean? Any executable runs in it's own process. Within the same process you can only run code from DLLs, which can dynamically (at runtime) link to anything, and so run in the same process. That's also possible cross language. There always has been and will be the possibility to integrate things written in many programming languages, if there wouldn't be, there could only be one language, or each language would only run in it's own bubble.
What you can't do is write single programs in multiple languages, not within the same method, not within the same source project compiled by one compiler.
I don't know what thread you refer to with running vbscript with VFP, a link to that would help. Most probably you saw something running wscript, or automating office VBA. Of course, again this runs in a separate process.
There are EXEcutables, each one running in an own Process, there are DLLs, "linking" into already running processes dynamically, there is OLE/COM, which allows automation, a weaker link to both in the same process DLLs (inproc COM Servers) and other processes EXEs (out-of-proc COM Servers). You can create those COM Servers with VFP for use in other COM enabled languages, for example.
Then, besides these techniques, you can share data, of course, via shared memory or pipes or much simpler files and databases.
Interoperation is no magic and has many interfaces and possibilities. Even for no direct interoperability you can share data via files, databases, connect via http protocol to services and others.
All this is no limitation nor exclusive to VFP or VB or any language, but in the end it also means you don't run VB within VFP, you may have VB code you pass into wscript.exe, for example, but that makes wscript run that code.
Bye, Olaf.
What you can't do is write single programs in multiple languages, not within the same method, not within the same source project compiled by one compiler.
I don't know what thread you refer to with running vbscript with VFP, a link to that would help. Most probably you saw something running wscript, or automating office VBA. Of course, again this runs in a separate process.
There are EXEcutables, each one running in an own Process, there are DLLs, "linking" into already running processes dynamically, there is OLE/COM, which allows automation, a weaker link to both in the same process DLLs (inproc COM Servers) and other processes EXEs (out-of-proc COM Servers). You can create those COM Servers with VFP for use in other COM enabled languages, for example.
Then, besides these techniques, you can share data, of course, via shared memory or pipes or much simpler files and databases.
Interoperation is no magic and has many interfaces and possibilities. Even for no direct interoperability you can share data via files, databases, connect via http protocol to services and others.
All this is no limitation nor exclusive to VFP or VB or any language, but in the end it also means you don't run VB within VFP, you may have VB code you pass into wscript.exe, for example, but that makes wscript run that code.
Bye, Olaf.
- Thread starter
- #5
Thanks to all for the quick response. I was trying to get an idea on a problem that I now have to address. I have a piece of equipment from a manufacturer where the interface was built using DOS commands to capture data at a dos prompt (kind of like a mag reader). They released a Visual Basic version which I've been adding on to ever since. It's been 15 years and now I'm at the point where I have to either convert it to FoxPro completely, or shell out to the simple dos command prompt to capture the data, perform the VFP/Dos machine coding that winds up as a numeric value, then exit the VB/dos program, passing the value to Foxpro, which is now my new user interface. I assume the coding could be converted to Foxpro but it is a bit too complicated for me and I can't risk there being any errors. I think I can just run the !run command but I wanted to get a professional opinion.
Thanks, Jim
Thanks, Jim
Olaf Doschke
Programmer
Well, run calls whatever is configured with %COMSPEC%, typically cmd.exe. cmd.exe is not DOS, but looks like a DOS shell. It's a Windows Shell knowing and executing all the typical DOS commands as they are now part of System32 and SysWow64. But that's true since NT (where COMSPEC was command.com most probably, though). If you simply do RUN pause 20 and then examine the cmd.exe processes in task manager and let it display the command line used to start the process, you see VFP does nothing but cmd.exe /C with whatever you put after RUN. So yes, run is essentially the same as cmd.exe, it differs if you do RUN /N, which essentially starts whatever application directly without going through cmd.exe and also returns immediately, so VFP doesn't wait for the end of the call.
You can both do RUN notepad.exe and RUN /N notepad.exe, because entering notepad.exe at the command line of cmd.exe also starts the Windows application, this is because cmd.exe is a Windows shell and not DOS. You just see the commmand window and VFP waits for it to quit.
That's mainly all there is to it. Today you don't even have to fiddle with PIF files, but they still are used and prioritized before calling cmd.exe (or %COMSPEC%) and offer ways to configure the state of the cmd.exe window, for example.
Overall any EXE made with VB typically is a Windows application and not a DOS application, but I'm not a VB developer, so whatever project template was used there might be a differentiation. Whatever EXE you can start via double click from Windows Explorer can also be started via RUN /N, as rule of thumb.
Bye, Olaf.
You can both do RUN notepad.exe and RUN /N notepad.exe, because entering notepad.exe at the command line of cmd.exe also starts the Windows application, this is because cmd.exe is a Windows shell and not DOS. You just see the commmand window and VFP waits for it to quit.
That's mainly all there is to it. Today you don't even have to fiddle with PIF files, but they still are used and prioritized before calling cmd.exe (or %COMSPEC%) and offer ways to configure the state of the cmd.exe window, for example.
Overall any EXE made with VB typically is a Windows application and not a DOS application, but I'm not a VB developer, so whatever project template was used there might be a differentiation. Whatever EXE you can start via double click from Windows Explorer can also be started via RUN /N, as rule of thumb.
Bye, Olaf.
Olaf Doschke
Programmer
Just by the way, though a bit off topic. On a 64bit system COMSPEC typically is configured as C:\WINDOWS\system32\cmd.exe, which is the 64bit version of cmd.exe, when you RUN anything and look into task manager you see the commandline C:\WINDOWS\system32\cmd.exe /C anything and when you right click the cmd.exe and look into properties you see it is running from C:\Windows\SysWOW64. That's part of the redirection Windows does for 32bit processes to rather spawn other 32bit processes than 64bit processes. Whenever a 32bit application accesses C:\WINDOWS\system32\ this file access is rerouted to C:\WINDOWS\SysWOW64, whenever there is the corresponding executable/file. It's a nice way to see this redirection takes place outside of VFP and you need no COMSPEC environment variable redefintion for it to work seamless.
Bye, Olaf.
Bye, Olaf.
- Thread starter
- #8
I've been testing RUN /N notepad.exe and substituting my VB exe command and it runs quite smoothly. I remember years ago it took a while for the splash screens etc to load but I've been out of the loop for so long that this may be a bit easier than I first thought. Thanks for your input Olaf.
Jim
Jim
Olaf Doschke
Programmer
Well, I assume the smoother execution you observe simply is because VFP doesn't wait for the VB process to end, if you use RUN /N. As described it's an option having a twofold effect: 1. no Shell Window appearing, as no cmd.exe /C is started, but 2. No wait (that's what the N stands for) for the end of the process.
If your VB puts something on serial port for example, and your next VFP code tries to receive the answer, this might fail on external serial devices taking some time to respond. If the VB app handles this serial port communication overall, that's not a problem, but you might access an output file (you mentioned the VB exe passes something to Foxpro), then you might need to go through cmd.exe and to get rid of the shell window use shellexecute of cmd.exe /C whatever with the option of Shellexecute to not show the main winndow of cmd.exe and still yet wait for the VB process to end and have passed the result to VFP.
Bye, Olaf.
If your VB puts something on serial port for example, and your next VFP code tries to receive the answer, this might fail on external serial devices taking some time to respond. If the VB app handles this serial port communication overall, that's not a problem, but you might access an output file (you mentioned the VB exe passes something to Foxpro), then you might need to go through cmd.exe and to get rid of the shell window use shellexecute of cmd.exe /C whatever with the option of Shellexecute to not show the main winndow of cmd.exe and still yet wait for the VB process to end and have passed the result to VFP.
Bye, Olaf.
- Status
Similar threads
