Challenge: Simplest VFP web application EVER! 2

[dantre]

Hello,

Can anyone show me the absolute simplest way to call a VFP function which is housed on a web server from a client computer via a web browser?

Restrictions:
No ASP allowed. FOXISAPI confuses me (if you can make it simple, be my guest). No pay tools (i.e. WebConnection/WestWind).

Objective:
I'd like to be able to submit a name string, using an HTML form, to some VFP code (DLL/EXE/Whatever) that is sitting on a server. The code would then return a custom greeting, like...

RETURN "Hello "+cName+"!"

...to the web browser.

Is this possible?

The closest I've come was to create a COM DLL and then use VBScript CreateObject() to access it. The flaw with this is that, I believe, the client machine must have the DLL registered. Also, it requires that the user enable ActiveX (therefore it only works in IE, and may be perceived as a security threat). The ActiveX part I can deal with, however. But I can't ask every user to register a custom DLL.

I'd be very interested to see what we can come up with. This could make a great FAQ if we succeed.

Thanks in advance! -Dan

 

[Mike Gagnon]

This could make a great FAQ if we succeed.I'd be very interested to see what we can come up with.

How far did you get with?


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[dantre]

How far did I get with what? I'm still waiting for suggestiongs. I hit a brick wall with the VBScript COM DLL route, as I noted above.

 

[Mike Gagnon]

I was just kidding. I was more refering to this statement "This could make a great FAQ if we succeed". Which seem to indicate that YOU are taking part in coming up with the solution.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[Mike Gagnon]

Just to clarify. This site is normally used for help programming issues where you would post the code snippet that is giving you a problem and we see where your code maybe falter. But I personnally charge by the hour for complete solutions ;-). None the less as far as I know you cannot call a COM just using HMTL, it has to be a scritping language like java or cgi or vbscript.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[wgcs]

Dan,

Asking for a simple web app in VFP is probably not as useful as you think.

The "complicated" frameworks that exist for VFP/Web apps are there to make things work well. A Simple VFP/web app won't be very extensible, so all the effort used in creating it would be kind-of useless.

The problem is that there are multiple pieces involved:
1) the VFP function
2) the VFP application that enables the function to work (.APP, .EXE, .DLL file, including the libraries a framework provides)
3) the Web Server itself
4) (or is that 2b?) a connector between the VFP application and the web server (this can be FOXISAPI.DLL... written in C)

So, to have the very simplest #1, you still need #2, #2b and #3, which are all maleable.

Here's one example where #2, #2b and #3 are all written in VFP:

http://fox.wikis.com/wc.dll?Wiki~WebServerInFoxPro

If you use FOXISAPI.DLL as #2b, then #3 can be Microsoft IIS, or Apache, or Sambar, or any other web server that supports ISAPI. However, you must
1) configure the web server to allow FOXISAPI.DLL as an isapi server, (how to do this is different for each web server)
and 2) build #2 as an ActiveX/Ole automation server, revealing #1 as a method. and have that .EXE or .DLL registered on the web server.
If using this method, then it is entirely up to you to make sure that you can scale to many users hitting your server simultaneously. Plus, Microsoft doesn't really seem to tout FOXISAPI.DLL as production-ready...

It's also possible in VFP to create SOAP-enabled web services (which I think are simply special ActiveX/Ole automation servers with a WSDL file that describes its methods.) this basically provides #2b and #3, you still have to make #2 yourself.... This is What you're looking for, I think, BUT you can't call it as simply as you describe... you need to use SOAP. There are examples in the VFP help file about how to do this... I'm not very experienced at it.

If you're just playing around, I'd recommend going the FOXISAPI way. If you describe where you got stuck, maybe I can help: I have had a small app up-and-running using FOXWEB.PRG/FOXISAPI.DLL for about 5 years (with numerous restarts as the code is adjusted), which provides our company with some internal services (like bug-log tracking).
If you are trying to create something commercial, use a commercial web tool, like west wind, or Active Foxpro Pages, because I'm sure you'll get much better reliability.

The whole trouble boils down to: You can't just build a simple VFP web service and scale it up to a production-level environment without starting out by architecting it so it will be able to scale.

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[dantre]

First of all, Mike, ouch...

I spent a lot of time trying to do this simply with a vfp COM DLL and vbscript, so I'm sorry if you feel that I'm just looking for hand outs.

I just wish that it was possible to do this without having to run your own web server. I used to be puzzled as to why VFP was not more commonly used, but after reading whitepaper after whitepaper on the subject, I'm shocked that anyone would ever bother making a vfp web app.

