FoxInCloud blog

Enhance your FiC Application look and feel with a Web Designer!

Wed, 05 Sep 2018 00:00:00 +0200

Wanna provide your Web Application users a unique experience?

Hire a Web designer to enhance your FoxInCloud Application’s look and feel!

This post explains how you can collaborate with a Web Designer and finally integrate his/her work into your FoxInCloud Application.

1. Let your Web Designer be creative

Once your application is ‘conventionnally’ adapted, you can just install a Test Version on your production server that you can showcase to the designer:

purpose of the Application,
target audience,
key forms and controls,
key steps requiring user’s attention,
graphic patterns in the industry (symbols, colors, etc.),
competition apps,
etc.

The designer will work and present you a mockup showing his/her ideas on how your application can graphically improve; this mockup can either be a slide show or a video showing some typical operation on the Application.

Once you validate this mockup ¹, the designer will create the HTML/CSS/JS templates that you’ll later inject into your application.

Here is a video showing this whole Web Design process on a live FoxInCloud application ²:

2. Integrate the Web Design into your Web Application

Let’s see how we can change this button named designation:

into this web design:

a- Add the Designer’s CSS and JS to your Web Application

If your Web designer has written his/her own CSS and/or JS files, and/or has used some specific CSS/JS library ,³ you can either:

copy and paste into your application’s standard xxx.css and xxx.js ⁴
copy the designer’s file into your application’s site folders ⁵ and implement the xxxProcess.cawCSSinc() and/or xxxProcess.cawJSinc() method like in the example below:

* ------------------------------------------------------------
PROTECTED FUNCTION cawCSSinc && <link rel="stylesheet" /> {en} for additional CSS files {fr} des CSSs FoxInCloud, des CSS de l'application et des Fichier CSS additionnels
LPARAMETERS ;
  tcCSSadd; && [''] {fr} Fichier CSS additionnels
, toForm as awFrm of aw.vcx; && {en} Reference to form && {fr} Référence au formulaire
, tcForm; && {en} form.Name {fr} Nom du formulaire

return DoDefault(;
     'css/animate.min.css, css/hover.min.css, ' + m.tcCSSadd; && {en} add custom CSS before standard CSS
    , m.toForm;
    , m.tcForm;
    )

This method adds these HTML directive to every page of your application ⁶:

<link type="text/css" rel="stylesheet" href="/css/animate.min.css">
<link type="text/css" rel="stylesheet" href="/css/hover.min.css">
<link type="text/css" rel="stylesheet" href="/xxx.css">

b- Generate HTML matching what the Designer wrote

In VFP, this designation button is in fact based on a container class named boutonlarge_png, holding several images around the button itself:

FoxInCloud generates HTML accordingly ⁷:

<div id="dooxi_scx-pageframe1-pagbien-designation" class="container awcnt vhccnt bouton_png boutonlarge_png dooxi_scx-pageframe1-pagbien-designation">
    <img id="dooxi_scx-pageframe1-pagbien-designation-image" class="awimg vhcimg image dooxi_scx-pageframe1-pagbien-designation-image" src="Images/bp_designation.png" style="display:none;">
    <img id="dooxi_scx-pageframe1-pagbien-designation-image_d" class="awimg vhcimg image dooxi_scx-pageframe1-pagbien-designation-image_d" src="" style="display:none;">
    <button type="button" id="dooxi_scx-pageframe1-pagbien-designation-bouton" class="commandbutton awcmd vhccmd dooxi_scx-pageframe1-pagbien-designation-bouton ecrire" tabindex="18">DÉTAIL</button>
    <img id="dooxi_scx-pageframe1-pagbien-designation-ok" class="image awimg vhcimg dooxi_scx-pageframe1-pagbien-designation-ok" src="Images/ok_b.png" alt="ok_b" style="display:none;">
</div>

However the designer has come up with a pretty different (and much more simple) HTML markup ⁸:

<button class="doo-btn-icon hvr-radial-out hvr-shadow diagnostiqueur">
    <span></span><div></div>DÉTAIL
</button>

Using the boutonlarge_png.wcHMTLgen() method, we then replace the whole HTML that FoxInCloud would have generated by custom HTML ⁹:

LPARAMETERS toHTMLgen AS awHTMLgen OF awHTML.prg, tlInnerHTML && {en} doc in Parent Code {fr} doc dans le code parent

if thisForm.wBSlHTMLgen && Generating HTML in Bootstrap mode
  this.wcHTML = '';
   + '<button';
   + ' id="' + this.wcID + '"';
   + m.toHTMLgen.cClass(); && class="" attribute generated by FoxInCloud
   + m.toHTMLgen.cStyle('display'); && style="" attribute generated by FoxInCloud
   + m.toHTMLgen.cEvents(); && Let FoxInCloud generate the event handlers in JS
   + '><span></span><div></div>'; && here is the Web designer's trick...
   + Upper(Alltrim(Strtran(this.Caption, '\<')));
   + '</button>'
endif

The HTML stored into the .wcHTML property replaces whatever HTML FoxInCloud would have normally generated for any object instance of this class or any of its sub-class.

Of course you can overwrite this method in any sub-class or instance of this class to keep by exception the default HTML, or further customize the custom HTML.

This video shows how the application behaves with all design enhancements implemented:

Better change now than later, when the whole process is finished… take some time to think with fresh ideas, and do give all the necessary feedback to the designer… always in a positive manner of course. ↩
Courtesy from the graphic designer for this Application: Mr. Eric Valcke, Trait Creatif ↩
other than the libraries already included in FoxInCloud like jQuery, Bootstrap, etc. ↩
where xxx is the 2-4 character code that you’ve chosen during FAA step 3-Publish ↩
site/xxxTest and site/xxxProd beneath your application folder ↩
Using m.toForm and m.tcForm, you can load libraries only for the forms that need them ↩
<div> is the FoxInCloud standard HTML markup to render a VFP container. ↩
Designer uses embedded <div> and <span> to easily add a background image using a simple CSS rules such as button.diagnostiqueur div {backgound-image: ...} or button.diagnostiqueur span {backgound-image: ...}; this markup allows having several images ‘behind’ the same button, that one can only do in VFP using the ‘contained images’ technique. ↩
We just copy and paste the HTML from the designer and let FoxInCloud compute some critical attributes such as id= class=, style=, and the event handlers ↩

FoxInCloud 2.27 works around a VFP bug to reach 99.99% availability

Mon, 06 Aug 2018 00:00:00 +0200

Once in a while, on applications under heavy load, we’ve faced situations where some grids suddenly lost their columns, meaning that their (.RecordSource) was unexpectedly USE IN.

After double checking the FoxInCloud code, seeing no correlation with the type of .recordSource (table, view or cursor), we progressively circumscribed the problem within an area of code where the contents of the grid is turned into XML for state comparison.

And finally we found what was going on…

VFP CursorToXML() bug

Yes, you read it right, the VFP CursorToXML() function has a bug!

Under certain conditions that honestly we could not isolate, maybe once out of 20,000 calls, without any obvious relation with the data contained in the cursor, CursorToXML() sometimes returns this XML:

<?xml version = "1.0" encoding="Windows-1252" standalone="yes"?><VFPData</VFPData>

Looks like an error in the pointer when writing the closing tag </VFPData> resulting in a malformed XML, and containing no data at all!

If you wish to investigate this bug, you can download here sample data that CursorToXML() has failed to properly convert while in production, all resulting in the XML shown above.

And if you attempt to convert these sample data with CursorToXML() on your dev. machine, it’ll most probably succeed…
That can probably be called an ‘intermittent bug’!

Workaround

FoxInCloud processes all CursorToXML() through a central function: cXMLofCursor().

Whenever it finds mismatched < or > in the result from CursorToXML(), cXMLofCursor() simply builds the XML string by scanning the cursor’s rows and columns. This obviously takes a little overhead however it happens only once in thousands calls and is 100% successful.

Result: four-nine availability

After solving this VFP bug, applications in production now meet the highest standards for availability, over 99.99%:

Special thanks

We could not have successfully achieved such a difficult debug without the close cooperation and help of our friends of the FoxInCloud users community!

Many thanks to the FoxInCloud users¹ who accepted to share logs, put experimental code into production, with sometimes failures and moments of discouragement… We finally did it: turned down a VFP bug that has spoiled us for quite a while…!

Wait, version 2.27 brings more than just a bug fix!

Out of the 15+ enhancements and fixes brought by version 2.27.0, let’s focus on 2 that’ll probably suit many VFP developers needs…

Paged grid: faster and updatable

In a Web Application, because of the limited bandwidth, browsing through long lists remains a response time issue.

As VFP application extensively use grids to present long lists of data, FoxInCloud comes with a handy class that turns any VFP grid into a paged grid ² where the whole set of rows is divided into pages of 20-100 rows. The user can:

choose the number of lines per page
by clicking the header of any column where .RecordSource an index: sort by left-click, filter by right-click
move to given page by typing its number
navigate between page by clicking arrows
seamlessly move to the previous or next page just by browsing past the first or last line in the page

The paged grid in action on FoxInCloud Live Tutorial:

Until this version 2.27.0, the data displayed in the grid were those of a cursor built from the grid.recordSource, and replacing the corresponding columns.controlSource. Because of that design, building a page with a large [col * row] count could take some time and the grid could hardly be updateable.

Starting with V 2.27.0, awCntGrdPage:

builds the page cursor with only the unique keys of the records that appear on the page, in the suitable order,
sets this one-key column cursor as the grid.recordSource,
sets a relation from the page cursor to the original grid.recordSource on the key columns ³,
keeps the columns.controlSource unchanged, pointing on the original grid.recordSource Alias, and/or related Aliases.

awCntGrdPage.wlCntGrcCSpageCursor lets you switch between the legacy and the new behavior:

.T. (current default) – legacy behavior: redirect columns.controlSource to the page cursor
.F. (future default) – new behavior: keep columns.controlSource and set a relation from the page cursor into the original grid.recordSource

Surface Events Live Tutorial

Surface Events –or Client-side Events– are events that trigger fast and alter only the aspect of the display and/or static contents, and thus don’t require an interaction with the data on the server: .MouseEnter(), .MouseMove(), .MouseLeave(), .KeyPress(), .InteractiveChange()

In short Surface Events only affect the surface of the application without requesting the server.

