How to slow the program down?

[dragonfish]

I was trying the code below:

--------------------------------------------------
void CChildView::OnMatlabTry3()
{
	// TODO: Add your command handler code here
	CDC *pDC = GetDC();
	CString i_String("");
	for (int i = 0; i < 10000000 ; i++)
	{
		i_String.Format("%d", i);
		pDC->TextOutA(300, 100, i_String);
		pDC->MoveTo(0, 0);
		pDC->LineTo(100, 300+i/10000);
	}
	pDC->DeleteDC();
}

--------------------------------------------------
It is the Event Handler to the menu. When I run this part, the program is running, but it consume 40% of the CPU resource and I can't move the program window. So is there any function that I can use to slow the program down?

[GCDEF]

I was trying the code below:
--------------------------------------------------
void CChildView::OnMatlabTry3()
{
// TODO: Add your command handler code here
CDC *pDC = GetDC();
CString i_String("");
for (int i = 0; i < 10000000 ; i++)
{
i_String.Format("%d", i);
pDC->TextOutA(300, 100, i_String);
pDC->MoveTo(0, 0);
pDC->LineTo(100, 300+i/10000);
}
pDC->DeleteDC();
}
--------------------------------------------------
It is the Event Handler to the menu. When I run this part, the program is running, but it consume 40% of the CPU resource and I can't move the program window. So is there any function that I can use to slow the program down?

What's wrong with consuming 40% of the CPU? That's what it's there for. The problem isn't that your program is running too quickly, the problem is that it's in a tight loop and Windows messages can't be processed. I'm sure people will be along to tell you to use threads, but in this case a message pump is quicker, easier and just as good. Look up PeekMessage and DispatchMessage.

[MikeAThon]

The problem isn't that your program is running too quickly; in fact it's running too slow. You're drawing 10,000,000 line segments and outputting 10,000,000 lines of text. Why do you think that would happen quickly?

This is probably a simulation of your expectation for some other lengthy operation. Chances are that the true lengthy operation is not as graphically intense as your simulation (and if it is, then you're doing it in the wrong place), or if it is graphically intense, that there are much better ways to do this (such as drawing into a bitmap, perhaps in a worker thread, where the bitmap is BitBlt'd to the screen in the OnPaint handler). If you tell us your true goals/objectives, perhaps we can suggest whether a worker thread or a message pump or some other architecture is better.

Mike

[dragonfish]

I think it is better to say something what I really want to do:

I want to code a program to control my experimental setup, there will be a step motor, and a electronic instrument such as a lock-in amplifier. I want to move the step motor to somewhere then read data from lock-in amplifier. Because the step motor is a slow unit, I will need to wait till it reach the position, then I will need to wait again until the lock-in amplifier stabilized. I used a empty loop in a thread to do this before, but now I want to know whether there is a better way to do the waiting thing, I think there should be a better way.

The problem isn't that your program is running too quickly; in fact it's running too slow. You're drawing 10,000,000 line segments and outputting 10,000,000 lines of text. Why do you think that would happen quickly?

This is probably a simulation of your expectation for some other lengthy operation. Chances are that the true lengthy operation is not as graphically intense as your simulation (and if it is, then you're doing it in the wrong place), or if it is graphically intense, that there are much better ways to do this (such as drawing into a bitmap, perhaps in a worker thread, where the bitmap is BitBlt'd to the screen in the OnPaint handler). If you tell us your true goals/objectives, perhaps we can suggest whether a worker thread or a message pump or some other architecture is better.

Mike

[sirama2004]

worker thread

I agree with your answer. I hope you try to say UI thread here.. or I am not aware that I can do drawing from normal worker thread.

[Igor Vartanov]

I was trying the code below:
--------------------------------------------------
void CChildView::OnMatlabTry3()
{
// TODO: Add your command handler code here
CDC *pDC = GetDC();
CString i_String("");
for (int i = 0; i < 10000000 ; i++)
{
i_String.Format("%d", i);
pDC->TextOutA(300, 100, i_String);
pDC->MoveTo(0, 0);
pDC->LineTo(100, 300+i/10000);
}
pDC->DeleteDC();
}
--------------------------------------------------
It is the Event Handler to the menu.

This stuff does not belong in command handler. This blocks the whole thread and does not let Windows process any other window stuff (system messages and user input).

As for the highlighted lines, DeleteDC must be done to DC that was obtained by CreateDC, but GetDC must be released.

When I run this part, the program is running, but it consume 40% of the CPU resource and I can't move the program window. So is there any function that I can use to slow the program down?

The problem with moving window is explained above. You need to change the approach to drawing. Any custom drawing should be done in WM_PAINT handler.

[MikeAThon]

I think it is better to say something what I really want to do:

I want to code a program to control my experimental setup, there will be a step motor, and a electronic instrument such as a lock-in amplifier. I want to move the step motor to somewhere then read data from lock-in amplifier. Because the step motor is a slow unit, I will need to wait till it reach the position, then I will need to wait again until the lock-in amplifier stabilized. I used a empty loop in a thread to do this before, but now I want to know whether there is a better way to do the waiting thing, I think there should be a better way.

Give us an idea of the time intervals involved.

If the time intervals are modest (eg, around 1/4 to 1 or 2 seconds) then one approach might be to set up a timer (call SetTimer) and monitor progress in the WM_TIMER handler. The progress could be monitored using a simple state machine with two states, such as "motor has reached position Y/N" and "lock-in amplifier has stabilized Y/N". The timer could trigger at, for example, every 50-100 milliseconds, and check for progress then.

This approach would not block the UI at all. But it depends on what you need to do in order to monitor progress. For example, if you are able to confirm that the lock-in amplifier is stable simply by reading a few of its outputs quickly, then the approach might work. But if you are able to determine stability only by long-term and continous monitoring of output, then the approach probably would not work.

Mike