stdout hates gfortran exe's

[monkeybuttons]

When I use stdoutread to retrieve output from the console, I use _guictrledit_appendtext to progressively update an edit control. Executables generated from gfortran don't display anything until code execution ends, at which point all of the output is dumped into the edit control. When I use g95 to compile my programs, the output is progressive (just like I wanted it to be). Am I missing something? Is there a problem with the way stdoutread interacts with gfortran executables? Any help would be appreciated.

[GEOSoft]

There are known issues using GFortran-4 with StdOut streams when redirected but that is not an AutoIt issue Apparently it's most noticable when compiling the GFortran with CygWin.

[monkeybuttons]

There are known issues using GFortran-4 with StdOut streams when redirected but that is not an AutoIt issue Apparently it's most noticable when compiling the GFortran with CygWin.

That's not quite the answer I was hoping for since that means there's really no solution right now. However, thank you for answering so quickly.

[GEOSoft]

Sorry about that. I don't know why CygWin would affect it though since everything I read about it says the real problem is that GF-4 waits until it finishes running and then dumps the StdOut as a single stream as opposed to doing it progressivly which to me would indicate that GF-4 doesn't have proper Std stream support.

[monkeybuttons]

It seems I found a work around (for those who are interested). If you set an environment variable GFORTRAN_UNBUFFERED_ALL to 'Y', 'y', or '1' (without the quotes of course), the output is progressive. The warning that comes with this variable is:

"If the first letter is ‘y’, ‘Y’ or ‘1’, all I/O is unbuffered. This will slow down small sequential reads and writes."

Make sure you restart your gui for the change to take effect.

[GEOSoft]

Good find and the fact that you got it to work probably proves my hypothesis that it is the Std stream in GF that causes the issue and not CygWin.