As they must entirely be processed on the client browser, Surface Events are the only area of a FoxInCloud application where the VFP developer must write some JavaScript and/or CSS code.

FoxInCloud Live Tutorial now provides an on-line sample form where all possible alternative techniques for writing such code are discussed:

The corresponding blog post and video provide additional detailed explanation.

Special thanks to Gilles Lajot-Sarthou (among others) ↩
modify class awCntGrdPage of aw.vcx; this class requires that grid.recordSource has at least a unique key (primary or candidate) ↩
whenever grid.recordSource is already the target of a relation, behavior automatically switches back to legacy and grid is set to read-only ↩

Adapting 'Surface Events'

Wed, 11 Jul 2018 00:00:00 +0200

We call Surface Events – or Client-side Events – events that trigger fast and only alter the aspect of the display and/or static contents, and thus don’t require an interaction with the data on the server.

In short Surface Events only affect the surface of the application without requesting the server.

In FoxInCloud Live Tutorial’s Controls and Events form, surface events are those listed in the bottom left box, namely .MouseEnter(), .MouseMove(), .MouseLeave() and .KeyPress() ¹.

As Surface Events don’t address the server, the VFP code can’t run as for the default FoxInCloud behavior: some ‘pure web’ code – JavaScript and/or CSS – is required!

This post explains how to take advantage of the powerful Web languages – especially CSS – to replace several VFP instructions and methods by a handful of CSS ‘directives’.

The adaptation statistics shared by developers reveal that Surface Events adaptation account for an average 10% of the total adaptation effort, so hopefully this post can help you save time in this area.

From a Web perspective, Surface Events (SE) break down into 2 categories:

SE altering display of contents only
SE altering contents itself

As usual for this blog, this post relies on the FoxInCloud Live Tutorial, namely the Surface Event form:

Surface Events altering display only

Influenced by the Web look and feel, it is quite common for a Desktop Application to suggest an interaction to the user using visual effects; eg. when user hovers a control with the mouse, change its forecolor and/or backcolor.

If you have such effect in your Desktop Application, you obviously want a similar effect to happen in your FoxInCloud Web Application.

Of course, due to the speed of such event, the standard FoxInCloud mechanism – execute the corresponding FoxPro Event code on the server – would be unusable to achieve the effect: things must happen right on the client browser.

Buttons in the Surface Event form are derived from this a class: modify class ficCmdHover of home(1) + 'tools\ab\aw\sample\fic\class\ficSample'. After running FAA step 2, its code looks like this ²:

PROCEDURE Init
* {en} create properties to save current aspect
this.AddProperty('FontBold_', this.FontBold)
this.AddProperty('BackColor_', this.BackColor)
this.AddProperty('ForeColor_', this.ForeColor)
return DoDefault()

* ---------------------------------------------
PROCEDURE MouseEnter
lparameters nButton, nShift, nXcoord, nYcoord && {en} doc in Parent Code

IF (Type('m.thisForm.wlHTMLgen') == 'L' AND m.thisForm.wlHTMLgen) && {en} Added by FoxInCloud base classes Manager (source mode)
  return .F.
endif

* {en} save current aspect
this.FontBold_  = this.FontBold
this.BackColor_ = this.BackColor
this.ForeColor_ = this.ForeColor

* {en} set hover aspect
this.FontBold  = !this.FontBold
this.BackColor = 0 && black
this.ForeColor = Rgb(255,255,255) && white

* ---------------------------------------------
PROCEDURE MouseLeave
lparameters nButton, nShift, nXcoord, nYcoord && {en} doc in Parent Code

IF (Type('m.thisForm.wlHTMLgen') == 'L' AND m.thisForm.wlHTMLgen) && {en} Added by FoxInCloud base classes Manager (source mode)
  return .F.
endif

* {en} restore previous aspect
this.FontBold = this.FontBold_
this.BackColor = this.BackColor_
this.ForeColor = this.ForeColor_

By default in Surface Events code, FAA has added RETURN .F. to prevent FAS from implementing an event handler that would send the event to the server.

Below we’ll see how to implement a similar effect on the web using JavaScript, CSS, or both ³.

Solution 1. Using JavaScript only

Using JavaScript is the method closest to what we used to do in VFP; however it takes limited advantage of more powerful Web techniques.

Here are some hints for understanding the code below:

FoxInCloud considers non-empty string value that event method returns from within if m.thisForm.wlHTMLgen … endif as JavaScript code to be executed in the browser when a similar event occurs,
We use the textmerge keyword to easily combine JavaScript code and VFP values
Each adapted VFP object inherits a .wcID property that FoxInCloud populates with a unique ID at runtime ⁴; it also uses this ID to populate the id and class attributes when generating the corresponding HTML element.
jQuery is a popular JavaScript framework (library) that FoxInCloud installs and loads automatically; jQuery('#id') selects the element in the page having ‘id’ as id="" attribute (see previous point), and exposes methods that alter the HTML element and/or its CSS
To change the HTML element’s aspect, we use the jQuery .css() method with an object as parameter; each property of this object is named as the corresponding CSS property
{"property": value, "property": value, …} is called JavaScript Object Notation (JSON), in other word a literal representing an object ⁵
Regarding line termination, JavaScript and VFP work the other way round: JS uses ‘;’ as instruction terminator, instructions without a closing ‘;’ continue on next line
Block comment /* comment */ can be located anywhere, even inside an instruction

PROCEDURE MouseEnter
lparameters nButton, nShift, nXcoord, nYcoord && {en} doc in Parent Code

DoDefault() && see code in parent class

* {en} We change the HTML element's style directly with jQuery.css() with an object using JSON syntax as parameter
* {en} This technique is the closest to what you're used to do in VFP, however not very 'web-aware'…
* {en} Note that you can see the HTML changing in the browser development tools

IF (Type('m.thisForm.wlHTMLgen') == 'L' AND m.thisForm.wlHTMLgen) && {en} Added by FoxInCloud base classes Manager (source mode)

  local lcJS
  text to lcJS textmerge noshow flags 1 pretext 15
    jQuery(".<<this.wcID>>").css({ /* jQuery() creates an object around the HTML element(s) with a '.css()' method */
        "font-weight": "bold"
      , "color": "white"
      , "background-color": "black"
     }); /* End of instruction starting with 'jQuery(' */
  endtext
 
  RETURN m.lcJS && {en} FoxInCloud interprets a non-empty string as JavaScript to be executed when event occurs
endif

* ----------------------------------
PROCEDURE MouseLeave
lparameters nButton, nShift, nXcoord, nYcoord && {en} doc in Parent Code

DoDefault() && see code in parent class

* {en} We change the HTML element's style directly by passing an object using JSON syntax to jQuery.css()
* {en} This technique is the closest to what you use to do in VFP, however not very 'web-aware'…
* {en} Note that setting the back color back to what is in VFP may contradict what you expect from a CSS framework such as Bootstrap…
* {en} Also note that you can see the HTML changing in the browser development tools

IF (Type('m.thisForm.wlHTMLgen') == 'L' AND m.thisForm.wlHTMLgen) && {en} Added by FoxInCloud base classes Manager (source mode)

  local lcJS
  text to lcJS textmerge noshow flags 1 pretext 15
    jQuery(".<<this.wcID>>").css({ /* jQuery() creates an object around the HTML element(s) with a '.css()' method */
        "font-weight": "<<Iif(this.FontBold_, 'bold', 'normal')>>"
      , "color": "<<HTMLColor(this.foreColor_)>>"
      , "background-color": "<<HTMLColor(this.backColor_)>>"
     }); /* End of instruction starting with 'jQuery(' */
  endtext

  RETURN m.lcJS && {en} FoxInCloud interprets a non-empty string as JavaScript to be executed when event occurs
endif

Note that this code changes the HTML of the element, and this change can be observed in the browser developer tool:

HTML of the button before hovering:

<button type="button" id="eventclient_scx-pgf-pagaspect-cmdjs"
class="eventclient_scx-pgf-pagaspect-cmdjs btn btn-default btn-lg"
tabindex="330" data-original-title="eventclient_scx.pgf.pagAspect.cmdJS">
JavaScript only
</button>

After hovering the button, the style attribute is set:

<button type="button" id="eventclient_scx-pgf-pagaspect-cmdjs"
class="eventclient_scx-pgf-pagaspect-cmdjs btn btn-default btn-lg"
tabindex="330" data-original-title="eventclient_scx.pgf.pagAspect.cmdJS"
style="font-weight: normal; color: rgb(0, 0, 0); background-color: rgb(240, 240, 240);">
JavaScript only
</button>

Note that this JavaScript-driven alteration of HTML style attribute (AKA inline style) takes precedence over the rules defined in CSS files. In the Bootstrap version of the ‘Surface event’ form, we’ve implemented a reminder that appears when mouse leaves the ‘JavaScript only’ button:

Solution 2. Using JavaScript and CSS

In this second example, we’ll define a class-based CSS rule in the application’s custom CSS file tuto.css ⁶ and, when mouse enters/leaves, dynamically add/remove this class to/from the HTML object.

Again, as the class attribute is part of HTML, we need JavaScript to alter its value, and jQuery will also come to the rescue to simplify the code, namely its .addClass() and .removeClass() methods ⁷

Here are some hints for understanding the code below:

