Hi guys, I have sent an email to your support dept explaining the problem in more detail…
Basically I have created an PHP script that uses curl to collect an extensive amount of data and echo it to the browser on the fly as it is collected.
The script echo’s the data to the browser bit by bit IN REALTIME AS IT IS COLLECTED, or at least that’s what happens when the script is executed on my local production server and live online on my shared hosting account, and it works correctly accross all browsers inc IE8, Chrome, Firefox and Safari.
I make use the php flush command after each echo statement to force the output to the browser as the script is executing in a loop.
However, when compiled with ExeOutput, upon execution the browser window completely freezes, and all data gets held back until the script has finished executing then it eventually appears all at once after several minutes.
I’ve tried everything I can think of to get the flush command working correctly, but to no avail. I’m guessing the issue is out of my control and probably lies somewhere in the buffer settings ExeOutput uses for its custom server/browser.
Is there an easy fix I can apply to my script to turn off output buffering on your custom server, or will it mean a major program update on your part?
If you could point me in the direction of either a fix, or let me know a timescale of when you’ll be able to get an update out so the php flush command works as expected it would be greatly appreciated and you’ll have definately got yourself a sale!
Unfortunately, flush() is not yet supported and I can’t guarantee you that we’ll add it in the next following days. In your case, I would have used AJAX instead of flush. If you prefer to rely on flush, I understand.
What I would do as a workaround:
while your PHP scripts executes, it saves its output to an external HTML data file (or even PHP).
in the meanwhile, I display a HTML page with a progress indicator, and with some AJAX code, I regularly include the data from the external HTML file. When the download is complete, I hide the progress indicator.
SUpporting flush() will require some changes to the internal protocol we use, I’ll put flush support on the TODO list.
Okay, thanks for the quick reply, I had a feeling that would be the case.
tags, and it works well in all environments I’ve tested so far. I’m not too familiar with Ajax tho, so it could be quite a mission to figure out exactly how to implement it - but if it’s not going too much of a learning curve then I’ll certainly be up for having a go.
Would you say by using Ajax my app would end up being more compatible across a wider range of operating systems or would it not make much difference?
I have a feeling I might just hold on a little while for you guys to provide a fix for flush() - could you give me a rough timescale of how long I might have to wait?
Failing that, could you give me, or can you recommend any code examples of how I would go about using AJAX for my requirements?
I too have run into this issue. I’m using a similar method as the original poster to output the progress of COM port operation as it happens. I too would love to see flush supported in the near future.
It seems that this issue also affects any AJAX request that runs for the length of the operation. I’ve tried both using an IFRAME to run my process and an AJAX request (using jQuery). I took your tip and am using a file method to communicate between the visual front end (e.g. progressbar) and the operation (in my case, writing to a COM port). I’m no longer using flush() and am not relying on a long running request for any actual data. I tried removing all COM port communication to ensure that it wasn’t causing the application to freeze, and continue to have the same issue.
Currently, I have one AJAX request that runs the COM port script. I then have an interval based AJAX request that runs every second which checks my “status” file for the current progress.
Any suggestions on a way to run a script in the background? This is more or less a game over for the project using ExeOutput if we can’t accomplish this.
In the incoming v1.3.1 update, we have added a new experimental option to create real multi-threaded applications.
When this option is set on, your issues will probably be fixed.
flush() is also being studied.
We finally got flush() working in our alpha tests. The work on the Beta version has begun.
The multi-threaded applications seem to perform well too. However, Beta testing will be necessary before the official release.
Whilst i did run with the idea of Ajax for a while, after a bit of experimentation I realised it would involve considerable changes to the way my apps work, and bearing in mind the amount of multithreaded scripts I’ve coded, all of which rely on flush, it would have been a bit of a nightmare.
Needless to say, I’ll be up for beta testing asap, just give me the word!
Assuming multi threading and flush works as planned, the only other concern I would have is for IE9 compatibility - I’m still on IE8, infact I still use XP on my dev machine, so as yet a have not had a chance to test anything with IE9, I will set W7 up on another machine soon though, fingers crossed everything will be fine.