10:54:21 PM
3IO1D3FX2
The need for a production application with a high reactivity of the operation, I also with my clients.
When my users have before them a queue of anxious patients, seizures must be fluid and no latency ..
In WEB is its very weak point, there are many latency-related infra-structures that disrupt user habits and slow down the work of operators.
For us to change discourses marketing and providing alternative views of the use of our web applications.
Eventually, there will be a smoothing of the performance of applications between WEB and LAN and this time we will be happy to have the choice of FIC
For the bar thermometer, integration into the FIC use of asynchronous mode will allow to simulate such an indicator ..
Cordially
GLS
I understand all that; I teach people how to use FiC and consult in projects with it.
1. Users are used to desktop apps. It is going to be a long time before they are re-trained.
2. I am also referring to MY ease of use. I do not want to be sending lots of threads off to an asyncrhonous handler. Lots of rewriting!
This progress bar thing is a big deal to users and developers. It also happend to address the one issue outstanding conceptually with FoxInCloud - the need for real time communication between the we display and the code running in VFP.
BTW, it would help if the timeouts for WC and FiC could all be set dynamically. Then a long process could change the timeout and then set it back again.
As long as I am on the topic, a pet peeve of mine is that all this talk of browsers and web ignores one big thing: there are very, very few business applications that run on a stateless web system. Most of what people are calling "applications" are juiced up e-commerce sites or small apps. Java is not really a web app, it is just that Java VM runs in a browser.
Hi Tuvia..
My English is poor ..
Thank you to the translator "Google" ..
I'll try to answer your question.
Today there are only two ways to protect your applications and customers:
1) Be extended, with FIC decade life of your VFP applications without rewriting code VFP important
2) Either completely rewrite all your applications in a development environment like the current "Microsoft .NET / Visual Studio" or "Servoy"
Other solutions patterned after the VFP code can not yet transform your applications in VFP productive applications for your customers. They are still in development tools Beta version (ex "Lianja" i test at the moment) that despite the best will in the world will be hard to be operational until at least 2014 ..
Currently there is no new development tools hundred percent compatible with VFP ..
The only solution immediately operational and productive to sustain our applications, it's all WConnect (Rick) + AJAX + Javascript + HTML5 + F.I.C (THN) + VFP.
One has to do and prepare clients to understand it .. then accept or die slowly.
I know this subject has been done to death, but for me, with FiC, this has gotten a little ridiculous the lengths to which I must go to provide a simple progress bar. Now before everyone piles on about the web, and stateless, etc., I know all that. But the USERS, the ones paying the bill, do not care about that. Period. They want what they always had on the desktop:
instantiate thermo class
loop
process A
Process B
update thermo display
endloop
I admit to being quite annoyed previosly when the idea that processes take a while, and that users might sit there for them, was considered hey, what an idea. Besides the massive rewrites involved, it is usual, customary, and required for users to sit there until a process is done. With reports we can get away with dumping the process off, but not with financial transactions of mega-importance.
I KNOW I can dump them process and check progress with a timer -- although the ajax and prorotype timers have some quirks with FiC, we could work around that. But that is not an answer. I can open all kinds of beautiful modal progress windows, but that is not a answer.
I am not up for rewriting over 2000 forms and 1500 classes.
It is an absolute requirement that within one method or block of code there be a way to send immediately a message to update some screen appearance This is so basic I cannot believe how much time I spent arguing about it.
Webconnect docs seem to have a class to manage this, but it requires wc 5.
This is the biggest thing stopping my enterprise apps. I have lost clients because, with FiC, I cannot easily accomplish this most basic of VFP tasks.
I am at a loss.
