Thierry,

You're beginning to irritate me. You make bold assumptions without knowing much about our software, goals and resources.


>>>>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.
>
>You wrote earlier that resources were unlimited to you; except when it comes to FoxInCloud obviously

I never said that, but VFP resources are indeed getting a constraining factor. Our strategic goal is to get rid of the VFP component in our software.


>>>>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.

>Because information travels at the speed of light (300k km/sec.), distance is not an issue.
>What matters is the quality of the connection on client's end (always fast on server's end)

You obviously do not know what you're talking about. Latency is a very real problem. I had to deal with that a lot the last 5 years.

>>>>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.
>
>No assumption here, just the result of almost 20 years of experience developing AJAX Web Applications


>>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.
>
>First you write it's impossible;
>after I explain why it's possible you say the point is how much effort it takes…
>… while you wrote earlier that resources were not an issue on your side
>difficult discussion

It is or likely is impossible with the constraints that do exist. Yes difficult discussion because you don't seem to understand that FiC is not the silver magical bullet that everyone is searching for.
I tried to explain you why, but you keep going on with more code adaptation and additions which renders your 1 - 3% as ridiculous.


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

>2 scenarios in this case:
>1- mailmerge takes a lot of time (say over 10 sec.): server starts mailmerge asynchronously and client polls on a regular basis for completion; if your mailmerge program can monitor it's own status like a % completion you can even have a progress bar on client side.
>2- mailmerge is less than 10 sec.: you start a synchronous process and user waits until completion

That is not an acceptable solution. Depending one the mailmerge workload it might takes anywhere between seconds and several minutes.

>In both cases server has a time-out:
>- case 1: if mailmerge process does not complete within the time out, server kills the asynchronous process, logs the error (and maybe the % complete before error), sends an email to app admin and warns the user
>- case 2: the web server has a timeout for any request (depending on the web app implementation, either at IIS app pool level, or linked dll level, etc.); if application fails to answer within the timeout, IIS or depending dll kills the faulty app and estarts a fresh instance automatically.
>
>Depending on where the timeout is implemented, you may receive a notification email.

A kludge. not workable. We are talking 100+ site installations which all need to run as stable as possible. I have no need to introduce the sloppy behaviour of MS Office into a web application. This is not and will not be acceptable.


>>>>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.
>
>Hen and egg story; nature hates emptiness: if you have an efficient VFP-based Web application and a successful business, you can offer some training and a good wage to young developers.
>In your strategic planning, keep 2 things in mind:

VFP is old and won't be updated with new technologies. It will do what it needs to do. I still find it an acceptable platform to write desktop applications with the all the enhancements to the GUI we made, but Web applications, no. There is no point in letting new developers learn VFP if they already have a solid background in developing websites in HTML5 - MVC - C# - SQL Server stack.

>1- Web development won't grow forever; there will be a time when employment will decrease and more developers will be available on the market
>2- Once adapted, a FoxInCloud application mainly requires web dev skills (eg. to improve the GUI compared to what VFP offers); the interest is that your VFP developers can slowly evolve to the Web, making the learning curve more smooth and experience-based; eg. we have a client who has been a VFP developers for 20 years, has adapted 2 applications using FoxInCloud 5 years ago and now blends new MVC-style development with the existing Web app, and migrates the data to a SQL database using cursoradapters.
>
>>2. We want to take the opportunity to look critically at the user interface and rewrite it from scratch
>
>Your user interface is the result of user demands and for this very reason is legitimate.

How the hell can you make such an assumption? You know nothing what our (potential) clients expect from a GUI. Its different than it was 10 years ago.
Its outdated and needs be updated to reflect the current demands. The GUI needs to be redesigned from scratch

>People claim that a Web User Interface should be different just because they're unable to reproduce in the browser all the richness they can get from a desktop user interface, or it would make applications unmaintainable (see an explanation below).

Another blunt illusional lie. Clients want gestures on mobile and tablet screens. They have different needs on how you enter data (less keyboard). They expect browser based technology (such as using a back button).

>eg. Bootstrap writes "Bootstrap only supports one modal window at a time. Nested modals aren’t supported as we believe them to be poor user experiences."
>This last assertion is completely wrong for a web application… simple use case: a customer editing form:
>- main form: searchable customer list (grid) with some in-line details
>- modal sub-form 1: full client details for edition; must be modal to update the customer list when edition is complete
>- modal sub-form 2: a lookup form, eg. country, city, etc.
>Of course FoxInCloud has worked around this limitation to support an unlimited number of stacked modal sub-forms.
>Do you plan to implement "one modal window at a time" throughout your responsive web app?


You are describing a process how to let a web app behave as a desktop form. This is not what we are after at all.
I have no interest to continue this thread where you want to shove things into my mouth for obvious reasons.


Walter,