As a variation, in jQuery(".<<this.wcID>>"), we use a class selector (‘.’) instead of an id selector (‘#’). You can use either one as FoxInCloud automatically assigns the same unique string (eventclient_scx-pgf-pagaspect-cmdjscss) as ID and class:

<button type="button" id="eventclient_scx-pgf-pagaspect-cmdjscss"
class="eventclient_scx-pgf-pagaspect-cmdjscss btn btn-default btn-lg"
title="eventclient_scx.pgf.pagAspect.cmdJSCSS" tabindex="331">
JavaScript + CSS
</button>

a rule is defined in tuto.css with the class selector .cmd_Hover ⁸:

.eventclient_scx button:not([disabled]).cmd_Hover {
  font-weight: bold;
  color: white;
  background-color: black;
}

The selector .eventclient_scx button:not([disabled]).cmd_Hover means: any button that is a descendant of an element of class eventclient_scx (the form), is enabled and has class cmd_Hover.

PROCEDURE cmdJSCSS.MouseEnter
  lparameters nButton, nShift, nXcoord, nYcoord && {en} doc in Parent Code

  DoDefault() && see code in parent class

  * {en} In this method, we add a HTML class on .MouseEnter(), and remove it on .MouseLeave()
  * {en} We define the CSS rule applicable to class 'cmd_Hover' in the application CSS file:
  * {en}   modify file tuto.css ; we can update this file separately from the application.
  * {en} Note that we use '_' and capital letters in the custom class name; it can't conflict with framework class name that never use these characters

  IF (Type('m.thisForm.wlHTMLgen') == 'L' AND m.thisForm.wlHTMLgen) && {en} Added by FoxInCloud base classes Manager (source mode)
    RETURN Textmerge([jQuery(".<<this.wcID>>").addClass('cmd_Hover');])
  endif
ENDPROC

PROCEDURE cmdJSCSS.MouseLeave
  lparameters nButton, nShift, nXcoord, nYcoord && {en} doc in Parent Code

  DoDefault() && see code in parent class

  * {en} In this method, we add a HTML class on .MouseEnter(), and remove it on .MouseLeave()
  * {en} We define the CSS rule applicable to class 'cmd_Hover' in the application CSS file:
  * {en}   modify file tuto.css ; we can update this file separately from the application.
  * {en} Note that we use '_' and capital in custom class name; it can't conflict with framework class name that never use these characters

  IF (Type('m.thisForm.wlHTMLgen') == 'L' AND m.thisForm.wlHTMLgen) && {en} Added by FoxInCloud base classes Manager (source mode)
    RETURN Textmerge([jQuery(".<<this.wcID>>").removeClass('cmd_Hover');])
  endif
ENDPROC

Note that the browser (re)evaluates the CSS rules dynamically – and immediatly – whenever any component of the rules changes in HTML.

Solution 3. Using ‘pure’ CSS, version 1

The previous case has unveiled the power of CSS selector syntax that can work on:

element position in the page hierarchy tree: descendant, child, sibling, first-of, last-of, etc.
element attributes: #id, .class and any other HTML attribute
element state :disabled, :checked, :hover, etc. ⁹

The :hover state fulfills what we need in this case: change the element’s aspect when mouse hovers it.

In this solution, we’ll add a rule to the CSS rules that FoxInCloud generates into a file named awDefault*.css ¹⁰.

We add this rule in the .wcHTMLgen() method that the object inherits from the aw??? FoxInCloud ‘base class’ and that FoxInCloud runs when generating the HTML for this object, at first time the containing form is required, and using the .CSScustomAdd() method.

Here are some hints for understanding the code below:

toHTMLgen AS awHTMLgen OF awHTML.prg is a reference to the FoxInCloud HTML generator that drills into the form and containers until each individual member;
Depending on the value that this method RETURNs and/or writes into .wcHTML, the HTML generator toHTMLgen generates standard or custom HTML;
.wcHTMLgen() can be implemented at any level of the VFP class hierarchy, making it possible to make the Web behavior specific to an object or all objects of a given VFP class;
The .CSScustomAdd() method adds custom CSS rules to the standard awDefault*.css style sheet, that the custom style sheet xxx.css can override if needed.

PROCEDURE cmdCSS1.wchtmlgen
  LPARAMETERS toHTMLgen AS awHTMLgen OF awHTML.prg, tlInnerHTML && {en} doc in Parent Code

  DoDefault(m.toHTMLgen, m.tlInnerHTML)

  * {en} Add a ':hover' CSS rule on this object (could be several objects using a class instead of an ID)
  * {en} FoxInCloud adds this rule to the generated default CSS style sheet for application: awDefault*.css
  && {en} note 1: in CSS pure language, ':hover' is called a 'pseudo-class'; browser development tools use this wording
  && {en} note 2: that JS and CSS syntaxes are close; however in CSS directives are unquoted and separated by ';' instead of ','
  && {en} note 3: this rule automatically restores initial aspect when mouse leaves the button

  local lcCSS

  text to lcCSS textmerge noshow flags 1 pretext 15
    #<<this.wcID>>:hover {
      font-weight: bold;
      color: white;
      background-color: black;
     }
  endtext

  m.toHTMLgen.CSScustomAdd(m.lcCSS)
ENDPROC

This solutions works fine for a small number of controls, however, if all controls of a given BaseClass must have a similar behavor, the solution 4 hereafter is more efficient.

Solution 4. Using ‘pure’ CSS, version 2

This solution combines several features that we’ve gone through in the previous solutions:

.class CSS selector: we will a class to the generated HTML element and build a CSS rule based on this custom CSS class
:hover pseudo class; our custom CSS rule will focus on the :hover state of the custom CSS class above
custom CSS class upon HTML generation besides .wcHTMLgen(), each adapted VFP object inherits a .wCSSclassAdd property where you can define additional CSS classes that the FoxInCloud HTML generator will add to the generated HTML element. You can manipulate this property either at design time, using the VFP visual designer, or at run time, in .Init() or form.Load() ¹¹

PROCEDURE cmdCSS2.Init
  * {en} add a CSS class to this object
  * {en} note 1: a 'cmd-hover2:hover' rule is defined in tuto.css (custom style sheet for this application)
  * {en} note 2: could also be done at design time in property sheet; we prefer do it programmatically in case the parent class also has this property defined
  * {en} note 3: we could also add this CSS class to the parent class (ficCmdHover) to have all derived buttons behave this way

  this.wCSSclassAdd = this.wCSSclassAdd;
    + Iif(empty(this.wCSSclassAdd), '', ' ');
    + 'cmd_Hover2'

  return DoDefault()
ENDPROC

tuto.css defines the corresponding CSS rule:

.eventclient_scx button:not([disabled]).cmd_Hover2:hover {
  font-weight: bold;
  color: white;
  background-color: black;
}

As tuto.css can be updated in production separately from the app, changing the behavior (eg. background-color) does not require updating the application.

Surface Events altering contents

Altering HTML contents always require JavaScript; CSS can alter the aspect of contents only, not the contents itself.

To change HTML contents, we also use jQuery and its utility methods:

.prop(): creates or reads a property of the HTML element
.text(): replaces or reads the text inside HTML paired tags ¹²

Note that FoxInCloud detects the user browser’s preferred language as a 2-letter ISO 639 code and stores it into:

client side: FoxInCloud.lang
server side: thisForm.wcLangUser (inherited from aw.vcx!awFrm)

PROCEDURE cmd.Init
  this.AddProperty('Caption_', '')
  return DoDefault()
ENDPROC

PROCEDURE cmd.MouseEnter
  lparameters nButton, nShift, nXcoord, nYcoord && {en} doc in Parent Code

  local caption_FR, caption_DE, caption_IT, caption_ES, caption_PT, caption_EN

  caption_FR = "Vous me survolez"
  caption_DE = "Du schwebst mich"
  caption_IT = "Mi stai sorvolando"
  caption_ES = "Me estás rondando"
  caption_PT = "Você está me pairando"
  caption_EN = "You're hovering me"

  IF (Type('m.thisForm.wlHTMLgen') == 'L' AND m.thisForm.wlHTMLgen) && {en} Added by FoxInCloud base classes Manager (source mode)

    && {en} This code executes first time server instantiates the form, once for all users
    && {en} As this code executes out of a user context, the user language is not known and must be evalutated at run time
    && {en} At run time, FoxInCloud detects user browser's preferred language and stores it in FoxInCloud.lang (coded on 2 letters as per ISO 639-1 https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes)
    && {en} The JavaScript code below adjusts the contents to the user's language

    local lcJS

    text to lcJS textmerge noshow flags 1 pretext 7
      var cmd = jQuery('#<<this.wcID>>'); /* get a reference to the jQuery object wrapped around this HTML element */
      cmd.prop('Caption_', cmd.text()); /* Save current Caption to a new property of this element created on the fly */
      var newText = '';
      switch (FoxInCloud.lang) { /* https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Instructions/switch */
      case 'fr':
        newText = <<cLitteralJS(m.Caption_FR)>>;
      case 'de':
        newText = <<cLitteralJS(m.Caption_DE)>>;
      case 'it':
        newText = <<cLitteralJS(m.Caption_IT)>>;
      case 'es':
        newText = <<cLitteralJS(m.Caption_ES)>>;
      case 'pt':
        newText = <<cLitteralJS(m.Caption_PT)>>;
      default:
        newText = <<cLitteralJS(m.Caption_EN)>>;
      }

      /* We can also use a syntax similar to ICase() by nesting ternary operators similar to Iif() [condition ? value if true : value if false] …
      slight downside: nested operators need be wrapped inside parentheses for some browsers (eg. IE).
      Below we indent the closing parentheses the same as the opening counterpart to visually prevent nesting errors */

      newText = FoxInCloud.lang === 'fr'
        ? <<cLitteralJS(m.Caption_FR)>>
        : (FoxInCloud.lang === 'de'
          ? <<cLitteralJS(m.Caption_DE)>>
          : (FoxInCloud.lang === 'it'
            ? <<cLitteralJS(m.Caption_IT)>>
            : (FoxInCloud.lang === 'es'
              ? <<cLitteralJS(m.Caption_ES)>>
              : (FoxInCloud.lang === 'pt'
                ? <<cLitteralJS(m.Caption_PT)>>
                : <<cLitteralJS(m.Caption_EN)>>
          ) ) ) );

      cmd.text(newText + '…!'); /* Assign new caption to the button */
    endtext

    RETURN m.lcJS && {en} FoxInCloud interprets a non-empty string as JavaScript to be executed when event occurs
  endif

  && {en} This code executes in desktop mode only

  this.Caption_ = this.Caption

  this.Caption = ICase(;
    thisForm.wcLangUser = 'fr', m.caption_FR,;
    thisform.wcLangUser = 'de', m.caption_DE,;
    thisform.wcLangUser = 'it', m.caption_IT,;
    thisform.wcLangUser = 'es', m.caption_ES,;
    thisform.wcLangUser = 'pt', m.caption_PT,;
    m.caption_en;
    ) + '…!'
ENDPROC

