Is there a way to define vfp classes that show themselves in html?

I don't mean a web application such as you can make with west-wind connection, but a true vfp form with the same behavior except that it renders itself differently.

Another approach may be to use a go between program that reads the screen and outputs to the browser and viceversa?

The purpose of this effort is beautification only.

Would appreciate suggestions.

TIA,

Alex

LOL - Alex, where do you come up with these ideas that are basically variations of already existing technology and prohibitively expensive (in terms of time to build) to create?

Yes it's possible but you have to create it yourself 😃

Basically you can do these things but that doesn't mean it's useful in FoxPro. You can build a UI that renders Fox forms into HTML, then use a Web Browser control to drive the controls and the logic in them. That can work without requiring a Web server. But a) it's difficult to do this and requires a ton of JavaScript and interop code, and b) it doesn't exist, and c) why???.

There are already solutions that basically do what you ask, but use a Web Server. Specifically that's FoxInCloud. There's a reason why a Web server is used to provide that sort of environment for HTML because you need something - specifically JavaScript - to interact with the HTML to make it useful.

FoxInCloud which has all of the rendering and the UI interaction figured out. Note that you don't have to run an application like that over the Web either. You can run that application locally in a local Web browser or even inside of a FoxPro (or .NET) application that uses a Web Browser control and have users access it directly from there (ie. for your Remoting Scenario).

The long answer is this: It's totally possible to render basic FoxPro forms into HTML fairly easily. However, once you start talking about complex controls - grids, some of the complex ActiveX controls etc. - it gets increasingly hard to provide a reliable experience. It takes a lot of work and time and experience to get this right. A tool like FoxInCloud has figured that stuff out and does a good job with it because they have had YEARS to work out the kinks. And even then, there are still edge cases that don't work and that are still being fixed and adjusted as they come. FoxInCloud is pretty amazing in terms of what it accomplishes in terms of rendering and interaction, even though it's not my preferred way how I would approach a Web application.

To expect a solution similar to that that works as a locally driven engine that doesn't go through a Web server is a pipe dream that is unlikely to happen. Especially for the non-existant FoxPro market.

+++ Rick ---

Hi Rick.

Why? To prettify a 50 MB exe vertical app that is not worth rewriting and still going strong.

I would write it myself but I don't have the html, javascript and css know how that it takes. I know Thierry has tons of experience and mentioned to him but he is not interested.

A web server to communicate the app with the browser is fine. My main goal is that the app continues to run between hits, one instance per user. It's best if it all done locally as you mentioned. It minimizes time between a user action and the response and there is less need for browser code.

What do you think?

Alex

Maybe can I drop in with FoxInCloud in mind …

My main goal is that the app continues to run between hits, one instance per user.

FoxInCloud server saves the state for each user after each request and, upon next request from the same user, restores the state if another user has hit the server in between.

We could add a 'single user' mode that would never restore the state, thus saving app. 15% of the total response time (including the Network and Browser).

see a typical response time breakdown: the upper table shows the average for 25+ forms, 2k request from 150 unique users.

It's best if it all done locally as you mentioned. It minimizes time between a user action and the response

Yes for 'single user' mode

there is less need for browser code.

as the browser knows nothing of what happens on the server, you'd need the same amount of browser code for 'single user' and 'multiple users' modes. Fortunately, 99% of this code is provided or generated by FoxInCloud.

You can see here the amount of custom JS code in some applications:

• Real Estate Contracting: no code at all, only FoxInCloud settings
• Medical Bio Lab: no code at all, only FoxInCloud settings
• FoxInCloud Live Tutorial: mostly code for displaying source code and user events.

Very interesting Thierry.

Would not restoring state also reduce the need for hand tweaking of code by developer? That would make it much more interesting. As I mentioned our exe is very large and hand code changes take time and introduce bugs.

Look forward to your reply.

Alex

What you call “code tweakings” are in fact “code adaptations” which follow a well documented process and do not produce any bug when applied thoughtfully.

The FoxInCloud Live Tutorial illustrates these adaptations, please dedicate some time to review the code samples, you’ll realize how simple and secure it is.

Code adaptations are required for client-server architecture and compatibility with HTML event model, they do not depend on the number of users served.

You can adapt your application progressively, form by form, and not everything at once.