timer control issue under Windows 7, from CVI 2013 under XP

[pblase]

I have a program that runs well under Windows XP. Two of the subwindows of this program use control timers @ 1Hz to determine if data isn't received from the ADC. When I launch the program under Windows 7, it seems to operate fine until I try to open one of these two windows. The timers appear to bung up the works and the windows can take up to 20 seconds to respond to a mouse click. I put a printDebugf() statement in the timer callback and it prints perhaps once/5 seconds and often hangs up for long periods of time. Any ideas would be appreciated.

[pblase]

Ok. I was wrong, the problem isn't the timers, or isn't only them.

It appears to be a problem with multithreading: these two windows are run from their own threads.

For instance, the first window is started with

CmtStatus = CmtScheduleThreadPoolFunctionAdv (Level1_poolHandle,
                                              VOscopePanelMain, NULL,
                                              THREAD_PRIORITY_ABOVE_NORMAL,
                                              CB_NotifyThreadFunctionExecState,
                                              (EVENT_TP_THREAD_FUNCTION_BEGIN | EVENT_TP_THREAD_FUNCTION_END),
                                              0,
                                              CmtGetCurrentThreadID(),
                                              &VOSCOPE_ThreadFunctionID);													  &VOSCOPE_ThreadFunctionID);

Where VOscopePanelMain is the main function for this new thread.

VOscopePanelMain then loads the panel and goes into a RunUserInterface() loop:

	iHandle_VOscope = LoadPanelEx (0, VOSCOPE_UIR_file, VSCOPE, __CVIUserHInst);
	DisplayPanel (iHandle_VOscope);
	RunUserInterface();

Which exits when the window is closed.

There's something wrong with the priority assignments here.

[RobertoBozzolo]

I have made a few trials to use high level priorities in my applications and all ended up with strange behaviour and eventually the system locked more or less like your situation. I have found that a better behaviour can be obtained by setting the thread sleep policy to "do not sleep" so that that part of the program is not interrupted waiting for other tasks to complete. Is it to be said though that I load the UI always in the main thread and don't call RunUserInterface while inside my threads, so my scenario is a bit different from yours.