PROCEDURE cmd.MouseLeave
  lparameters nButton, nShift, nXcoord, nYcoord && {en} doc in Parent Code

  IF (Type('m.thisForm.wlHTMLgen') == 'L' AND m.thisForm.wlHTMLgen) && {en} Added by FoxInCloud base classes Manager (source mode)

    && {en} This code executes first time server instantiates the form, once for all users
    && {en} As this code executes out of a user context, the user language is not known and must be evalutated at run time
    && {en} At run time, FoxInCloud detects user browser's preferred language and stores it in FoxInCloud.lang (coded on 2 letters as per ISO 639-1 https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes)
    && {en} The JavaScript code below adjusts the contents to the user's language

    local lcJS

    text to lcJS textmerge noshow flags 1 pretext 7
      var cmd = jQuery('#<<this.wcID>>'); /* get a reference to the jQuery object wrapped around this HTML element */
      cmd.text(cmd.prop('Caption_')); /* Assign previous saved caption to the button */
    endtext

    RETURN m.lcJS && {en} FoxInCloud interprets a non-empty string as JavaScript to be executed when event occurs
  endif

  && {en} This code executes in desktop mode only

  this.Caption = this.Caption_
ENDPROC

Wrap-up

Hopefully this post has teached you the important basics of CSS and JS programming, and the main hooks where FoxInCloud lets you add this client-side code to your application:

CSS selectors
jQuery and its utility methods
FoxInCloud CSS: awDefault*.css and xxx.css
In VFP event methods, return JavaScript from within if m.thisForm.wlHTMLgen … endif
.wcHTMLgen() for generating custom HTML, CSS and/JS
.wCSSclassAdd for adding CSS class(es) to one object or all objects derived from a class
toHTMLgen.CSScustomAdd() to add custom CSS rules

Video

on some controls like textBox, .InteractiveChange() also falls into the ‘Surface Event’ category, that FoxInCloud will soon support using the recent HTML DOM Event level 3 API .oninput() ↩
Button instances in EventClient.scx call this form using dodefault() ↩
As you may be aware of, HTML defines the contents and structure, and CSS defines how this content and structure appears to the user. Events occurring in the browser execute JavaScript code that can alter HTML, CSS or both. In earlier versions on HTML, some HTML tags and attributes could influence the aspect (such as <b>, <i>, width, align, background, etc.); today these tags and attributes are fully deprecated and should no longer be used. Visual FoxPro works with similar principles except Layout properties are just a category in the visual designers and follow the same logic as any other class or object property ↩
this ID concatenates .Name of form, object parents and object itself ↩
VFP does not offer a similar ability to represent an object as a literal; conversely JavaScript misses the date and date-time literal feature like in VFP. Note that JavaScript accepts the dash (‘-‘) character inside property names, which VFP rejects … each language has its pros and cons… ↩
named after the FoxInCloud Web App xxx code – tuto.css in this case – the App custom CSS file xxx.css is loaded by FoxInCloud on each page/form, after all other CSS files, particularly the default, FiC-generated awDefault*.css. This gives the ability to (1) override any standard CSS directive and (2) define custom directives. ↩
note the camel case convention: in the ‘Web world’, everything is lower case except the first letter of successive words. ↩
note the block comment has the same syntax as in JavaScript ↩
W3C calls these state modifiers ‘pseudo-classes’ ↩
during development, FoxInCloud dynamically generates awDefault_<sys(2015)>.css, and awDefaultAll.css for production ↩
altering .wCSSclassAdd at run time is advisable for easier maintenance in case .wCSSclassAdd changes in a parent class. ↩
while some tags such as <br> or <img> are unpaired or self-closing, most HTML tags require a closing tag: <p>text</p>, <i>text</i>, <div>text</div>, etc. ↩

Learning FoxInCloud with the FoxInCloud Live Tutorial

Thu, 05 Jul 2018 00:00:00 +0200

Experienced FoxPro Developers using FoxInCloud all around the world need more than an English documentation: live code that they can understand, learn from, and adapt for their own Application.

FoxInCloud provides the FoxInCloud Live Tutorial that developers can use either on line or locally, in the VFP IDE and the http://localhost/ Web site.

The FoxInCloud Live Tutorial (FLT) provides working examples of:

the main cases of adaptation
features and scenarios that maybe you doubt FoxInCloud can support
the full source code of the application:
- forms and classes
- programs
- configuration
- JavaScript and CSS files

In Web mode, you can see the forms using 2 different HTML renderings:

Classic rendering: controls are laid out just like in the original VFP form, with absolute positioning using .left, .top, .width, .height like VFP,
Responsive rendering: controls are laid out similar to the original VFP form, albeit with a relative positioning that automatically adapts to the device screen size ¹: controls that can’t fit in width automatically wrap below their predecessor.

You can also see the forms either as a full page (like a Top Level Form in VFP), or as a child form.

Using the FoxInCloud Live Tutorial on line

Just type in your browser http://foxincloud.com/tutoTest/; you get the classic version:

Note that the menu on the left derives from a tuto.mnx VFP menu, the rest being generated from a VFP form.

This version’s layout does not change according to browser size, it just overflows:

Switching to the Responsive version of FLT

You can display the Responsive version of FLT either by:

clicking the ‘Responsive’ button at the top right of the form
type in your browser http://foxincloud.com/tutoTest/bs/

In both cases you get:

As it’s responsive, this version adapts to the browser’s width (notice that the menu has wrapped on 2 lines, the fox is now hidden and the control buttons are now at the bottom):

The layout further changes when narrowing further the browser width (notice the menu collapsed to a ‘hamburger’ menu):

Displaying the same form as a full page or as a child form

Let’s display the ‘Controls & Events’ form which demonstrates the range of VFP Controls and Events that FoxInCloud supports:

1. as a full page

In the ‘Support’ menu, select the ‘Controls & Events’ pad:

You get the ‘Controls & Events’ form displayed as a full page:

2. as a child form

Get back to ‘home’ and click the ‘Controls & Events’ button:

You get the ‘Controls & Events’ form displayed as a child form:

Note that both forms share the exact same code and expose the exact same functionalities – go ahead testing!

The benefit of displaying a form as a full page is that you can provide a direct link to any form: eg. http://foxincloud.com/tutotest/bs/Event.tuto

Displaying the same form in ‘Responsive’ and ‘Classic’ modes

In the ‘Support’ menu, select the ‘Controls & Events’ pad:

You get the ‘Controls & Events’ form displayed in ‘Responsive’ mode:

Then click on the ‘Classic’ option button:

You get the same ‘Controls & Events’ form in classic mode:

Reviewing the source code of some VFP object

The FoxInCloud Live Tutorial gives you the ability to review, on line, the code running in an object just be hovering that object with your mouse.

