>>>>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
>
>>>>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)
>
>>>>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
>
>
>>>>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.
>
>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
>
>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.
>
>In any case you have nothing to restart manually.
>
>
>>>>>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
>
>Right; you would:
>1- implement the .wcHTMLgen() method of this grid class to generate the div stack HTML
>2- override the proper AJAX class method to, when grid's content changes, call the object's .wcHTMLgen() method again
>
>
>>>>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:
>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.
>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).
>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?
>
>>3. We want to use the most modern web development techniques
>
>depends on which criteria you base the locution "most modern":
>- if you consider the release date, then probably angularJS, reactJS and viewJS are, in turn, "most modern"
>- if you consider the development simplicity and productivity, please rate the following scenarios for developing a form:
>
>scenario 1
>- get a fair understanding of HTML, CSS, JS
>- write the HTML and CSS using a framework like Bootstrap
>- for each control in your application (a typical application has over 1k controls, in your case should be around 5k)
> . add the MVC attributes to the HTML
> . name and write the controllers in JavaScript, each controller matches a transaction on the server
> (each controller involves an AJAX request and a query on server side, make sure of your response times in a variety of test cases)
> . name and write the transaction on the server to provide the necessary data to the control; make sure to optimize each query as you can have up to 10-20 query for a single user action like navigating to the next record in a list.
>- make sure your naming convention is solid enough to be able to understand, a a given point in time later in the project, what each controller and server-side transaction is made for. You'll probably have to change your naming convention as the project grows to keep it understandable (eg. move from names with low significance like model1, model2, model3 to names that every member of the team can understand)
>
>scenario 2
>- adapt your VFP application using FoxInCloud
>- whenever you want to improve FoxInCloud's default behavior, or add new behaviors, implement some custom code in .wcHTMLgen() and/or xxx.css and/or xxx.js
>- one AJAX request per user action and support for native VFP .controlSource, .rowSource and .recordSource: light network activity and no extra queries to write
>
>If "modern" means efficient and productive, which scenario is more modern?
>
>> 4. We want to hire additional web developers.
>
>Sure, with FoxInCloud these developers will also help the former VFP developers get more out of the application while knowing excellently the 'legacy' functional and user aspects.
>
>>FoxIncloud is not the most logical choice given the above.
>
>The new arguments above are worth considering.
>
>
>>>>>> 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 today's standards.
>
>For the reasons mentioned above, "today's standards" are nothing more than a way to escape complexity of desktop application that no one (except FoxInCloud) is able to match on the Web.
>If you've come up with the forms as they are in your application it's because users have found it more comfortable and practical for doing their work.
>This does not change whether the form is on the desktop or in a browser: your application is driven by "letting users interact with the professional data" regardless of the medium they use (desktop, tablet, mobile) for this interaction.
>One exception could however be made for small devices like smartphones; and in this case FoxInCloud helps you again: you can easily assemble new forms dedicated to the handheld, sharing (adapted) classes with larger forms, and install 2 applications side by side (sharing the same code) depending on the device size.
>
>We have almost 20 years experience in developing AJAX Web Applications, from the early days of IE 5 (new ActiveXObject('Microsoft.XMLHTTP')), and long before the word AJAX even existed.
>We have come up with the idea of adapting VFP code to the Web (using HTTP/CSS/JS) for commercial reasons dealing with a worldwide company, and this concept has resisted all the oppositions and the many counter trends.
>We have complex business applications (eg. full ERPs) in production since years with 100s of users and over 99.99% availability (the highest possible SLA).
>You can benefit from this experience or deny everything I write, it's up to you.