>>That would be clunky and again more code adaptation
>
>No more VFP code adaptation, just some additional JS code to handle interactive user events

Which is the same to me. Its investment in writing code. Whether that is a change or writing new code does not make a difference in terms of effort.

>>Most likely also having an performance effect.
>
>No, FoxInCloud has a 'fast track' to send simple events to server without full user state restore -- with any technology (including FoxInCloud), if events have to be processed on server side because client side is not able, you'll have a performance effect

The roundtrips to the server are indeed the main concern, The server might be 1000s of km away.

>>Its kludge, one that might work in some instances but not if you are using the activeX interactivity (like interactive zooming in, cropping, adjusting hue and contrast, drawing lines on the canvas, etc).
>
>1- events like zooming and cropping can be processed on client side and just send an asynchronous event to the server to let it know the state

That assumes you can catch all of those event, and that performance will be adequate.

>2- any activeX has methods matching events: you can write JS that captures the 'zoom' event, send to the server, execute the 'zoom' method on the activeX, send the new image back to the client (though in this particular case (1) would probably be preferred)
>3- adjusting hue and contrast: must require additional controls like sliders or textboxes to be implemented when generating the HTML code for this activeX:
>

>procedure leadtools.wcHTMLgen
>this.wcHTML = '';
> + "<img …>"
> + "<input type='number' …>"
> + …
>

>
>>I understand. But a lot of what we do, is not. interactive user interaction with an activeX control is not easily or impossible replicated in javascript.
>
>Since HTML5 & CSS3, Everything dealing with GUI CAN be replicated in JavaScript, down to the pixel level
>That is how tools like TSplus work.

Its not the question whether you CAN, but how much effort is this going to take.

>>Quite difficult in the case of what we do with Crystal Reports. Its not just displaying it. We let users navigate within the view, set filters, change groupings, drill down etc. There are web tools which can do that. Not free, but money is not the primary concern here.
>
>if the problem is fixed on the client side, we just need to wire that to your server code to make this work
>
>
>>Money and resources for new development are not the Primary concern here. If we have to spend a couple of million we probably will do that. The fact is that we are in TECHNICAL DEBT (Not to be confused with financial debt), where we have gone through tricks (like using citrix) to provide customers cloud solutions. We have spend tents of thousands of dollars to be able to run our product through a VPN to a destination more than 1000 km away without extremely poor performance. We are dealing with problems relating to buggy windows updates (VFP application exiting with C5 errors, scanner problems, crashing the core application) problems in office automation which are extremely difficult to troubleshoot, especially if you do not have access to the physical machines producing them.
>
>FoxInCloud users are very happy to no longer maintain client workstations
>
>> Your solution to use automation on the server is a recipy to disaster. MS does not support that in the first place and even if it works, its no guarantee it will work in the future. If a mailmerge document containing problems, will error out on the server showing a dialog with no means to recover from that as it requires user intervention. We will have to invest a lot of time and money in order to cope with that. I'd rather invest in software more reliable that can do this without those risks.
>
>1- MS does not support automation on servers because they trapped themselves with the per-machine licensing scheme; if everyone automates MS office on servers, they'll cut their revenue stream;
>2- there's absolutely no difference between a Web server and a user Workstation, except the server is much more controlled and reliable; if an issue occurs, you get an error back and that's it; every process being clearly isolated, there's absolutely no risk of contamination and/or server failure
>3- the only real issue might be that MS office processes hang up when restarting the web application; fortunately this no longer happens with newer versions of Web Connect and IIS: when the IIS Application Pool stops, all dependent modules do a proper garbage collection. IIS Application Pools can stop for a variety of reasons, such as scheduled recycling (daily or weekly)

We want stable web connections. Connections we have to restart because of a Word dialog getting stuck in a mailmerge is simply not acceptable.

>>>FoxInCloud supports all PEMs in grid and its members, except containers in columns
>>That would already be a big problem for us, as we use this extensively (screenshot) throughout the product. See attachment
>
>The example you give does not require a grid: a simple stack of divs is enough.

Which is another case of code adaptation


>>I have little confidence that using FIC is the route we have to take. Our product is not a simple VFP application. Far from it.
>
>There are complex FoxInCloud applications in production since 2011… Instead of just throwing FoxInCloud away for the sake of your 'confidence', you can just investigate and ask, we're always happy to share what we do and how we can solve problems. What I hate in all this is that FoxInCloud is underrated, as is it was a second class solutions… NO… FoxInCloud server hundred of users daily with a 99.99% availability, including activeX and all the stuff you consider impossible. Again, please ask and dig further.

As I said earlier, there are numerous reasons to rewrite our applications, of which the majority FoxInCloud has nothing to do with it.
1. We want to be future proof and the VFP language does not fit in there. Good VFP developers are very hard to find.
2. We want to take the opportunity to look critically at the user interface and rewrite it from scratch
3. We want to use the most modern web development techniques.
4. We want to hire additional web developers.

FoxIncloud is not the most logical choice give the above.


>>>> if we are investing in a migration we want responsive HTML5 interface which means that everything has to be rewritten anyways.
>>>NO, FoxInCloud supports Bootstrap: http://foxincloud.com/tutotest/bs/
>>I know, but that is not the point. If I want to have responsive HTML5 GUI, I have to rewrite the GUI from scratch anyways.
>
>That's exactly what FoxInCloud produces: a responsive HTML5 GUI:
>- responsive: FoxInCloud writes all HTML/CSS using Bootstrap classes; it adapts to the screen size
>- HTML5: FoxInCloud uses HTML5 elements, attributes (eg. input type="telephone") and events
>- all HTML can be adapted and/or overridden using custom CSS and methods; at any level: application, class or object
>
>> There is no point for migrating VFP GUI.
>
>FoxInCloud DOES NOT migrate anything; FoxInCloud generates HTML/CSS/JS that roughly matches the layout and logic of your VFP GUI, it considers the VFP forms as templates to similarly arrange the controls. By doing so FoxInCloud values your years of investment in designing a GUI, and makes users at ease: they have a Web Application that looks and behaves almost like the desktop application they used to use, and that maybe they still use in parallel: they don't need training and make less mistakes.

Exactly, this is exactly what we do not want to do. We do not want to copy the current user interface. We have to rethink the user interface as what was a good GUI about 10 years ago, isn't by todays standards.