Not to mention that everywhere I've politely asked for advice there's always at least one or two bitter replies...

wgcs, thank you very much for your thoughtful reply. Unfortunately, I was really hoping to find a solution that didn't require that much control over the web server.

Also, eventhough this is a new account, I posted here for a very long time until my account got corrupted.

 

[Mike Gagnon]

I spent a lot of time trying to do this simply with a vfp COM DLL and vbscript, so I'm sorry if you feel that I'm just looking for hand outs.

Sorry it sounded like you wanted the "experts" here to come with a complete solution that worked for you and walk away "scott free".

I just wish that it was possible to do this without having to run your own web server. I used to be puzzled as to why VFP was not more commonly used, but after reading whitepaper after whitepaper on the subject, I'm shocked that anyone would ever bother making a vfp web app.

The issue is the website. You want to convey information to someone in a static way (no interaction with the user) no problem, HTML is the easy part. Notepad and web browser are the only tools you really need. But when it comes to interaction (even a guestbook) it needs more than just HTML, it needs a language that can do something other that formatting text. So VFP programmers being familliar with VFP want to do it in VFP, other do it in other languages. But what you are trying the do is not unthinkable and quite easily achievable. There are two or three website that I know of the run on VFP (They are mostly in Europe but still possible), one of which I am a member of is

http://www.atoutfox.org.

The whole "backbone" of that site is VFP.

Not to mention that everywhere I've politely asked for advice there's always at least one or two bitter replies...

Can I suggest you ask your questions in smaller chunks? Your original post sounded like "give me the solution and We (meaning you) will take all the glory". Rick Strahl has done extensive work in VFP web based applications, that may be a site you want to look at

http://www.west-wind.com.

But designing a website site that runs on VFP is not my idea of an FAQ, is it more like a project that takes time and effort and resources.

Not to mention that everywhere I've politely asked for advice there's always at least one or two bitter replies...

This is bigger than "fix my combobox problem". This requires knowledge of all the components involved ie: VFP, the web and anything in between that will make them communicate with each other.

Also, eventhough this is a new account, I posted here for a very long time until my account got corrupted.

Accounts DONT just get corrupted here. Please read the faq in my signature. There are suggestions for a better way to post a question.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[audiopro]

I have been with the FOXPRO family since back in the DOS days but have never attempted any Web stuff with it. IMHO there are other tools better suited to web work, unless I am missing out on Foxpro's Web functions. Having said that, I am only using VFP6 which does everything I need it to do.

Keith

http://www.studiosoft.co.uk

 

[dantre]

If you read my original post carefully, I am asking a very simple question.

How to access VFP code through a browser.

I have NO interest in designing an entire website. just one form that submits very few parameters to a VFP class and gets something back from it.

Here's a more specific question: If I register a VFP DLL on the web server, can every client access it, or would they have to register the dll?

Here is how I managed to run VFP code in a browser WITHOUT using IIS/FOXISAPI/FOXWEB/WebConnect/AFP/ASP or any web server software.

Just VFP, Notepad, and Internet Explorer.

I managed to call a VFP class that I built into a COM DLL using VBScript.

The VFP class is called MyClass and looks something like this:

DEFINE CLASS MyClass AS Custom OLEPUBLIC
	PROCEDURE Greet
		LPARAMETERS cName
		RETURN "Hi "+cName+"!"
	ENDPROC
ENDDEFINE

I saved this in MyClass.prg, added it to a project, then I built the project as a Multi-Threaded DLL named "MyDll.dll"

Then I saved this Mark-up/script as "test.html" and opened it in IE:

<HTML>
<HEAD><TITLE>dlltest</TITLE>
<SCRIPT LANGUAGE="VBScript">
<!--
Sub Button1_OnClick
	Dim oMyClass, MyString
	Set oMyClass = CreateObject("MyDll.MyClass")
	MyString = oMyClass.Greet("Bob")	//Returns "Hi Bob!"
	Set oRadio = Nothing
	document.write(MyString)
End Sub
-->
</SCRIPT>
</HEAD>
<BODY>
<FORM>
<INPUT NAME='Button1' TYPE='BUTTON' VALUE='Click Here'>
</FORM>
</BODY>
</HTML>

If you follow these steps you should get it to work.

It will only work in IE because only IE supports ActiveX, and even then you will probably be asked to enable ActiveX. But it works.

When I got to this point I was very excited, but the it occured to me that ever user of the website might need to have my DLL registered for it to work.

