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!

Python code execution though Foxpro environment

A_Radiolog_inFoxPro

IS-IT--Management
Mar 29, 2020
44
CY
Dear All ,

This will sound silly and stupid , but it's worth the shot.

At the moment when I want to interface with a python project I have to generate a text file with all the details / parameters(generating it via foxpro before hand ) I have to pass to it then run the python script that is pre-compiled as an exe through fox-pro behind a yes no window box.

now the issue arises when I want to change that exe file of python to make changes it takes time to find it , change it , replace it , and then recompile it , re-package it as an executable.

has anyone in here thought or found a way to call or use the higher level languages of python though the .prg files of foxpro ( 6.0 in my case ) ... I know I know I should have ditched VFP long time ago.
( is like trying to run DOOM on voyager 1 with 60 FPS remotely too .... )

I found this. https://github.com/mwisslead/VFP-Embedded-Python

But I am not 100% sure that this will do what I want it to. I haven't tried it yet.

Let me know if you have any thoughts on my idea / problem

Thank you in advance
The Radiologist
 
"like trying to run DOOM on voyager 1 with 60 FPS remotely"

I don't find that to be true. VFP still runs great and given that it was built for data from the ground up, it makes dealing with data far easier than something like .NET.

As for your question, I'd like to see a better description of what you're doing, because it's unclear to me. You know what it is you're doing, but you've not explained it well, I'd say. I've always noted it's difficult for us as programmers to explain things to others. We have divorce ourselves of the knowledge we have of a system and see it through the eyes of others unfamiliar with it. Same applies here.

But, can Python be loaded as an automation object? Probably not, but that would be great for your needs, if it could.
 
"like trying to run DOOM on voyager 1 with 60 FPS remotely"

I don't find that to be true. VFP still runs great and given that it was built for data from the ground up, it makes dealing with data far easier than something like .NET.

As for your question, I'd like to see a better description of what you're doing, because it's unclear to me. You know what it is you're doing, but you've not explained it well, I'd say. I've always noted it's difficult for us as programmers to explain things to others. We have divorce ourselves of the knowledge we have of a system and see it through the eyes of others unfamiliar with it. Same applies here.

But, can Python be loaded as an automation object? Probably not, but that would be great for your needs, if it could.
Imagine .

I have some things I want to do. Having Foxpro to speak to a webserver make requests etc etc.

I can't do that directly through Foxpro.

So I bridge the gap by. the following :

1.passing the parameters from FOXPRO to a TEXT file.
2. Made a Pre-compiled exe file of a python project with all the libraries and logic I need. also in the code poining the python script to get the data from that text file(that foxpro added what parameters into).
3. calling the python script from Foxpro as a shell32 run command
4. Python script does its thing and returns what ever I need in the same file.
5. Foxpro waits for my response that the script has ended successfully. so that it can pick up where python left off.
6. go on with my day as python did the heavy lifting.

And yes I am trying to run doom on Voyager 1. there is no doubt about it.

because I am trying to make a system that was never intended to work with webserver's , requests , ssl and fly a plane.

With data ? Sure I agree is quite versatile. and sometimes robust if implemented correctly

Let me know if something was unclear.

Thank you in advance
 
I have some things I want to do. Having Foxpro to speak to a webserver make requests etc etc.

I can't do that directly through Foxpro.
Of course you can make http requests with VFP, and that's also the straight forward way to execute other languages run within the web server, like PHP, Perl, Python. You're instead going the hard way compiling pythin to an exe to call. To my Python mainly is a scripting language, you don't necessarily need the web for it, you can run python.exe and pass in command line parameters, of which one is the name of the python code file to run. You can theoretically also do that with PHP.

It's typically not done, neither with Python nor PHP as you don't install Python or PHP on an end users computer but have your PHP/Python or other code in the web on your server that has a Python/PHP installation under your control, easy to upgrade, configure as necessary, etc. and Python/PHP script you run by makeing http requests to it, which can have a body of parameters, too.

In short, an API, a web API, a web service.
 
One thing is true about Python, it's also used standalone, there's the basic standdar IDLE Shell installed with Python and there are ways to code python within MS Visual Studio Code, there's Jupyter and much more, and there are modules for many things in the direction of AI or Data Science etc. etc. Python is a bit of a Chameleon and not in the first place, as PHP just intended as web scripting language.

Python is not rarely used standalone, for any development, it is a general purpose language, not just a web language. but given your description needing often changes in your python modules points out to me that you rather want to use it uncompiled to an EXE and jsut as a scripting language, and then it's good to embed that into a web server as web language, which makes it easy to scale up to offer it in the cloud and not only locally as a module your EXE uses.