Open the Modal form (# 1 in ‘Adaptation’ menu):

When hovering any of the buttons in the form, you see the corresponding source code appear in the code frame below:

Ctrl-clicking the code area displays it into a new browser tab ²:

Reviewing the source code of a VFP form

Each form in FLT has a source code button </> to display the full form source code;

click opens VFP code a new child form:

ctrl+click opens VFP code a new browser tab ²:

Getting details about a VFP form

Need more information about a form in FoxInCloud Live Tutorial? Clicking the fox head will tell you more…

Reviewing the full app. source code

Besides code in forms, you can review the full application source code by using the ‘Source’ menu:

Eg., clicking Main program displays the Web Application Server’s main program source code:

Reviewing the FoxInCloud Web Application Dashboard

The FoxInCloud Web Application Dashboard is the central point where you get control over all the operations of your Web Application: errors (if any), users, status, and much more… ³

Debugging your Web Application

Among many other benefits, a Web Application logs about everything you’d dream of knowing to understand and fix errors.

As a standard feature, FoxInCloud provides a very handy Error Browser where you can see what each user has done just before and after each error:

Using the FoxInCloud Live Tutorial locally

Still in doubt about what’s running under the hood? Just run the same features locally, right from within your VFP IDE!

1. Install FoxInCloud Web Application Studio (FWS)

Just follow the steps in this blog post: Managing your FoxInCloud Project

Once you’ve completed these steps,

Start VFP using the FWS shortcut on your desktop:
You now have a FoxInCloud pad in your VFP system menu ⁴:

2. Run FoxInCloud Live Tutorial in Desktop mode

As any FoxInCloud application, FLT runs the same code on the desktop and on the Web… You may want to see first how it goes on the desktop…

You can see the FLT home page:

You can also see in your VFP IDE the FLT LAN/desktop project open that you can explore once you’re done testing the FLT LAN/desktop app:

3. Run FoxInCloud Live Tutorial in Web mode

As the FoxInCloud installation has created the FoxInCloud Live Tutorial Web Application for you, you can start it just by selecting this menu item:

You can see your default browser pop up and loading the FoxInCloud Live Tutorial home page…

… while the FLT Web Application Server is starting within the VFP IDE:

Once the the FLT Web Application Server has started …

… FoxInCloud Live Tutorial home page is loaded in the browser:

When stopping the Application Server using the ‘exit’ button, you can see the Web Application project open in the VFP IDE, from where you can open and explore the full source code:

Video wrap-up

Responsive rendering uses the popular and free Bootstrap framework ↩
you may need to allow popups on foxincloud.com ↩ ↩²
the FoxInCloud Web Application Dashboard requires a secured authentication by default; for the FoxInCloud Live Tutorial, this safety was removed for demo purpose. ↩
captions and menu items may be slightly different in your case depending on the extensions you’ve loaded in VFP ↩

Managing your FoxInCloud Project

Thu, 17 May 2018 00:00:00 +0200

This post describes how to adapt and publish your VFP application as a Web Application from scratch.

With FoxInCloud, your application runs the same code on the Web, and on the Desktop as usual.

This is made possible by adapting your application’s code to run in either mode; these adaptations are simple, and many are automated:

adding new instructions such as testing desktop mode or web mode,
moving instructions to another method without changing the functionality,
replacing native instructions such as DO FORM by calls to functions or methods provided by FoxInCloud.

The free FoxInCloud Adaptation Assistant (FAA, see below) identifies the adaptations in your app., performs as many as possible, and leaves the more complex to your attention. You can open and modify the source code right from FAA, and FAA provides you the guidance on why and how you can do the adaptation.

As the adapted code runs the same in desktop mode, you can adapt your application progressively, while continuing the regular maintenance and evolutions that your daily client service requires.

You can also create a new sub-project with only the forms that you intend to expose to the Web, publish to production, then expand it over time; this project and your regular desktop project share the same adapted files that run in desktop mode side by side with non-adapted files.

All the FoxInCloud resources on which your adapted code relies (installed in home(1) + "tools\ab\") are free to use and distribute with your desktop application. These files are also always available in a public GitHub repository.

Round I: Heat-up

Est. duration: 2 hours

In this first sequence you will verify that you have all the necessary softwares and services installed on your development machine.

1- Make sure you run the latest VFP9 SP2

This VFP command should display Visual FoxPro 09.00.0000.7423 for Windows

? Version()

If the last 4 figures are less than 5815, first download and install VFP9 SP2 from the Microsoft site.

Then download and install SP2 Hotfix 3 from the VFPx site.

2- Install FoxInCloud Adaptation Assistant (FAA)

Go to the FoxInCloud download page, click on the FAA screenshot and save awAdapterSetup.zip. Expand this archive into a sub-folder awAdapterSetup\.

Read the text files awAdapter-licence-*.txt and awAdapterSetup-*.txt (brief description of what awAdapterSetup.exe will do on your computer).

Then double-click the VFP executable awAdapterSetup.exe; if ever you don’t have the proper version of VFP installed or associated to *.exe, you’ll get a ‘VFP resource mismatch’ message, then get back to step 1; otherwise awAdapterSetup.exe copies the necessary files to your computer and displays the result as explained in the awAdapterSetup-*.txt text file.

Clicking OK in the final message box automatically starts FAA: .

Whenever a new version is posted on the FoxInCloud site, when starting while connected to the Internet, FAA downloads and installs this new version automatically.

3- Make sure IIS is installed on your development machine

You can follow different tracks to check IIS is installed (translate the strings into your OS language):

Press the Windows key on your keyboard, type Windows Features, press Enter
In Windows Explorer address bar, type control panel, then select applications, then Turn Windows Features on or off
For Windows 10, open the parameters pane, select Applications, then Application and features, then move to the bottom and select programs and features, then click Turn Windows Features on or off

This displays the Windows Features Treeview:

Check the options like indicated in the above image or, if you hesitate or have difficulties in matching your OS language to this picture, select all options ¹.

Next, to make sure IIS will have the right to access the folder where your application resides:

Open the IIS management console (Press Windows key then type ‘IIS’ and press ‘Enter’),
Navigate to the ‘Sites’ node,
Click “Define the default values for Web sites”,
In the ‘Identification…’ line, click the ellipsis
Type in your user ID and passWord; IIS will use this account to access the folder wherever your Web Application is later installed.

4- Install FoxInCloud Application Server (FAS) and FoxInCloud Web Application Studio (FWS)

Grab FAS for free by signing up your on the FoxInCloud download page ².

The file you download is a signed MSI-based InstallShield installation package, with all due security protections.

Running the installation installs:

The FoxInCloud Application Server in home(1) + 'tools\ab\aw\'
The FoxInCloud Samples in home(1) + 'tools\ab\aw\samples'
The sample applications in IIS that you can run locally
A FoxInCloud Web Application Studio shortcut on your desktop

At this stage you have 2 FoxInCloud shortcuts on your desktop:

FoxInCloud Adaptation Assistant (FAA)
FoxInCloud Web App. Studio (FWS)

In the first steps of your FoxInCloud journey, you’ll probably use more the FAA shortcut and concentrate on Adaptations.

After a while, when you start testing your app in the browser, you’ll favor FWS shortcut that provides you all the resources, including FAA from the FoxInCloud menu added to VFP system menu.

Make spend some time reviewing the options offered by the FoxInCloud menu in FWS!

Round II: Review your application with FAA in Copy Mode

Est. duration: 1-2 days (including readings)

(for more details, please consult this complete description of FAA operations)

As explained earlier, FAA performs some adaptations automatically, modifying your application’s code.

As FoxInCloud’s philosophy is to never break existing code – just add new functionalities on top of existing features – FAA provides a way to check that what FAA does automatically preserves your code’s integrity: the Copy Mode.

In Copy Mode, FAA copies your project and related files to a Test folder ³ and then works on this copy only: FAA leaves your source files unchanged ⁴.

The only purpose of Copy Mode is to let you check that your desktop application runs the same after FAA automated adaptations; after you do a complete run in Copy Mode you will just drop it in favor of Source Mode.

1- Analyze your project copy

Click the red + sign, pick your original project and start analysis.

Completed analysis provides a list of adaptations that you can sort and filter using the controls on top of the grid columns, and statistics at the bottom ⁵.

The mid pane explains how the current adaptation will be performed (either automatically or manually); you can display these explanations as a VFP program with code sample, and/or view a training video when available.

Please note that the estimated adaptation effort is based on unit times that you can adapt to your project experience by clicking the red line “Estimated adaptation time” down right.

2- Adapt your project copy

This step is why Copy Mode exists: by clicking the 2-Adapt button, FAA performs the automated adaptations on your project’s copy.

After this step, you will open the copy project and run your adapted application in desktop mode to make sure that FAA has broken nothing in your code that could prevent your applications from working OK.

If ever you see something wrong, just shoot an email to support at foxincloud dot com with the original code (unchanged in your original application) and the modified, not working code (in your application copy); we will fix the issue rapidly and post a new version of FAA that will update automatically at your next startup.

To re-run Adaptation on the whole source code, make sure to select the “re-copy…” option in the drop down menu that appears when clicking the 2-Adapt button.

Please make sure to test your adapted application copy thoroughly until you find everything works fine as usual in desktop mode!

3- Publish your project copy

This step is just a way for you to make sure that the Web App publication works fine for you with all required dependencies available; it is a temporary publication that the final Source Mode publication will later override.

At least you can see some of your form display in the browser, which you are eager to see happen…

It can also help you understand how the publication wizard works and train at using it.

After this step completes, you have 2 Web projects named xxxTest and xxxProd, located in the same folder as your copy project.
FAA creates 2 projects to let you later deploy 2 versions of your Web Application on the Production Server, one for Testing and one for Production. You may choose to deploy a single application or both according to your preference.

These 2 projects won’t probably not build completely, especially when using the Trial edition where a lot of FoxInCloud code is gathered in aw.app, causing project manager to complain for missing references.
This is perfectly normal and has no consequence as Trial does not support building an app or an exe.

However you can use these projects a shortcuts to the files generated by FoxInCloud ⁶, and later start the Server from within the FWS IDE.

Important: from now on, make sure to always open a FoxInCloud Web Application Studio IDE to work on your adapted application and, most importantly, start your FoxInCloud Web Application Server. If anything goes wrong such as a missing procedure or class, select restore environment from the FoxInCloud system menu pad.

Tips and tricks

Code changes you do in Copy Mode may be overridden next time you Analyze or Adapt because FAA may overwrite your modified copy by the original file. Change code in Copy Mode for training only, and/or to check manually adapted code runs the same in desktop mode.
FAA project-level settings and options are memorized separately for Copy Mode and Source Mode: mode, review, ignore, statistics, etc.
You can re-do over and over any of the 3 steps: Analyze, Adapt and Publish
You can learn from the adapted applications installed with FoxInCloud: just browse the FoxInCloud menu to start either desktop, local Web and/or remote Web versions. You have the full source code of these applications for your review.

Round III: Adapt your app Source Code, for real

Once you have successfully completed step II above, you switch FAA to Source Mode and start the final steps that will end up by putting your Web Application into Production.

From now on there’s no need to step back to Copy Mode.

1- Analysis

Est. duration: 15’ to hour(s) depending on your application size

Very similar to what happened in Copy Mode, just let FAA complete the scan.

2- Adapt

a- Automated

Est. duration: 15’ to hour(s) depending on your application size

Click the button and let FAA complete his job:

Replace native classes by “FoxInCloud Base Classes”: eg. Form replaced by awFrm of aw.vcx
Perform the Automated Adaptations identified at step 1

When this steps completes, you should no longer see any adaptation tagged as “Automated Adaptation” in FAA left drop-down list.

b- Manual

Est. duration: depending on your application: see figures provided by FAA

Here comes the part where your development skills come at play.

At this stage you need to filter the Adaptations list on Manual Adaptations after Step 2- Adapt (left drop-down)

We recommend that you process adaptations by type rather than by file; eg. you could start with the call-back adaptations (‘User decision required: …’) that are the most critical. For instance, select one of such adaptation that you can easily test (eg. on an easily accessible form), do it, and test it right away to make sure you’ve fully understood the process.

Also make sure to test your application after a bunch of adaptations to remain sure you’re on the right track.

Nothing changes at this stage and this is perfectly normal: it’s just your application running the same as usual, with slightly different classes and code, albeit ready to run on the Web.

Tips and tricks

If you KNOW that a module and/or file won’t be used in Web mode, and thus don’t need be adapted,
- ignore it using the Ignore button
- choose the not ignored option below: all ignored files, modules and adaptations will disappear from the list

Once you’ve completed an Adaptation and want it removed from the list, you can either re-analyze the project or click Ignore like above explained
In case of doubt that FAA documentation and/or video can’t address, ask for free support on any public area such as the VFP forums below ⁷; please make sure to post the whole code where you have a doubt.
You may want to fully adapt a couple of forms for your first Web Application tests (see below).

3- Publish

Est. duration: 2 hours

Once you have a couple of forms adapted, you can run step 3-Publish like you did earlier in Copy Mode.

When this Publish step completes ⁸, you need to review the xxxSets program that FAA has built from the startup code in your desktop application’s main program. Please make sure that this code is OK and edit it as you see fit. Make sure also to read the documentation in this program to fully understand what it is used for.

When typing in your browser: http://localhost/xxxTest/, you can see a a static page built by FAA showing a clickable list of your app’s forms.

After starting your Application Server by typing in the FWS IDE command window do <path to>xxxTest, you can click on any of these links and see your form rendered as HTML in the browser.

Of course this is just a test page, not your final Web App home page! To install your Web App home page:

Open IIS management console like explained earlier
Navigate to your app node under ‘Default Web Site’: eg. xxxTest
Click ‘Default Document’
Click ‘Add’
Enter ‘index.xxx’, click OK

Now if you reload http://localhost/xxxTest/ in your browser, you see a sample home page using a ‘sampleIndex’ form (sample login form) installed by FoxInCloud.

To replace this sampleIndex by your own login form, modify command xxxServer, navigate to procedure Index and replace 'App\Sample\sampleIndex.scx' by the name of the your login form. Make sure to open your login form in the VFP designer and:

set .wlAnonymousAllowed = .T.: this will allow this form to display to anonymous user,
adapt the login method like in
modify form App\Sample\sampleIndex.scx method txtPass.valid

You could also have a splash form as index form, with a menu or a button calling the login form; in such case both these forms should have .wlAnonymousAllowed = .T.. to know more about all the possible variations, just ask on a support forum ⁷.

Once you’ve done this step successfully, your web app is up and running! Your Index form can either display a regular VFP menu or a ‘menu’ form with buttons opening the various sub-forms of your app. What’s really important is, just like in a desktop application, to set the starting point as explained above.

Note that the Publish step should run only once successfully; whenever your app shows up in the browser OK, you no longer need to run this step. You might want to re-run step 1 et 2 whenever you add new code to your application (see below). If your code is stable, you can just use FAA as its name states: an Assistant to help you identify and complete your adaptations.

Round IV: Maintain your adapted Source Code

As FoxInCloud adapts, not converts your application, your maintain a single (adapted) code base that you deploy on the Desktop as usual, and on the Web.

Desktop deployment of adapted code does not require any additional license; all the FoxInCloud modules (*.prgs and *.vc?) added to your application are under GNU General Public License and thus can be included, distributed and even used in your application for free.

Whenever your adapted app. needs new features, you can either (1) develop this new code as usual and later run FAA to adapt it or, as soon as you have a fair experience of adaptations, (2) develop this new code the FoxInCloud way:

Base new classes and objects on the FoxInCloud sub-classes created by FAA (xxx.vcx)
Write adapted code; eg.:
implement a new event, adding 3 ‘magic lines’ as header:

procedure someEvent
if thisForm.wlHTMLgen
  return
endif

&& your regular code starts here

display a message box expecting a user response, add the call-back method as 1rst parameter:

thisForm.wMessageBox('wFormCallBack', eMessageText [, nDialogBoxType ][, cTitleBarText][, nTimeout])
...
procedure wFormCallBack
lparameters tuUserChoice
if m.tuUserChoice = IDYES
  && code processing user response
endif

etc.

Et voilà!

Hopefully this post has given you a complete view on the whole FoxInCloud development process, and helped you understand how to better use the free tools offered by FoxInCloud for adapting your application.

This earlier post further clarifies the why and how behind adaptations.

Have a fruitful journey with FoxInCloud!

Selecting all options is OK for a development machine having very little risk to be accessed from the outside world. Carefully selecting the options is mandatory on a Production Server. ↩
we will send you a notification email whenever newer versions are available; you can unsubscribe from any notification email you receive. ↩
By default, the files are copied to the same folder hierarchy within a Test folder located at the root of the same drive. You can change this setting in FAA. ↩
When using Copy Mode, you don’t need to copy your project for FAA! However, if you prefer to copy yourself, you can just run it in Source Mode… ↩
Statistics always reflect the current filter; eg. filtering on a file provides the estimated time to completely adapt it; this can help you organize the work of your team members. ↩
mainly xxxTest.prg – Server startup, xxxSets.prg – App Environment Settings, xxxServer.prg – Server classes and settings; and other maintenance utilities in the Progs\ folder ↩
VFP support forums: https://support.west-wind.com/, https://www.levelextreme.com/, https://www.foxite.com/ ↩ ↩²
in what follows, xxx is the code you chose during the publish step. ↩

FoxInCloud 2.26.2 is released!

Thu, 19 Apr 2018 00:00:00 +0200

FoxInCloud 2.26.2: even more hardened

FoxInCloud 2.26.2 is the second maintenance release for version 2.26, the 26th in FoxInCloud History (close to 4 releases per year), tallying over 450 fixes, enhancements and support extensions.

This is in the process of cleaning up the code, polishing functionalities based on user feedback, improving availability up close to the magic ‘4 nines’ (99.99%)

2.26.2 brings more than 13 fixes; even if it seems a few, most of these fixes respond to customer demands, to help them improve their Web app even more.

Execute JavaScript on form.activate()

One example of how a small fix can bring a new cool feature is the ability to execute some JavaScript on form.activate().

By doing so, one FoxInCloud developer could display nice notifications when a form opens like shown on this video:

When using the Boostrap mode in FoxinCloud, it’s fun to replace the traditional Foxpro icons (.jpg, or even .bmp) by font-based vector icons from one of the 2 free icons sets provided with FoxInCloud: Glyphicons and Font-Awesome.

Whenever FoxInCloud finds a PICTURE clause in some menu command, it adds this picture to the awBSicon table where you can later associate the picture with a font-based icon; at run time, FoxInCloud places the latter into the popup like demonstrated in the FoxInCloud Live Tutorial menu:

Note above that ‘traditional’ and font-based icons can co-exist in the same menu popup.

FoxInCloud Adaptation Assistant enhancements

We love your feedback on FAA! You manage to find issues that we would otherwise never find! Thanks also for using the error feedback form.

Why and How adapt your App for the Web?

Tue, 17 Apr 2018 00:00:00 +0200

At FoxInCloud we see the Web as just another User Interface (UI) device. And no one should ever need to rewrite an application for another UI device, not even rewrite the UI, just do whatever provides a similar UI on the new device.

From this stand point, a desktop Application only needs be adapted to: (1) display the UI inside a browser and (2) run on a Web server.

This post discusses the 3 areas where code needs adaptation, and how FoxInCloud Adaptation Assistant (FAA) and FoxInCloud Application Server (FAS) handle them.

It provides a broad view on why and how adaptations are needed, and will hopefully ring a bell when you later meet such a situation while developing.

A - Map VFP and Browser event models

The event models implemented in VFP and Browsers (HTML DOM events to be precise) are mostly similar, though with some slight differences such as:

VFP events that don’t exist in HTML: eg. .Validate(), .When(), .DropDown(), …
HTML events bubble, VFP events don’t: by default in HTML, an event occurred in a contained element also triggers on all parent containers up to the document (equivalent for the form);
Fast events such as .MouseOver() and .InteractiveChange() can’t be timely processed on the server and require some browser-based code instead.

How FoxInCloud handles Events

1- Choose who processes the event: Browser, Server, or both

When running FAA step 2, after replacing native classes (such as Textbox, Combobox, etc.) by classes derived from FoxInCloud (such as xxxTxt, xxxCbo, etc.) FAA adds at the beginning of each Event Method:

IF (TYPE('m.thisForm.wlHTMLgen') == 'L' AND m.thisForm.wlHTMLgen)
  RETURN <value>
ENDIF

First time it needs a Form, FAS:

sets m.thisForm.wlHTMLgen = .T.
runs each event methods in all member objects of the form
decides what to do based on the <value> returned by the RETURN <value> instruction above:
- .T.: (default) run VFP event code on server
- .F.: ignore event ¹
- string: assume JavaScript to be run on the browser

If necessary, thisForm.wcScriptClientServer() and thisForm.wcScriptServerClient() makes the event be processed by the browser and the server in either order.

» FoxInCloud Live Tutorial Sample

2- Handle event

Based on the above value, FAS creates a JavaScript event handler invoking FoxInCloud.js, a standard JavaScript module that any FoxInCloud Web page loads by default.

FoxInCloud.js collects whatever value from the form controls, processes the event, takes care of cancelling bubbling and/or default behavior such as context menu on .RightClick() and, if required, sends event to server using AJAX, for processing by the VFP app.

» FoxInCloud Live Tutorial Sample

B - Replace local peripherals by the Browser

When running on the desktop, an app can directly address peripherals on the user’s machine: screen, printer(s), storage, etc.; when running on a server, app can only address the server’s resources, and reach the client’s machine through a protocol named ‘HTTP’, acronym for ‘HyperText Transfer Protocol’.

As its name says, ‘HTTP’ can only transfer text, without any ability to ‘discuss’ with user’s screen, printer or storage directly.

Furthermore, the server can only respond to an HTTP request from the browser, in other words it can’t initiate a message to the browser ².

As a consequence, every piece of code where your application delivers a result to the user – either on display, printer of file – must be replaced by an equivalent mechanism going through the Browser.

How FoxInCloud Handles Peripherals

With FAA replacing the native classes by classes derived from FoxInCloud’s aw.vcx ‘base classes’, FoxInCloud exposes classes, methods and procedures that replace the VFP native command and functions addressing the peripherals. These methods and functions run different code whether the app. is in desktop mode or web mode:

desktop mode: execute regular VFP code
web mode: execute browser aware code

1- Display

DO FORM ... → [thisForm.]wForm()
MessageBox() → [thisForm.]wMessageBox()
etc.

FAA replaces these instructions automatically.

» FoxInCloud Live Tutorial Sample

2- File

PutFile() → thisForm.wFileSaveAs()
GetFile() | GetPict() → xxxImgGetFile | xxxImgGetPict class

» FoxInCloud Live Tutorial Sample

3- Printer

Printing requires generating a PDF report and send it to the browser using wFileSaveAs()

As code depends on the PDF generator you prefer (eg. XFRX, FoxyPreviewer, FRX2Any, etc.), this adaptation is manual for now ³.

» FoxInCloud Live Tutorial Sample

C - Address multiple users

When running on the desktop, an Application addresses one single user at a time; when running on a server conversely, the same application can address any user having the Web Application’s URL.

Because the Web the application is shared by a number of users, it must ensure that serving a user does not affect the other users:

never stops or hangs
cleans up the place after each user action

1- Split Questions and Answers into separate processes

One easy way to hang an application is waiting for an answer from the user:

procedure Click
...
IF MessageBox("Question", 4) = 6 && application hangs here
  <process user's choice>
ENDIF
ENDPROC

To avoid hanging the app. waiting for the answer – and this is the same for any Web Application – code needs be arranged as follows:

user fires an event
server asks a question and provides to client an address where to send the answer
client sends the answer at the address specified
answer is processed by code at the address specified

Using FoxInCloud, the above code becomes:

procedure Click
...
thisForm.MessageBox("wFormCallBack", "Question", 4) && code hangs in desktop mode only, not in Web mode
ENDPROC && Question is the last instruction in method

procedure wFormCallBack && Standard method provided by FoxInCloud 'base classes'
LPARAMETERS tuUserChoice
IF tuUserChoice = 6
  <process user's choice>
ENDIF

» FoxInCloud Live Tutorial Sample

Because the callback response processing code (above moved to .wFormCallBack()) can have dependencies outside the original method (such as a ‘private’ variable), picking a call-back method and moving the code is a manual adaptation; FAA identifies the methods requiring your attention.

2- Stop instructions execute in desktop mode only

Any instruction that stops application execution must be conditioned by desktop mode:

IF wlLAN() && function provided by FoxInCloud under General Public License
  QUIT
ENDIF

3- Save and restore the user’s state

Because a user action should not be influenced by what the previous user has done, the app should be able to swap context from one user to another.

FoxInCloud saves and restores the full user context automatically, provided 2 manual adaptations are performed:

List the native properties (such as .Visible, .Enabled) affected by user action into a property that every object inherits from its FoxInCloud base class ⁴:
.wcPropSave = "Visible, Enabled"
Requery the parameterized views using thisForm.wViewParmSet() inherited from FoxInCloud base class;
eg. with 3 parameters:

thisForm.wViewParmSet('viewAlias', 'parm1Name', parm1Value)
thisForm.wViewParmSet('viewAlias', 'parm2Name', parm2Value)
thisForm.wViewParmSet('viewAlias', 'parm3Name', parm3Value, .T.)
&& adding .T. on last call runs Requery('viewAlias')

FoxInCloud handles all other user state bits automatically.

» FoxInCloud Live Tutorial Sample

4- Setup the full App environment at Server Startup

When running on the desktop, your application goes through predefined steps that you can easily predict: start, login form, menu, formA, formB (modal), back to formA, etc.

Conversely, because browser and server execution are asynchronous, user actions can come in any order, especially after a server restart: some user actions can affect the formB in the example above, while the calling formA is not yet running.

For this reason it is required that all application-wide settings like SET PROCEDURE, SET PATH, PUBLIC, etc., are made right at server startup rather than throughout the application code.

To help this adaptation, FAA step 1 identifies the corresponding instructions in the application code and step 3 builds an environment setting class xxxSets where you can safely move them.

The Desktop and Web versions of the Application should share this environment class:

modify command DesktopMain.prg

...
local oEnv
oEnv = newObject('xxxSets', 'xxxSets.prg')
...
do form mainForm
read events

» FoxInCloud Live Tutorial Sample

modify command xxxServer.prg && generated by FAA step 3

cAppSetsLib = 'xxxSets.prg'
cAppSets = 'xxxSets'

» FoxInCloud Live Tutorial Sample

Pretty simple, isn’t it?

When you take a fresh new look at what really makes a difference between a Desktop and a Web application, you can easily isolate a handful of specific areas where an adaptation is needed, while most of the application code can run unchanged in both environments.

And you soon realize that complex MVC and REST frameWorks ⁵ that current Web Technologies tend to present as ‘mainstream’ are just another attempt to make what desktop applications have (wrongly) done for decades: maintain the user state on the browser, with code mixed up with the UI layer.

Another caveat of these technologies is that most of the application code ⁶ is in a readable form that anyone can download and copy.

Hopefully this post has helped you understand that:

You can have the same code running on the desktop and the Web: test new functionalities on the desktop and later deploy on the Web, get desktop developers work on the Web Application rapidly;
Reasons for code adaptations are pretty simple to understand and keep in mind, and easy to practise in later app development;
FoxInCloud keeps all the sensitive code on the server, protected from your competitors;
The Web can be simple and fun!

Typical use case is a ‘fast event’ such as .MouseEnter() or .MouseLeave() that you can override using a CSS ‘pseudo-class’ such as :hover ↩
Even WebSockets (allowing full duplex communication between Browser and Server) require an initial handshake from the client browser ↩
We plan to add standard functions for the most popular PDf generator: XFRX, FoxyPreviewer and FRX2Any ↩
At design time or in .Init(), .Load() for forms ↩
MVC client-side FW: jQuery, Bootstrap, angularJS, emberJS, ReactJS, vueJS, etc. – REST server-side F/W: asp.net, ruby-on-rails, django, telerik, flask, expressJS ↩
Except the database layer ↩

What do you need a Web App for?

Fri, 30 Mar 2018 00:00:00 +0200

Web Applications have been a hot topic since 2005 (more than 10 years ago…), when AJAX was first coined in the post by Jesse James Garrett “Ajax: A New Approach to Web Applications”.

After many articles were written, posts blogged, questions discussed on StackOverflow, and many new tools and frameworks were launched with buzz, we haven’t seen that many Web Applications around, at least in the Business Application arena where VFP-based developers and companies have reigned for over 30 years.

What’s the reason for that? Are Web Applications less efficient than Desktop Applications? Less demanded? Do they cost so much that no one has seriously invested to get a result similar to what Desktop Applications deliver?

This post will discuss the pros and cons, and the future for both Desktop and Web Applications.

Pros For a Web App

Install once for any number of users

We put this first as it’s what companies running a Web App love best: no more installation hassle; yes installing and maintaining on a Web Server is a little more complex that a user desktop, but it’s far more simple than installing and maintaining 200 desktops!

No more virus issue, no more disk crash; if you use FoxPro tables ¹, no more index or memo file crash because a power outage.

No more “it works on my colleague’s computer but not on mine”.

A new user comes in? Just create her/his account in the database, send her/him the URL and you’re done! A user leaves the company? Just close her/his account in the database and you’re done.

Reach Users outside the Company

It’s great to have suppliers and customers be able to log into your system and provide informations, download documents, pay invoices and so on. That’s a real productivity booster for your client company to get this kind of close interaction.

Of course this interaction can be with human or machines: you can expose either or both an API (for machine-to-machine collaboration), or business forms eg. for customers to approve and/or pay invoices.

Serve Mobile Users

Workers dealing with customers are often mobile: salesmen, inventory keepers, delivery personnel, doctors, teachers, and many other working categories need information on the field, away from their office. Because AJAX bandwidth requirements are low, a Web App can deliver the information they need anywhere using a 3G/4G connection.

Get into Younger People’s habits

Younger generations are used to do almost everything using their smartphone, from monitoring their bank account to dating… 6% of new such users enter the workforce every year, and they soon will be in a position to decide the kind of information technology they want to use.

Tightly control Users and Licenses

Many software companies struggle with protecting their source code and application from piracy using dongles, encryption, and many other methods against privacy.

It’s obviously easier to protect a server than 2,000 copies of a software spread around.

Easily debug your application

Remember the headache remoting into a user’s machine, trying to understand why your application worked everywhere except on this very workstation, dumping memories, creating ad-hoc logs?
Do you remember the time it took to get the boss’ application work fine and get paid?

With a Web Application you have full control: you can have any kind of log, anywhere, at any time, and update the application within minutes to add such additional precious debugging information… day and night, regardless whether users are connected or not.

Join prospective Customers anywhere

How do you reach the prospective customers for your application? And when you’ve reached one, how can he test your application? Do you have a demo version that can be downloaded? Are you sure this demo app will install correctly? Or do you visit him to make the demo and explain the benefits of your program? What if the prospective customer is 5,000 miles away?
What if the customer uses another platform, or has put ‘mobile’ on his selection check list?

A Web App jumps over all these fences.

Cons

Development Cost

One day you decide you’ll start developing a Web Application: you send your top devs to a conference, select a dev. environment, some frameworks, send your team to a training, build a mock-up as proof-of-concept, and start estimating the cost for the whole system.
Then come the trade-offs: you realize that some functionalities will either not be useful, or will cost too much to develop for the Web.

When you decide to kick off, 2 years after the initial research, you read an article or a post somewhere saying that the framework X that you’d chosen initially is no longer hype: everyone now rushes on framework Y that is developed and supported by a larger company and a larger user community… back to square 1…

It’s a known story: Web Technologies is an area where obsolescence beats any other industry: despite they’re based on standards, tools like JavaScript frameworks have a life expectancy of several years, and it’s quite common that their development effort stops after a couple of years just because the volunteer contributors have rushed away to a more recent project that gives more momentum to their carrier and speaking experience.

Response time

Web Applications require a request going through the wire, somehow restore the user’s context, execute the user request, deliver a response that goes back to the user through the wire.

Even if a server is generally faster than an average user workstation, the overhead for request and response transport and for user state maintenance makes response time obviously slower than on the desktop.

How FoxInCloud can Help

Value your experience

FoxInCloud adapts your desktop application to the Web: you can deploy the same – adapted – code either as a ‘classic’ Desktop Application or a Web Application:

FoxInCloud supports 99% of the features you have in your Desktop Application
You don’t need to ‘rethink’ your application to suit the Web and/or limit your functional scope to keep your budget under control
Your same development team can maintain both the Desktop App. and the Web App.
FoxInCloud sorts out the technologies for you, and supports the cost for keeping pace with the perpetual changes
You can sell the Web App. as a natural extension to the existing Desktop App, a much easier sell than a brand new app.
No one can tell what technology runs on the server: whether it’s php, asp.net or VFP, the user experience will not change at all
You end up developing Web features without the hassle of going through the whole Web Tech stack.

You adapt less than 2% of your source code to make your application Web-aware; and these adaptations are not rewrite, just moving code, adding parameters, and/or calling different methods.

You can adapt your application progressively, by functional block, rather than everything at once.

Control response time

As we’ve developed on VFP for 30 years, just like you, we are able to monitor anything that can possibly be monitored in your application (settings, data sessions, aliases, and much more), and in FoxInCloud itself; you have a complete view on the response time and which actions you can take to provide a smoother experience to your users

Take full advantage of Web Technologies

FoxInCloud builds full breed, not second range Web Applications: your VFP Web App. with FoxInCloud fully compares to, and often beat the best Web App around: functional coverage, response time, number of objects and events.

You can even improve the HTML that FoxInCloud generates for you to please your users even more.

Control license and application usage

FoxInCloud provides a Dashboard (sample here) where you can see how many and which users your Application has had, for any period of time; you can be notified if the users count exceeds the number licensed, and take appropriate commercial action in a smooth manner with your clients.

a perfect fit for FoxInCloud by the way ↩

Challenges of developing a Web Application

Sun, 18 Mar 2018 00:00:00 +0200

When seeing the many attractive frameworks that have flourished on the web since 2005 ¹, one could think that developing a Web Application is just a game of assembling components that you can pick here and there for free.

The reality is very different: as of today (2018), and despite 2 decades of continuous efforts to make it more simple (from antique asp to ‘modern’ frameworks) web development still has not found a paradigm where any regular developer can become a ‘full stack’ web developer within a couple of years.

Two main reasons for that:

the client-server nature of the HTTP protocol: with a desktop program, each user runs his/her private instance that is totally at his/her service; on the web conversely, a server can deal with any/many users, and a given user can deal with several servers; a shift from a simple 1-to-1 relation to many-to-many.
the many standards: after almost 20 years of a fierce battle between Microsoft willing to impose “his standards” through a quasi-monopoly of Internet Explorer as a browser, and the web designer community backed by Mozilla Firefox (heir of Netscape, only serious concurrent browser in the early 2000), the standards have finally won the battle.
Nice outcome having a little drawback: each component (HTML, CSS, JavaScript) is maintained by a standard organization (W3C, ECMA), and developed by ‘volunteer’ third parties (thousands of contributors in discussion lists). Documentation depends on the goodwill of these parties: blog posts, discussions on stackoverflow, utility sites from service companies have replaced the good old documentation that developers used to have 20 years ago: maintained by a single source, consistent, accurate, etc.
Ironically, efforts from opponents to a world regulated by a de-facto monopoly have led us to a completely de-regulated world where free stuff is often a troyan horse to sell more services than what licenses used to cost.

Whatever language or framework you choose, you’ll meet 2 serious obstacles down the road to a Web Application:

Write responsive HTML/CSS/JS: if you want to somehow clone the layout of the forms of your VFP desktop application, and render it as responsive HTML using - eg. - the Bootstrap framework, it’ll take you up to 10 levels of nested divs to get a proper layout; no GUI editor at the rescue for that: you’ll have to hard code using a text editor, and choose appropriate class and IDs without getting messed up; and it soon becomes very complex and difficult to handle, especially because CSS computes the layout for you based on the structure and rules you define. If you want a responsive layout, you can no longer set .left, .width, etc., you must let the browser compute positions and dimensions. Generating HTML is the area where your server code will mostly be used and, strangely, this is only the emerged part of the iceberg as point 2. below explains.
Maintain user state: in your VFP code, each time you write thisForm.… or this.… or alias.field, or read a public variable, you query (without knowing or realizing it) the user state, as it results from the succession of user actions applied to an initial state. In VFP, as a single instance of the application serves a single user, everything can persist in memory: easy and painless. On the Web conversely, as the same application can serve any user in any sequence, the user state can exist only if you somehow maintain it (save and restore). No framework, whether it’s Python-based or C#-based, will ever do that for you. Then you have roughly 2 options to maintain the user state: on the client or on the server.

Maintaining the user state on the client requires to:

write a lot of JavaScript, probably with some client-side framework such as jQuery, Angular or Ember (be aware that these frameworks are pretty conceptual and difficult to master properly; they at least require that you are very proficient in HTML/CSS/JS as they add several layers above these technologies). Whatever your choice, you write no Python, php or C# here, just HTML, CSS and JS.
use client side storage to create on the client something similar to a view that you’ll submit to the server once user decides to save. This requires a good knowledge of web storage API, another JavaScript-centric technology
expose all your business and presentation layer code to the outside world; just like you would expose all the VFP code you have in *.scx and *.vcx, except queries. You can only obfuscate this code (eg. minify renames variables in alpha sequence such as “a”, “b”, “c”, “d”, etc.), concealing it is impossible as the browser must be able to read it.

This is the solution that most developers use nowadays; exchange with the server are merely data conveyed in the JSON format.

Maintaining the user state on the server requires to:

write double code: client side code altering the user interface is almost the same, except it must query the user state from the server to take proper action; the amount of code is much higher, and client and server must somehow understand each other, this generally requires either being a ‘full stack developer’ or defining tight rules (eg. naming) between client and server.
store user state on a server disk so that any web server can retrieve the state for any user at any time (forget about assigning server instances to specific users like in the desktop world, it just does not work for high user counts; a typical web app serves 200 users and this figure can go up to several thousands)
choose or define a format to store user state: could be a simple JSON string that the client JavaScript provides after each action (then you need to choose a scalable structure), or a table that you can easily query to, eg., find differences between states before / after user action.

FoxInCloud helps you dramatically in these 2 critical areas:

generates responsive HTML/CSS/JS code from your VFP forms: FoxInCloud understand how controls are aligned and grouped on the page and builds the corresponding groupings (row, column, *-group) in the Bootstrap CSS system: eg. the FoxInCloud Live Tutorial
maintains user state automatically: as FoxInCloud runs your VFP forms on the server and these forms are object oriented, FoxInCloud is able to detect what the user actions change on the form and save these changes in a structured way; the same for the dataSession ² and the general environment ³. FoxInCloud maintains the user state on server side, in tables using a naming convention (user\form\_[ante/post].dbf). The only thing you need to do is: declare the native properties (eg. visible, enabled) that the user action can affect (custom properties are saved by default); FoxInCloud compares the state before and after user action to identify the visual changes that the browser must apply: you have strictly nothing to code to make this happen.

As we already often wrote, FoxInCloud can be regarded either as a final, or just an intermediary step to a Web Application; you can:

take advantage of the generated HTML/CSS/JS to save months of writing responsive HTML
judge whether the user state maintenance mechanism suits you and eventually recode a similar mechanism in Python, C# or other
mitigate between a server-side and client-side user state maintenance to save response time while protecting the code that you consider critical.

At FoxInCloud we would be delighted if VFP developers would consider FoxInCloud as a community-inspired effort, and would like to cooperate towards a future suitable migration path to the Web, rather than like a “take or leave” product with the VFP stigmata.

FoxInCloud does incorporate thorough software engineering thinking about running a Web Application while taking advantage of a Desktop Application background, going far beyond and above the mere language level which, in any case, does not and will never provide a complete solution to building a Web Application.

client-side: jQuery, Bootstrap, angularJS, emberJS, ReactJS, vueJS, etc. – server-side: asp.net, ruby-on-rails, django, telerik, flask, expressJS ↩
views and parameters, cursor and contents, table/alias states, cursorAdapters, etc. ↩
public variables, _Screen and _VFP custom properties, aliases in the default datasession, _sysmenu, etc. ↩

FoxInCloud adapts your Web App to any screen size.

Tue, 20 Feb 2018 00:00:00 +0200

Classic or Bootstrap, your FoxInCloud Web App. IS responsive

FoxInCloud offers you 2 HTML rendering: Classic or Bootstrap:

Classic rendering uses absolute positioning like VFP: each element has a fixed .Left, .Top, .Width and .Height, the HTML form looks and feels very close to your VFP application.
Bootstrap rendering generates HTML that automatically adjust to the screen’s area by taking advantage of the Bootstrap framework: controls are distributed within columns that flow on large screens, stack on smaller screens.

In Classic mode, if the form members have their .Anchor property set, FoxInCloud automatically implements the form.resize() event on the client side. When the form or the browser is resized, the server ¹ recursively calculates the new size and position of each control (based on .Anchor), and sends the corresponding resize and move orders to the browser. Browser animates the changes for user’s comfort.

In Bootstrap mode, the generated HTML and CSS is responsible by design, regardless of the .Anchor property; however some CSS might be needed to enhance the default rendering.

In short, you can get a responsive Web App just by implementing the .Anchor property on your form control, which you can very easily test in desktop mode as it works exactly the same in both modes. The Bootstrap mode provides, on top of responsiveness, a more modern look to your application, that you can easily extend using CSS.

This video shows this feature in action:

we plan to implement the same logic on the client side (in JavaScript); this will avoid the slight response time after resizing the form, especially for users with a slow connection. ↩

FoxInCloud blog

Enhance your FiC Application look and feel with a Web Designer!

1. Let your Web Designer be creative

2. Integrate the Web Design into your Web Application

a- Add the Designer’s CSS and JS to your Web Application

b- Generate HTML matching what the Designer wrote

FoxInCloud 2.27 works around a VFP bug to reach 99.99% availability

VFP CursorToXML() bug

Workaround

Result: four-nine availability

Special thanks

Wait, version 2.27 brings more than just a bug fix!

Paged grid: faster and updatable

Surface Events Live Tutorial

Adapting 'Surface Events'

Surface Events altering display only

Solution 1. Using JavaScript only

Solution 2. Using JavaScript and CSS

Solution 3. Using ‘pure’ CSS, version 1

Solution 4. Using ‘pure’ CSS, version 2

Surface Events altering contents

Wrap-up

Video

Learning FoxInCloud with the FoxInCloud Live Tutorial

Using the FoxInCloud Live Tutorial on line

Switching to the Responsive version of FLT

Displaying the same form as a full page or as a child form

1. as a full page

2. as a child form

Displaying the same form in ‘Responsive’ and ‘Classic’ modes

Reviewing the source code of some VFP object

Reviewing the source code of a VFP form

Getting details about a VFP form

Reviewing the full app. source code

Reviewing the FoxInCloud Web Application Dashboard

Debugging your Web Application

Using the FoxInCloud Live Tutorial locally

1. Install FoxInCloud Web Application Studio (FWS)

2. Run FoxInCloud Live Tutorial in Desktop mode

3. Run FoxInCloud Live Tutorial in Web mode

Video wrap-up

Managing your FoxInCloud Project

Round I: Heat-up

1- Make sure you run the latest VFP9 SP2

2- Install FoxInCloud Adaptation Assistant (FAA)

3- Make sure IIS is installed on your development machine

4- Install FoxInCloud Application Server (FAS) and FoxInCloud Web Application Studio (FWS)

Round II: Review your application with FAA in Copy Mode

1- Analyze your project copy

2- Adapt your project copy

3- Publish your project copy

Tips and tricks

Round III: Adapt your app Source Code, for real

1- Analysis

2- Adapt

a- Automated

b- Manual

Tips and tricks

3- Publish

Round IV: Maintain your adapted Source Code

Et voilà!

FoxInCloud 2.26.2 is released!

FoxInCloud 2.26.2: even more hardened

Execute JavaScript on form.activate()

Use graphical Web icon as menu bar PICTURE

FoxInCloud Adaptation Assistant enhancements

Why and How adapt your App for the Web?

A - Map VFP and Browser event models

How FoxInCloud handles Events

1- Choose who processes the event: Browser, Server, or both

2- Handle event

B - Replace local peripherals by the Browser

How FoxInCloud Handles Peripherals

1- Display

2- File

3- Printer

C - Address multiple users

1- Split Questions and Answers into separate processes

2- Stop instructions execute in desktop mode only

3- Save and restore the user’s state