>First of all, look not only at the time estimate from the conversion run, but check out how that estimate is composed.
>My guess is that for "typical" conversion tasks the estimate was quite high compared to my guess.

You can now adjust the unit time estimate (per adaptation type) based on your experience.

>Back then FIC had no support for TeeViews - make certain all your controls are covered (Dotnet / activeX controls used?)

By the end of this year, FoxInCloud will support MSComCtlLib.TreeCtrl.2 and MSComCtlLib.ImageListCtrl.2 using Bootstrap Treeview and font awsome

>FIC could be viewed as a special kind of fwk along "typical" JS fwk lines - good as it allows easy porting, bad if too dependant/tightly coupled to the implementation of the fwk. Reset your mind from all project knowledge and try to estimate how much the 'ported app would be coupled to the FIC layer implementing the base vfp stuff. Perhaps have a JS developer look it over, as you probably feel at home with more vfp base assumptions than a web developer.

- all VFP dependencies for desktop deployment are public : https://github.com/FoxInCloud/FoxInCloud-AB/
- adapted code runs on the desktop as usual.

>Spot checks on sources and perf did not turn up something ugly - solid stuff, not up the the stellar comparison Rick creates but wth more attention to detail than many other sources.

thks