Is this the case, or would it be enough for the server to have it registered?

p.s. are people that nutty about FAQs here? Do you get paid for them or something? When I said "WE" I meant we, but if you want to take all the credit, I could honestly care less.

 

[Mike Gagnon]

p.s. are people that nutty about FAQs here? Do you get paid for them or something? When I said "WE" I meant we, but if you want to take all the credit, I could honestly care less.

No not at all, and may I suggest that you post this solution in the FAQ section so you get the credit.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[dantre]

Thanks Mike.

I believe that this can work with the dll only registered on the server. I'm going to test this on a web server and if it works, an FAQ will be born.

 

[Mike Gagnon]

Technically, I would also agree that the COM only needs to reside on the server. Type type of setup is done all the time, and the user normally is not required to download and install anything, except on rare occasions mostly for DirectX.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[dantre]

I may have to build it as an out-process EXE instead of an in-process DLL.

I read somewhere that the in-process DLL may have to run on the Client machine, because it needs to share the client app's memory space. Whereas the EXE runs in its own memory space, so it can reside on the server.

I'm not sure if the DLL won't actually work, but I'll try to test them both.

Is it possible to register a DLL/EXE on a server via telnet (I'm really in the wrong forum now)?

 

[wgcs]

Hi Dan,

I think I understand your position; I also think you're asking a bigger question than you think you are... you say:

I spent a lot of time trying to do this simply with a vfp COM DLL and vbscript...

I just wish that it was possible to do this without having to run your own web server.

If you read my original post carefully, I am asking a very simple question: How to access VFP code through a browser.

I have NO interest in designing an entire website. just one form that submits very few parameters to a VFP class and gets something back from it.

Here's a more specific question: If I register a VFP DLL on the web server, can every client access it, or would they have to register the dll?

Here is how I managed to run VFP code in a browser WITHOUT using IIS/FOXISAPI/FOXWEB/WebConnect/AFP/ASP or any web server software....


This method reveals a fundamental lack of understanding of HTTP and web technologies. It is also similar to Microsoft's abandoned "ActiveForm" approach to web pages.

To directly answer your questions:
If I register a VFP DLL on the web server, can every client access it, or would they have to register the dll?

No, you can't access a .DLL file using the CREATEOBJECT(...) calling method unless that .DLL is registered on the computer running the CREATEOBJECT(...) command. There's no way around it: CREATEOBJECT(progid) causes windows to search it's local registry for "progid", and if it isn't found there, then it can't access the object's DLL.

Now, you might think "then I'll have to register the DLL on every client, and then it will work". The problems occuring with this reasoning are:
1) Now every client will have to Trust your DLL (which is fine for friends and coworkers, but is absolutely impossible for a public website)
2) Now, you will have to determine & implement a way to distribute the DLL to each user: you can't simply "access" a DLL across the internet (in an executing-code manner).. it has to be downloaded then registered (executed). This is fundamentally insecure, so there aren't any ways that will do it for you: you'll need to create an installer program with something like installshield (or a batch file calling REGSVR32, etc) that will be downloaded and run before your website works.
3) Now, when the DLL is adjusted, you'll have to find a way to re-deploy the DLL to all the clients.
4) most importantly: as the DLL is executing, since it is executing on the client and not on the server, it won't have any more access to server resources than the client computer. You won't be able to "USE mytable" (because mytable.dbl is on the server, and you don't have drive-share access across the internet), you won't be able to "SELECT * FROM mytable" (same reason). You could use HTTP GET to access web pages from the server that contain data, and then HTTP POST to submit data to a form processer on the server... but that's the part you seem to be trying to create, rather than wanting to use a part that already can do that.

It comes down to this: if Executable code is going to be running on the server (and not on the client), then you need to care about the web server.

On a static web site, as Mike pointed out, the web server sits and waits for HTTP GET requests (which look something like this:
[tt]GET /ip_image.php HTTP/1.0
Host: www.printmyip.com[/tt]
)
then the server responds with the requested page or file (which looks something like this:
[tt]HTTP/1.1 200 OK
Date: Fri, 19 Aug 2005 14:29:13 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Accept-Ranges: bytes
X-Powered-By: PHP/4.3.2
Connection: close
Transfer-Encoding: chunked
Content-Type: image/jpeg[/tt]
... followed by the image data, or HTML text )

To run code (VFP code, or any other code) on the server, you need to make the web server understand that when it gets a certain request (perhaps, when it gets a request for any page that has the last letters ".asp" or ".dll" or ".cfm" before a question mark... this is called an "HTTP GET form submission" ) that the web server should then locate that resource (ending in .asp or .dll or .cfm), and hand it the parameters that follow the question mark.

These "extensions" are quite arbitrary... you could define a new one ".VFP" that is VFP code (or .PRG). However, there are now standards that are pretty commonly followed:

.asp = Load the Active Server Pages .DLL and tell it to handle this page, and break the stuff following the "?" down into name-value pairs, and hand all these parameters to the asp .dll. This asp script may contain CREATEOBJECT commands that instantiates a VFP COM DLL and accesses a method on it, etc. Since the web server loaded the "Active Server Pages .DLL", the asp script is executing on the server, and therefore the VFP COM DLL will instantiate on the server, and have access to all the server's resources (dbf files, mapped drives, etc).

.cgi or .pl = Dump the stuff following "?" into a text file, then Load the perl command interpreter and hand it the name of the text file

.dll = Treat this file as a virtual directory: Use the ISAPI functions to load this DLL and hand it the stuff following the "/" as a single big parameter. Let the DLL do what it wants from there on.

Clearly, this last one is what is used for FOXISAPI.. the calling prototype for the URL is this:

http://domain.tld/path/foxisapi.dll/Foxweb.MyClass.MyMethod?param1=value1&param2=value2

To use this Foxisapi example, there are some things needed:

1) FOXISAPI.DLL must exist on the server in the folder identified by "/path/"

