Rif.: ActiveX Control WMP Thread, execute the Thread inside button click event immediatelly

[G4bandit]

Hi All,

is it possible that my Thread starts immediatelly inside a "button click event" function?

I have used

i = CA_InitActiveXThreadStyleForCurrentThread(0, COINIT_APARTMENTTHREADED);

at the top of main and of the Thread itself.

Create and call Thread:

hThread = CreateThread(0,0,(LPTHREAD_START_ROUTINE)playMusic,mediaPlayerControls2,0,NULL);

void playMusic(LPVOID MPCtrl)
{
int i = 99;
/* Create thread pool here */
i = CA_InitActiveXThreadStyleForCurrentThread(0, COINIT_APARTMENTTHREADED);

WMPLibObj_IWMPControls MPCtrl_l;
DWORD Startzeit = 0, MTime = 0;

/* WMPLib_IWMPControls2play (mediaPlayerControls2, NULL);
Delay(10);
WMPLib_IWMPControlspause (mediaPlayerControls2, NULL);
*/
if(fRecThreadShouldRun)
{
fRecThreadIsRunning = 1;
MPCtrl_l = (WMPLibObj_IWMPControls)MPCtrl;
Startzeit = GetTickCount();
WMPLib_IWMPControlsplay (MPCtrl_l, NULL);
ProcessSystemEvents();
Delay(6);
WMPLib_IWMPControlspause (MPCtrl_l, NULL);
ProcessSystemEvents();
i++;
MTime = GetTickCount()-Startzeit;
DebugPrintf("Vergangene Zeit: %ums\n", MTime);
fRecThreadShouldRun = 0;
fRecThreadIsRunning = 0;
}

[RobertoBozzolo]

It may happen if you haven't selected the event used to start the new thread: a button control responds to several events, EVENT_MOUSE_POINTER_MOVE for example is fired continuously when the mouse passes over a control, even if you don't click it.

Normally the control callback is designed trapping EVENT_COMMIT event, which is fired when you press and then release the button.

[G4bandit]

OK, so far so clear.

I understand that more code is needed.

int CVICALLBACK START5S_CB (int panel, int control, int event,
void *callbackData, int eventData1, int eventData2)
{
int dummy;
int i = 99;
i = CA_InitActiveXThreadStyleForCurrentThread(0, COINIT_APARTMENTTHREADED);

switch(event)
{
case EVENT_COMMIT:

/* Schedule new thread function here */
DebugPrintf("Start Music\n");

if(!fRecThreadShouldRun)
{
fRecThreadShouldRun = 1;
hThread = CreateThread(0,0,(LPTHREAD_START_ROUTINE)playMusic,mediaPlayerControls2,0,NULL);
}

DebugPrintf("End of calling\n");

Sleep(20000);
DebugPrintf("End of Wait after music started\n");

//WMPLib_IWMPControlsstop (mediaPlayerControls2, NULL);
}
return 0;
}

with Sleep(20000);
Memory allocation: OK
Start Music
End of call
Start time measure insisde thread
End of Wait after music started
Start Music
End of call
Passed time: 26255ms

with Sleep(5000);

Memory allocation: OK
Start Music
End of call
Start time measure insisde thread
End of Wait after music started (inside Button Callback)
Passed time(in the posted code: Vergangene Zeit): 11373ms (inside Thread)

So what I see according to the behaviour is that after button is pushed:

- Step inside EVENT_COMMIT

- Create and execute the thread so far that the time measure inside thread is started

  Music ist not started!

- Thread is waiting till EVENT_COMMIT is completly closed, - see different sleep and according different Passed time measured results.

This is for me the actual issue. Why is the Thread waiting for the EVENT_COMMIT to be closed? This is against my understanding of threads.

[RobertoBozzolo]

First of all, is there a reason why you are using Windows API CreateThread () instead of CVI native CmtScheduleThreadPoolFunction ()? I'm saying that because I have no experience on CreateThread function.

Having said this, I don't understand the reason of that long pause in your callback: the paradigm of multithreading is that its execution is independent from the calling thread, so I would expect the callback to start the thread and exit immediately, letting the separate thread work on it's own. Moreover, adding a 20 seconds sleep inside a control callback would completely block the UI until the pause expires!

[G4bandit]

Why I have not used CmtScheduleThreadPoolFunction () I can not answer you for sure. I know I have tried it and stucked on this stuff

NewActiveXCtrl(panelHandle, "WMP", 100, 200, &clsid, &WMP_IID, licStr, &__result);

especially GUID clsid and IID WMP_IID. But do not ask my why I had to use NewActiveXCtrl.

I will try it this way again.

This sample I presented here is abstracted, so no need for sense. But later there will be some waiting or polling so therefore I used wait. And wait 20sec to see that the Thread is not walking in parallel.

But the behaviour still strange regarding CreateThread().