- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also note, do not assume the TextOut window relative position and size has not changed.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page