Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28560 Discussions

Screen output freezes while the application keeps running

Paul_Felz
New Contributor I
592 Views

Hi,

I have a wierd problem where I would need someone to point out to me where to look.

My application runs in loops, and provides output to disk for future usage and to the screen to witness what is going on. I use win32 to bring my data to the screen in some graphic and text output. My application runs fine for more than 1200 cycles. Then my output to screen just freezes while my application continues as if nothing ever happened and processes all the 8760 loops.  I am still able to use the controls, that is, they have the desired effect on the process but buttons do not reflect the 'presed' status. I can even check the WM_PAINT command with my debugger and find my data there, but the statements to bring them to the screen like TextOut does not have any effect any more while working fine for the first 1200 cycles..

In TaskManager my prog occupies about 8 MB of memory, with a slight memory leak issue of about 4 bytes per cycle. Load on CPU is less than 10 %.

I am using the intel compiler in VS2017, all this running in a windows 11 environment.

Being not a native speaker of English I have some difficulty to imagine what keyword to look for in the docs/manuals or on the internet.

Any support will be appreciated.

0 Kudos
1 Solution
Paul_Felz
New Contributor I
404 Views

Thanks to all of you - but it was a simple error of mine that was hidden in broad daylight.

Just for the files:

Instead of

Irslt = EndPaint(hWnd, tPaintStruct)

I coded

irslt = EndPaint(hDC, tPaintStruct)

So apparently EndPaint failed and each new call to BeginPaint() created a new DC or whatever. And when the register that holds this data was full, well then the output to screen ended. Strange: this did not show in increased memory demand.

I am happy my problem is solved and I will have my nex beer to the health of all of you who offered support. Thank you.

PF

View solution in original post

8 Replies
andrew_4619
Honored Contributor III
571 Views

Sounds like it could be some data corruption issue. In debug to you compile with check all? That might help. Also you don't specify what type of graphic application it is Windows, QuickWin etc but maybe you need to add an error trap routine in some key places and do a getlasterror with a breakpoint on error to see if you get some error after "1200 cycles".

Paul_Felz
New Contributor I
508 Views

Thanks for your hint. I am using win32 API.

Could you point me as to how to set an error trap?Is this just the 'GetLastError'-function?

I did not f ind any reference in the win32 docs. And how do you set 'check all' for the compiler and/or debugger?

Thanks

PF

 

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
474 Views

Could you show the failing TextOut function call including the values for the arguments.

 

Potential issues:

 

The value of hdc has changed (handle to device context)

The handle to device context got closed

The foreground color got set to the background color

The coordinates are off screen

The text is all whitespace

The text is null.

 

Does the return value of TextOut indicate failure (return == 0 == fail).

 

You can insert diagnostic code that trips after 1200 cycles and displays the information (or use the debugger).

 

The handle may have to be tested for open via a system call.

 

Jim Dempsey

jimdempseyatthecove
Honored Contributor III
474 Views

Also note, do not assume the TextOut window relative position and size has not changed.

 

Jim Dempsey

0 Kudos
JohnNichols
Valued Contributor III
454 Views

All of the above can happen, I have a large windows program that runs FFT loops, 51 of them and it takes 3 minutes for the loops, the screen often freezes for 20 loops and then catches up, the same thing happens with the data collection program that is running at 2000 Hz. 

It got so bad I actually placed a popup window that says, I am still running - do not touch anything -- and so people do not start hitting keys.  It lasts for about 1/8th of  second, long enough to read and distract the average human. 

I did the same thing once on the mainframe at Newcastle University with STRAND6 and was banned from the mainframe.  It took over the computer for 6 hours one night.  The same problem on a 386 computer took a week to solve and nothing came on the screen for the whole week.  

0 Kudos
JohnNichols
Valued Contributor III
453 Views

You can insert diagnostic code that trips after 1200 cycles and displays the information (or use the debugger).

Or just learn to be patient, it is a human error to worry and not a computer error. 

0 Kudos
Paul_Felz
New Contributor I
405 Views

Thanks to all of you - but it was a simple error of mine that was hidden in broad daylight.

Just for the files:

Instead of

Irslt = EndPaint(hWnd, tPaintStruct)

I coded

irslt = EndPaint(hDC, tPaintStruct)

So apparently EndPaint failed and each new call to BeginPaint() created a new DC or whatever. And when the register that holds this data was full, well then the output to screen ended. Strange: this did not show in increased memory demand.

I am happy my problem is solved and I will have my nex beer to the health of all of you who offered support. Thank you.

PF

JohnNichols
Valued Contributor III
376 Views

nex beer

nex beer is spoken of with awe in Outback Australia. 

There is a rumor that that beer gave Crocodile Dundee his super powers. 

I have searched high and wide but it is only served in a few places in the world. 

Your are very lucky.  

The search goes on. 

Reply