Well, and from the other end of a perspective to write some extension for applications, wanting a close as possible integration you write a DLL that's used by anything else and when you change features, extend it, then building new versions of a DLL (or EXE) is normal, it shouldn't hinder you to do that. It becomes crazy, if you generate Python code from within your application and want to auto build that into a DLL or EXE to use by the application.
 
Last edited:
Of course you can make http requests with VFP, and that's also the straight forward way to execute other languages run within the web server, like PHP, Perl, Python. You're instead going the hard way compiling pythin to an exe to call. To my Python mainly is a scripting language, you don't necessarily need the web for it, you can run python.exe and pass in command line parameters, of which one is the name of the python code file to run. You can theoretically also do that with PHP.

It's typically not done, neither with Python nor PHP as you don't install Python or PHP on an end users computer but have your PHP/Python or other code in the web on your server that has a Python/PHP installation under your control, easy to upgrade, configure as necessary, etc. and Python/PHP script you run by makeing http requests to it, which can have a body of parameters, too.

In short, an API, a web API, a web service.
are you sure vfp 6.0 can do directly api calls ?

as far as i know in vfp9.0 and higher with some modes / external dll calls was possible.

do you have some vfp 6.0 native examples ?

and Native is the key point here.
 
You don't need native code to do API calls, https requests, that is. You use OLE objets for that, and VFP6 can do that just like VFP9.

Code:
loHTTP = CREATEOBJECT("MSXML2.ServerXMLHTTP.6.0")
loHTTP.open("GET", "https://www.tek-tips.com" ,.F.)
loHTTP.send()
Do While loHttp.readystate<4
   Doevents
EndDo
? Left(loHTTP.responsetext,200)+"..."
Just like you can make a GET request for the homepage of a site, you can call a PHP script at some URL and get the response of the PHP script back. It doesn't need to be HTML, it could be anything binary, XML, JSON, whatever, and then you process that response in VFP.

The code has nothing VFP9 specific, the functionality of a HTTP request is in the OLE Class. There are several and you don't need to be as specific as I was here with version 6.0 of MSXML2.ServerXMLHTTP. It'll work from Windows 98 to Wiondows 11.
 
There is a project on GitHub: VFP-Embedded-Python, which allows you to run native Python code within Visual FoxPro (VFP). I use Python extensively, and to integrate it with my legacy VFP application, I utilize a SQLite table as a bridge between the two runtimes. This approach is incredibly fast and highly flexible.

With Python's Pandas library, you can efficiently process SQLite or MySQL files. It offers exceptional performance ( in most cases much faster than VFP,) , and the coding experience is straightforward.

For web server functionality, you can use Flask in Python to interact seamlessly with the SQL table, enabling a powerful and flexible server-side solution.
 
The Radiologist has mentioned that github himself.

I don't like to install Python or PHP or any other language to integrate with with an application setup, as that's usually not easily to integrate in a setup. It's feasable to do and use, I'd still prefer the usual way of interop with other languages that don't offer to interop via DLL or OLE class through the web with http requests.

The github project makes use of a Python.dll or Pythonw.exe or both. Usage of Python.dll is clearly usage of a DLL, but you can't just distrubute the dll standalone (inclduing a runtime), this whole project requires a full PYthon installation.

The http request usage of Python also requires a Python installation, but hosted on a server under your control, maybe provided by the hoster you choose and maintained by them - one less job for yourself.

If a Windows computer you install your application already has a Python installation, that could be used, but then the configuration of it and upgrades is not under your full control, you can't - as far as I know - simply install Python twice to have your own version for your application usage only. This makes it a less controllable situation.

It's totally fine, if you just do all this for yourself, if you don't distribute an application and just write your application for yourself, no doubt, but I wouldn't recommend the dependency on a whole language installation.
 
For web server functionality, you can use Flask in Python to interact seamlessly with the SQL table, enabling a powerful and flexible server-side solution.
Yes, Flask is one of the first known frameworks for using PYthon on the web, but you can get bare python to work just like PHP on an IIS, for example like this:

I would recommend to find a hoster to offer py scripts to run, as that unbinds you from the maintenance of Python itself. If you don't consider there is any maintenance to do as the python integration in your application is fixed and when it is tested to run error free that'll do forever, you don't consider securtiy fixes, for example.

