Critical Sections

[Gyannea]

I think I have a critical section type of problem but I am not sure. I have a couple of threads which use the GUI to draw things to various windows. Currently, I have placed critical sections around blocks of code that perform the drawing. I have tried (as much as possible) to minimize the entrance and exit of these critical sections, and usually have one entry and exit in a drawing loop.

Doing such corrected problems I was having until I recently introduced fonts into the code. Using fonts and formtting them involves calls to functions that get text lengths and things like that but no actual drawing is performed. So one does a lot of formatting garbage and then does the drawing.

The drawing is in a critical section but the formatting code is not. However, the formatting functions like

GetTextExtentPoint32(
label.hdc, // handle to device context
ptr, // pointer to text string
x + 2, // number of characters in string
&fontsize); // pointer to structure for string size

involve device contexts, and therefore calls to

SelectObject(label.hdc, label.hfont);

and things like that. I am wondering if these functions also need to be in a critical section. Doing so would greatly lengthen the time of the critical section, but I am wondering if conflicts are arising since a thread calls the drawing function and so does a Window callback procedure. They both draw to the same window, but different fonts can be used. Can one set a device context in the thread and then have the Window's callback call the drawing function with the thread's device contect setting?

I guess what I am trying to find out is which GUI functions need to be contained in the critical section.

If all of those device function need to be included, then it is probably necessary to include the entire setting and drawing in a single critical section...from the first "SelectObject' to its release.

Yuulk.

Brian

[kuphryn]

Assuming you are working with MFC, access to any CObject derived objects should be done in the main thread. Send messages and have the main thread update the controls.

Kuphryn

[Gyannea]

No, I am not working with MFC. I don't know if that makes a difference. I am not using controls but doing actual GUI drawing to windows. No callbacks are inovlved with the drawing, though a timer sends a callback function a message to cause GUI drawing.

Brian

[kuphryn]

That's fine. Just do the drawing in the thread that owns the control.

Kuphryn

[Gyannea]

I have a separate routine that does the drawing. All the routine does is draw a box with some shading (for a 3d effect) and draw text in the box. The routine, however, is called from a thread and from a window callback routine. The callback routine "flashes" the box every second on a WM_TIMER message. The thread waits for some event to happen before it draws the box. (All the boxes are drawn on the initialization of the object, all the reamining calls simply redraw the boxes with different colors to indicate what is currently happening.)

Nevertheless, the window is in the main thread, and a separate thread handles events.

Brian