2) FOXWEB.DLL is a VFP dll built by you (FOXWEB.PJX is an example project provided with VFP by microsoft.. it's simplest to add classes to that project rather than start from scratch, so FOXWEB.DLL is what the dll often ends up called).

3) "MyClass" is a class in the FoxWeb project that is OLEPUBLIC

4) "MyMethod" is a method in MyClass, and takes these parameters:
PARAMETERS p1,p2,nPersistInstance
P1 might be filled with all the form fields and values in URL-encoded format (result of a HTTP-GET form submission)
P2 might be filled with the name of an .ini -format file containing the form fields and values (result of an HTTP-POST form submission)
nPersistInstance is an output parameter, and determines whether the DLL should be released by FOXISAPI.DLL after it is done with it.
This method should return a string containing the page to send to the web browser.


I hope this makes it a little clearer to you how a webserver interacts with executable programs.


- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[Mike Gagnon]

No, you can't access a .DLL file using the CREATEOBJECT(...) calling method unless that .DLL is registered on the computer running the CREATEOBJECT(...) command. There's no way around it: CREATEOBJECT(progid) causes windows to search it's local registry for "progid", and if it isn't found there, then it can't access the object's DLL.

How about CREATEOBJECTEX() ?



Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[dantre]

.cgi or .pl = Dump the stuff following "?" into a text file, then Load the perl command interpreter and hand it the name of the text file

I've played with perl a bit in the past... are you saying that there is a way to access a VFP DLL using a Perl script?

If so, that would be best for me, certainly the simplest. Most web hosts support Perl, while fewer support ASP (mine doesn't), and virtually none support FOXISAPI.

No, you can't access a .DLL file using the CREATEOBJECT(...) calling method unless that .DLL is registered on the computer running the CREATEOBJECT(...) command. There's no way around it: CREATEOBJECT(progid) causes windows to search it's local registry for "progid", and if it isn't found there, then it can't access the object's DLL.

Are you sure that an out-process EXE COM couldn't do this?

 

[wgcs]

How about CREATEOBJECTEX() ?

I hoped you wouldn't go there, Mike ;-)

Technically, my answer covered that, though: CreateObjectEx still requires that the progid for the activeX COM server be registered on the local computer... Sure, if you specify the GUID CLSID, it doesn't have to be registered locally.

This does, perhaps, offer Dan just what he's looking for, though...

Dan: Read Rick Strahl's page here

http://www.west-wind.com/presentations/internetenabling/InternetEnabling.htm

for info on using remote COM instantiation to access a VFP COM server over the internet (particularly the section "Direct instantiation via CREATEOBJECTEX()" )

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[dantre]

So, these are the key rules for using CREATEOBJECTEX()?

- the web host and client must both have VFP installed.

- the web host must have the COM server registered (and maybe the client as well, or just the type library?)


Is this accurate?

Is there any method that doesn't require the client to install or register anything? Does FOXISAPI require the client to have VFP runtime files?

It's starting to sound more and more like I need to start learning a new language...

 

[Mike Gagnon]

dantre, do you have a website you can test this on?


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)