>>First, our application contains more things that fox in cloud cannot handle, You cannot handle the frontend of CR as you cannot bring the activeX control to the (any) browser with the functionality we need, like editing the templates and the interactive viewer. Same goes for libraries like our Commandbars library. Al the code surrounding that need to be redesigned. Then I'm not even talking about automating word allowing for users to open word to design templates, scanning documents, image capturing of microscope cameras etc. It just does not work through the browser no matter how good your product is. That is not 1 to 2% code adaptation, that is a serious redesign of large chunks of our application.
>>
>>Therefore I think you missed the point.
>>
>>We are maintaining and enhancing the current applications for an x number of years, but Business wise need a new approach for the future, away from ActiveX controls, away from MS office COM automation, away from the Crystal Reports XIR2, away from the VFP language. Its outdated, riddled with problems and will not take us another 20 years forward. We have been extending VFP to what is possible, but we are going to develop it from the ground up with another approach while keeping the current product in maintenance mode. Its not worth it to invest anymore into the old architecture. We have made a business analysis and we have come to the conclusion we need to switch technologies now (still filling in the details). We are now analyzing the available techniques, tools and GUI libraries we need to make that happen. We want code to be maintainable by developers you can hire everywhere in stead of scrambling for VFP talent around the world.
>>
>>Lots of the complex calculations, the data munging has now moved to the SQL server as we now have dedicated to one single backend: SQL Server. That has made the client much more straightforward and thus migration itself a lot easier.
>>
>>We skipped wi forms, vb.net, WPF, Silverlight and other technologies, but now its time to look at what you would use if you're do it from scratch.
>>
>>Our company is about 30 people large. Lots of people have to eat, also in the future and therefore we have to invest into that future.

>Obviously foxInCloud does NOT bring any activeX in the browser, but interfaces some JavaScript code (either off the shelf or custom) with the business code running in the app, on the server.

Which already means rewriting a large chunk of code as there is image handling through Leadtools in a lot of areas in our product.

>As for your template editor requirement: it's a fake problem; this kind of functionality is a gadget that is used very scarcely and can remain desktop-based. You can move that to the web in 10 years without frustrating your users.

So what are you saying here? Breaking up the functionality here. How much code adaptation you think that is on our side?


>You wrote 3 or 4 times that you want to « go away from… »; dropping everything to seek the Graal is, in my opinion, a tech-biased strategy that is —sorry to write that— blindfolded. You’re always better off starting from a user’s point of view, prioritize the areas where you can bring him a substantial and possibly quick benefit, and see which available solution can fit.

That is what we have done. We are doing product demonstrations all around the world. From Australia to Asia, Europe Africa and north and middle America while trying to enter the south American market. And many of the prospect want as modern responsive web-based solution, suitable for tablets, phones and normal desktop computers, period.

>As I explained here several times, FoxInCloud can move parts of an app to the web (a sub-project) and co-exist with other web techs and/or be a starting point to move to MVC-style web techs. FoxInCloud DOES NOT migrate the application --- meaning it becomes segregated from the rest -- it only ADAPTS the code to run web-based, and builds a HTML/CSS/JS interface around it.

Again, I'm not interested in going through a quickfix project first, while the goal is something else. We need to do this well from the ground up.

>That's why I reacted to your idea of packaging a part of your app into a COM object (despite you want to move away from COM); you could use FoxInCloud instead, and quickly expand your web-based offering.

Then again, I have to adapt more code to do that. Packaging parts of the app into a COM object is not a 1% - 5% code adaptation. In many ways it will be a rewrite. I got forms with treeviews, listviews, leadtools image controls, crystal reports designer and views, MS office automation, Video and image capture, document scanning, document handling of DOCX, XLSX, TXT, PDF documents altogether, some VFPX projects including message notfications (desktop alert), GDI+ handling, Theme colouring, visual effects etc.

And then to add up, we are stretching the grid to do thing beyond where it was designed for which it is uncertain of how much that needs to be redesigned in Fic.

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. And if we are investing in a migration we want responsive HTML5 interface which means that everything has to be rewritten anyways.


>Please consider viewing FoxInCloud as a possible HELP to your migration, rather than an exclusive solution. The world is not black and white, with good modern solutions on one side and bad obsolete solutions on the other side.

We did a while ago and decided it was not worth the effort.

Let me be clear that your product can be viable for other VFP products, I won't deny that, but in our case there is no business case in favour for it.


Walter,