Hi Rob,
I'm Thierry Nivelet from FoxInCloud; I'm here to add information to previous answers.
Scott said:
If you are using any non-native VFP or a Framework, it's a very long time to get the VFP appearance in a web application. If your app is simpler, and all native it's a little better.
1- The time it takes to get the "VFP appearance" does not depend on how many layers of class you have in your application. As VFP frameWorks a no longer supported, it'd be better if users of the same frameWork group their effort to adapt the framework.
2- Rather than getting the "VFP appearance", you'd probably like to deliver a more modern appearance; FoxinCloud now offers an option to generate Bootstrap HTML code so that your app looks like any modern Web Application, and can be used on any terminal including tablet and smartphone. This
blog post shows some forms: VFP original, 'classic' rendering, 'responsive' rendering using Bootstrap.
Scott said:
My biggest complaint with it though is, it takes over your VFP installation. So all future modifications of your app has to be done in the FoxInCloud client of VFP. Trying to back out of that if you decide not to do it, you need to have made a backup.
Both true and false
true: once adapted, your code has some dependencies over FoxinCloud; all these dependencies are free to use and distribute; you can get them at any time on GitHub:
false: your app can have both adapted and non-adapted code, and you can continue with 'traditional' VFP coding at any time if you desire; for instance you can publish only a part of your app on the Web (the adapted part), and keep the rest not adapted. To do that using FAA, you can just ignore the files you want to keep not adapted. And if you want to adapt them later, you can just 'recall' them and they'll show up back in FAA.
Mike said:
There are a number of features that are not supported. These are mainly because they are not supported in the browser. It might be possible to overcome these limitation with some Javascript coding. The features in question include right-click events and context menus; IncrementalChange event (can use LostFocus instead, but that would be no good for things like incremental search); Destroy event; "Active" properties (ActiveForm, ActiveControl, etc.); ACTIVATE command; AfterRowColChange (in a grid); MouseEnter and MouseLeave; and resizing a grid
As Mike mentions beforehand, FoxInCloud has improved over time and many of the features he mentions are now supported (some were already supported back in 2014):
[ul]
[li]
right-click event: supported, see
[/li]
[li]
context menus: supported[/li]
[li]
IncrementalChange event…: (Mike probably refers to textbox.InteractiveChange); this issue exists in all Web applications, not only FoxinCloud: you can emulate .InteractiveChange() using the .keyPress() HTML DOM event, it's more difficult to get the server process this event dynamically; however you can implement a custom keyPress event to query a list on the server based on some character typed; this event can be processed on the server without user state maintenance, and be fast enough. Besides many developers use .interactiveChange() instead of .Valid() and just need to move the code once for all[/li]
[li]
Destroy event: supported except is does not fire the same as in desktop; any code doing user-dependent stuff needs be moved to .release(); the rest (like garbage collection and/or table USE IN) can stay in .destroy()[/li]
[li]
"Active" properties (ActiveForm, ActiveControl, etc.): supported through wActiveForm() and wActiveControl() (part of FoxinCloud public layer)[/li]
[li]
ACTIVATE command: all supported except activate window and activate screen[/li]
[li]
AfterRowColChange (in a grid): has always been supported, base of any VFP application: see
page 'grid', check 'allow cell selection' to see before/after column change fire[/li]
[li]
MouseEnter and MouseLeave: has always been supported; again an issue common to any web application: these events are too fast to be processed by the server, you need to process them in the client browser instead. In many case you can replace the VFP code by an ':hover' CSS directive (hightlight, change fore or backcolor), you don't even need to code in JavaScript; you can see these events fire here:
[/li]
[li]
resizing a grid: form.resize() is supported since V 2.22 (10/15/2016): you can see it in action here:
click '
data update' or '
grid.*RowColchange()', then resize the form using the bottom right angle. Note that the form retains the same dimension if you call it as a full page using the menu in left margin[/li]
[/ul]
Mike said:
Toolbars are not supported
Menu are supported and generally most applications have both a toolbar and a menu. The reason why we've not supported toolbar yet is that it does not fit well with current trends in Web Application design, especially responsive apps.
Mike said:
Printing of reports is not supported
false: you can see it here:
(responsive); you can also see the couple of lines you need to write to adapt your code.
Mike said:
Changes must be made in how you define public variables and certain SET commands (these weren't an issue for me, but I noted them anyway).
false: the only change you may need is: for runtime
optimization, you better declare all your PUBLIC variables at application startup; not a big deal as FAA finds for you every place where a PUBLIC variable is declared.
Mike said:
You have to get rid of anything that can cause a modal state in your server-side code. In particular, things like message boxes and file opening dialogues must be removed.
false for at least 2 reasons:
[ol 1]
[li]FoxInCloud supports all modal states and responses from modal dialog; you can see this, and the corresponding code here:
[/li]
[li]FoxInCloud adapts the corresponding code automatically (in step 2-adapt); eg. changes [tt]MessageBox()[/tt] into [tt]wMessageBox()[/tt], [tt]do form[/tt] into [tt]wForm()[/tt], etc. Of course the whole instruction is adapted, including parameters[/li]
[/ol]
All you need to do is store the response from a modal form into a property and tell FoxinCloud its name, or use the standard '[tt]wuValue[/tt]' property.
Mike said:
At the time, the vendor was a one-person company. That person did all the development, support and marketing
false: just click the 'about' pad on our site's menu and you'll see the 3 people participating in FoxinCloud.
Christophe Unrug has been in charge of Sales and Marketing since 2010:
A single person could not have done so much coding (3,500 modules) and sales material alone: see the
video collection
By the way West-Wind Technologies is a one-man shop and I've never seen any concern about it… FoxInCloud bashing again?
Mike said:
At the time, there was no formal support mechanism, only an email address.
false:
[ul]
[li]there has been a 'FoxinCloud' section on
West-Wind support board and
LevelExtreme for more than 5 years, West-Wind support board is mentioned in the header of each page of our site.[/li]
[li]we have a Facebook and Linked-in page and also a group on both[/li]
[/ul]
Mike said:
no formal documentation for the product, but there were some useful tutorials.
right: we plan to work on that in the coming months, to complete the '
how-to' and
FAQ sections
So far we have set priority on extending the support scope and delivering Bootstrap responsive HTML/CSS, a major demand from end customers.