About FoxInCloud Technology


FoxInCloud views a VFP9 application as a black box interfaced with inputs and outputs: inputs are events that user triggers on the graphic interface, outputs are data supplied back: changes to user interface, a file or a report.
FoxInCloud ‘clones’ the application GUI into HTML/CSS/JavaScript, catches user events, transmits events to the Visual FoxPro application running on the server for executing the matching VFP event method.
By comparing the state of user interface before and after event execution, FoxInCloud Application Server (FAS) identifies the differences and sends them back to the client for execution on the HTML page.
FoxInCloud hooks applications forms and contained controls through 2 additional layers of classes substitutive to the native Visual FoxPro classes; while the base layer is FoxInCloud-specific and can be replaced at any time by any newer release, you can implement specific code in the intermediate layer dedicated to your app(s).

HTML/CSS/JS generation

At startup, FoxInCloud Application Server (FAS) instantiates application's forms and recursively scans containing objects.

FAS maps each member control into HTML/CSS/JavaScript with an ‘ID’ reflecting its position in the containment tree.
Each event implemented in a Visual FoxPro control is also implemented in its HTML counterpart (except some very few VFP events which do not map exactly the same into HTML).

Event capture and processing

All HTML DOM events are handled by a single standard FoxInCloud JavaScript method: FoxInCloud.DOMEvent().

FoxInCloud.DOMEvent() retrieves id of event’s target object, value chosen by user when applicable, keyboard and mouse status, then transmits these data to the server via AJAX.
Based on object’s HTML ID, FoxInCloud Application Server retrieves a reference to the matching VFP control, and executes the method of the event occurred in the browser's HTML page.

User state management

FoxInCloud Application Server (FAS) maintains the state of each form for each user by saving on disk its key properties and the data session where the form operates (either private or default, including buffered data).

Before executing an event on a form, FAS restores the form’s state (properties and data session, including buffered data) for the requesting user based on a 9-character user identifiers carried along requests.
After event execution, FAS saves the same set of properties into a new state file and compares with the latter.
FAS maps each modified visual property into an update instruction in the HTML, CSS and JavaScript syntax. This set of instructions is then returned to client (FoxInCloud.js) for execution on the HTML page contents.

The user state storage delay is adjustable on line; default is 4 weeks.

Modal forms

Application stores user’s choice into a property of the Visual FoxPro form that developer can define; FoxInCloud replicates this property on the matching HTML form automatically. When user closes HTML form, FoxInCloud JavaScript sends user’s choice to FoxInCloud Application Server (FAS). FAS then provides this value to the specified form callback method. User’s choice can be of any type: string, number, date, object, etc.

Server Support Scope

Executing your application within a Visual FoxPro web server drives some easy-to-implement rules:

  • Shared resources: as FAS instantiates forms only once for all users and maintains these instances alive, Form.Init() should only execute code depending on parameters or presence of member objects; code that is independent of the user context should be executed by Form.Load().
    Similarly, as Form.Destroy() does not execute when user closes a form, some of its code should be moved to Form.Release().
  • Stateless: as several FoxInCloud Application Servers may execute in parallel (up to 32 on the same physical server, several server can serve requests in parallel), each request must restore the whole user context on each request. Any property shared between user events should be saved on disk, by adding to the object.wcPropSave property inherited from FoxInCloud base classes.
  • Asynchronism: modal forms’ callback code must lie in a separate method of the same form or one of its member objects.

Besides, you have 3 solutions to enhance graphic rendering of your VFP application to a modern Web app.:

  • Style sheet: as visual properties are stored in a CSS file separate from the HTML, any of them may be replaced by a CSS directive using object’s ID or class as CSS selector, stored in application's CSS file (xxx.css);
  • Custom HTML rendering: each class and object can build its own HTML overriding standard rendering;
  • JavaScript: any object or class behavior may be enhanced through additional JavaScript code added to generated HTML.

LAN Web Visual FoxPro database synchronization

If your application uses a VFP database, as updates can occur either on LAN (desktop) or Web instances of the application, FoxInCloud provides a bi-directional synchronization class between Web and local databases.
This class can be easily integrated into the LAN version of the application.


Independent of application architecture


  • Data and business logic are protected on the server: only UI orders are transmitted over the wire, client code deals with UI updates only; HTTP requests never include any SQL command.

A great user experience

  • Only updated elements being refreshed, the HTML page is visually stable
  • When coming back to a form, user retrieves it in the state as of previous connexion
  • Generated default HTML 5 / CSS / JS is fully standard, W3C compliant, compatible with any browser.
  • App Look & Feel can be easily customized through custom HTML, CSS and/or JS
  • Web application behaves the same as legacy desktop app: users are immediatly productive without additional training
  • Average server response time is around .5 second


  • Memory consumption and response time do not depend on the number of simultaneous users
  • Number of objects, containers and events are only limited by available memory
  • Up to 32 FoxInCloud Application Servers can run simultaneously on the same machine; based on experience, each server can deal with up to 10 concurrently active users