Again, when you all do this for yourself only and don't need to consider a distribution of your whole system including Python and whatever other components you integrate, it's fine, you'll be able to fix this for yourself and don't have the maintenance problems for clients using your software.
 
Yes, Flask is one of the first known frameworks for using PYthon on the web, but you can get bare python to work just like PHP on an IIS, for example like this:

I would recommend to find a hoster to offer py scripts to run, as that unbinds you from the maintenance of Python itself. If you don't consider there is any maintenance to do as the python integration in your application is fixed and when it is tested to run error free that'll do forever, you don't consider securtiy fixes, for example.

Again, when you all do this for yourself only and don't need to consider a distribution of your whole system including Python and whatever other components you integrate, it's fine, you'll be able to fix this for yourself and don't have the maintenance problems for clients using your software.

With PyInstaller, you can bundle all Python dependencies (including the Python runtime) into a single package, either as a standalone executable or a folder.However, there are indeed many ways to accomplish tasks between Python and Foxpro.
 
The problem is not to bundle Python for your setup, you may just point out to end users, that they please install Python 2.7 or whichever version you need and specify the path of Python. The problem with a python installation required for your software is that other software having the same dependency already can cause conflicts. Not that their and your software run Python, that can be used in parallel, but like VFP has settings, PYthon has settings, you may require other settings than the other software. So I would only be working with a separate Python installation just for my software, and I don't see something like that without going through hoops like making my software a VM that runs completely separate from the host system in it's own little virtual universe, and I won't recommend to do that for somebody like A_Radiolog_inFoxPro.

Running Python within a webserver is having that separate universe, either under the roof of a website re runs as a support server for his software or in the intranet.

And as I already siad, if the software doesn't need distribtion, then you have the freedom to integrate whatever without thinking about such things as dependencies. because your only maintenance problems are with your own computers running your own software.

Maybe, A_Radiolog_inFoxPro, you even think this github repository is self contained and has everything in it to run Python with FoxPro, but you requira this Github package and a full Python installation. to run this. It may not be impossible to just pick out the essential pythonw.exe and some support DLLs to fully integrate, but as Python scripts depend on modules you'll have to also integrate subfolders lib, DLLs and then you're already near a full Python installation folder. Python like VFP knows its HOME() installation folder, so if a Windows system has two or mor Python installations it becomes hard to maintain what Home os for your Python integration, I think.

Looking into another software that uses Python for scripting within it - Gimp - that does not use a full Python installation it depnds on, it has some libpython2.7.dll and libpython3.9.dll in a bin subfolder of its application directory. It doesn't intefere with the Python installation I have, too. The goal opf the Python integration of Gimp is not to run general purpose Python code, but for scripting batch processing. It will not import anything I have available in my major dededicated Python installtion, it's not the intention to be able to, it's sufficient it can use modules of Gimp to have image processing features of gimp for automation batch processing purposes.

So, it's not impossible to integrate Python in software in a way that's not simply using a full Python installation. I'd be more impressed with a FoxPro Python installation that's using the same integratable libraries as Gimp does, though I also fully support that the idea of simply wrapping around a full Python installation makes it easier to integrate any general purpose Pyhton scripts that add to the import modules etc. as necessary. It's just something not as simply to redistribute, unless you make the assumption it will not collide with anything your end users have already installed.

Well, and the solution I still prpüpse in having a Web server integration with Python used centrally, that has one little disadvantage of the http request/response full turnaround time, that's surely a few ms everytime, but it's usable, otherwise no web services would be able to exist. With such a separate cloud based solution you have your own and only Python installation fully under control without needing to install anything at clients, you can choose the modules you need, configire PYthon as you want and upgrade whenever necessary. You can maintain your Pythong code and not necessarily need to build it into an EXE. Python is just like VFP not necessarily getting a boost from that, unless you use a build system that does not produce Python byte code but transpiles it to the C++ underlying the Python language and make a C++ binary from it that effectively becomes assmbler, just as fast assembler as you get from writing C++ code. CPyhton does that, I think, I never used that, Cython does similar things based on another idea, I'm not in the details. But such things will always not be fully compatible or need adjustments in the code. And, I think, A_Radiolog_inFoxPro. your main idea is to use solutions you find done in Python and not need to translate that to VFP code. It's surely a nice way to increase usable solutions. It's a huge effort, if all the Python code does is use web APIs you could also directly use from VFP, though. And many things like AI APis and other databases are directly integratable into VFP without going through Python.
 
Last edited:

Part and Inventory Search

Sponsor

Back
Top