01:54:01 PM
3IN0TSKRL
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.
