C / C++ / MFC

Re: Calling GUI functions from a worker thread in MFC??

18-Jul-13 11:39

Every normal gui framework is single threaded that means: you can access gui related data and functions only from the gui thread (that is the main thread in case of MFC). Its only blind luck that your app worked on WinXP most of the time. Multithreaded programs become quite non-deterministic and the same is true for the occurrence/reproduction of their bugs. Now you are "lucky" that you have a quite reliable repro case for your bug that was a bug even on WinXP!

1. AfxGetMainWnd() is a gui related call so I would call it only from the main/gui thread. Call AfxGetMainWnd() from the gui thread when you create the worker thread and pass the window pointer to the thread as a CreateParam. Since SendMessage() and PostMessage() are thread safe WinAPIs the same is true for the SendMessage() and PostMessage() methods of the window.
2. On the worker thread use the PostMessage() or SendMessage() method on the window pointer you received as a ThreadCreateParam. PostMessage(WM_CLOSE, 0, 0) should work if you use directly the window pointer without AfxGetMainWnd().
3. To call UpdateAllViews() do the following: Define your own window message. Either WM_APP+(0..1000 or whatever) or WM_USER+... Then use again PostMessage() on the window pointer to post your own window message. In the message map of your window receive your user defined message with ON_MESSAGE(WM_MYMESSAGE, OnMyMessageMethod). Your OnMyMessageMethod() will be called from the gui thread so it will be safe to call UpdateAllViews() from there. Use PostMessage() instead of SendMessage() if you don't want the worker thread to block until the end execution of OnMyMessageMethod() on the gui thread.

BTW: Here is the implementation of AfxGetMainWnd() of VS2010:

C++

_AFXWIN_INLINE CWnd* AFXAPI AfxGetMainWnd()
	{ CWinThread* pThread = AfxGetThread();
		return pThread != NULL ? pThread->GetMainWnd() : NULL; }

If your worker thread was created with non-mfc api then this AfxGetMainWindow() returns NULL always if called from your worker thread.

«_Superman_»18-Jul-13 21:25

«_Superman_»

18-Jul-13 21:25

Passing a window pointer between threads is not a good idea in MFC.
Instead, you must pass the window handle behind the pointer.
You can convert the handle to a pointer using the CWnd::FromHandle static method.

Rest of the things are spot on. Thumbs Up | :thumbsup:

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++) (October 2009 - September 2013)

Polymorphism in C

Re: Calling GUI functions from a worker thread in MFC??

pasztorpisti18-Jul-13 22:56

Re: Calling GUI functions from a worker thread in MFC??

18-Jul-13 22:56

If you can guarantee that the lifetime of the window spans that of the worker thread activity (and it does since it is the main window) then its OK to pass the pointer but it has no advantage over your solution because PostMessage and SendMessage is available in both cases.

Kiran Satish19-Jul-13 10:46

Kiran Satish

19-Jul-13 10:46

Thanks for your reply. Probably I should show how I am currently defining my thread and how I am using it.

Declaration:

C++

static	DWORD WINAPI ThreadProcess(LPVOID pParam);

Definition:

C++

DWORD WINAPI CMainDoc::ThreadProcess(LPVOID pParam)
{
	CMainDoc *parent = (CMainDoc *)pParam;

	while(TRUE) {
		switch(::WaitForSingleObject(2, parent->m_eMsg, FALSE, INFINITE)) {//Process the message
		case WAIT_OBJECT_0:
//access some variables in the document using parent pointer and update them such as parent->var1, parent->var2 etc.
			parent->UpdateAllViews(NULL);
			break;
		case WAIT_OBJECT_1://process close msg		
			pObject->PostMessage(WM_CLOSE, 0, 0);
				break;
}
}

Now if I do the way you suggested, do I need to send the handle returned from AfxGetMainWnd() along with a pointer to the document in 'pParam'?

PKNT

Re: Calling GUI functions from a worker thread in MFC??

pasztorpisti19-Jul-13 14:01

Re: Calling GUI functions from a worker thread in MFC??

19-Jul-13 14:01

If you don't call MFC functions from your worker thread (its best not to call them) then its OK to go with non MFC threads so the kind of your thread doesn't matter. As I see you have already used up your pParam to send the doc pointer. You can send any number of parameters to your thread this way:

C++

struct MyThreadParamStruct
{
  CMainDoc* parent;
  CWnd* mainwnd;
};

void StartThreadTask()
{
  MyThreadParamStruct* thread_param = new MyThreadParamStruct;
  // TODO: filling thread_param
  CreateThread(..., thread_param, ...)
  ...
}

DWORD WINAPI CMainDoc::ThreadProcess(LPVOID pParam)
{
   std::unique_ptr<MyThreadParamStruct> thread_param((MyThreadParamStruct*)pParam);
   // TODO: use thread_param
   ...
}

Kiran Satish19-Jul-13 16:18

Kiran Satish

19-Jul-13 16:18

Looks like std::unique_ptr is not defined in VS2008. I got it working using standard form like

C++

ThreadNetMsgParamStruct *pThreadParams = (ThreadNetMsgParamStruct *)pParam;

But the problem is, a CDocument class can not process windows messages. Is there any other straight forward way to replicate UpdateAllViews() command without calling it directly?

thanks

PKNT

Re: Calling GUI functions from a worker thread in MFC??

pasztorpisti20-Jul-13 6:07

Re: Calling GUI functions from a worker thread in MFC??

20-Jul-13 6:07

unique_ptr is like std::auto_ptr (its younger brother in stl). It deletes the pointer automatically when it goes out of scope (in this case at the end of the function or if you return from the func). The struct instance must be deleted otherwise you cause a memory leak. You have to send a message to a window and not to a document object. If you can't solve the problem using the info I provided (theory + 90% of the code needed) then either ask a colleague to do it for you or start learning about multithreading+gui and their relationship.

David Crow19-Jul-13 4:43

David Crow

19-Jul-13 4:43

Kiran Satish wrote:

I am trying to call a GUI function from a worker thread...

Bad idea. See here for why.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

Re: Calling GUI functions from a worker thread in MFC??

Erudite_Eric22-Jul-13 4:59

Erudite_Eric

22-Jul-13 4:59

Just dont do it. Think of your thread as being in a different process, how would you communicate between them? With PostMessage and SendMessage. So create some custom IDs, handle them in your main window proc and post or send using those IDs from the thread.

You have to keep it clean on Windows, you cant bodge stuff. It might work for a bit, but eventually it will break.

Re: Calling GUI functions from a worker thread in MFC??

Kiran Satish22-Jul-13 5:23

Kiran Satish

22-Jul-13 5:23

Thanks, that's exactly how I did it over the weekend and it works well.

PKNT

How to disable copy/paste in CEdit?

Donguy197617-Jul-13 5:53

Donguy1976

17-Jul-13 5:53

Hi there,

Is there a way to disallow users from pasting anything to CEdit box control?

Right now they can right click and select the PASTE menu option.
And also do a Control + V.

How to disable this?

please give some sample code.

Thanks in advance.

NotPolitcallyCorrect17-Jul-13 6:05

NotPolitcallyCorrect

17-Jul-13 6:05

Donguy1976 wrote:
Is there a way to disallow

Yes there is.

See Subclassing CEdit to disable clipboard operations[^] and see if that helps you.

Erudite_Eric17-Jul-13 23:30

Erudite_Eric

17-Jul-13 23:30

Oh, but he said "Please give me some code". Are you sure he can handle a link? It might involve thinking....

NotPolitcallyCorrect18-Jul-13 1:40

NotPolitcallyCorrect

18-Jul-13 1:40

Erudite_Eric wrote:
might involve thinking

If 99% of the people asking questions here actually put forth any effort in thinking, then 99% of the questions would disappear.... Smile | :)

ofstream optimization problem

Erudite_Eric17-Jul-13 23:33

Erudite_Eric

17-Jul-13 23:33

Here you go:

C++

<pre>	if (add_uevent_var(env,
		   "MODALIAS=usb:"
		   "v%04Xp%04Xd%04Xdc%02Xdsc%02Xdp%02Xic%02Xisc%02Xip%02X",
		   le16_to_cpu(copy_dev->descriptor.idVendor),
		   le16_to_cpu(copy_dev->descriptor.idProduct),
		   le16_to_cpu(copy_dev->descriptor.bcdDevice),
		   copy_dev->descriptor.bDeviceClass,
		   copy_dev->descriptor.bDeviceSubClass,
		   copy_dev->descriptor.bDeviceProtocol,
		   alt->desc.bInterfaceClass,
		   alt->desc.bInterfaceSubClass,
		   alt->desc.bInterfaceProtocol))
		return -ENOMEM;

modified 18-Jul-13 9:11am.

doug2517-Jul-13 4:43

17-Jul-13 4:43

Hi,

I'm using wofstream to write text to a file

my problem is that, with any level of optimization, neither write() or << allows me to write a wstring or c string in the form of (WCHAR*).

example

C++

WCHAR* str = new WCHAR[MAX_PATH];
wcscpy(str, L"walk");
myfile.write(str, wcslen(str));

No string written to file

C++

wstring str2 = L"walk";
myfile << str2;

No string written to file

I am able to to do

C++

myfile << "String";

how do I fix?

Richard MacCutchan17-Jul-13 4:53

17-Jul-13 4:53

Unfortunately you don't. The wstream types take wide characters in but write them out as normal ASCII. You should use the old C-style fwrite or the newer WriteFile functions which allow you to specify the output character size.

Use the best guess

doug2517-Jul-13 5:06

17-Jul-13 5:06

so wofstream can't be optimized? it all works well without optimization

Richard MacCutchan17-Jul-13 5:22

17-Jul-13 5:22

doug25 wrote:
so wofstream can't be optimized? it all works well without optimization

Sorry, I don't understand what you are saying here. As far as Irecall from all the tests I have run, you cannot write wide characters via a wstream. I would be interested to see the code you have that does work. In the meantime I will retry my own tests.

Use the best guess

doug2517-Jul-13 5:48

17-Jul-13 5:48

sorry, I've discovered what was happening, it isn't a problem with wstring optimazation. I was converting the file to another format the functions i'm using behave differently with optimization.

The problem is nothing to do with vectors or wstrings. it's a directx set of functions i'm using that fail when optimazation is turned on. It was difficult to determine tat this was where the program was failing.

modified 17-Jul-13 12:17pm.

Richard MacCutchan17-Jul-13 7:12

17-Jul-13 7:12

doug25 wrote:
the functions i'm using behave differently with optimization.

I find that very difficult to believe. Much more likely is that you have a bug somewhere that only shows when you have optimization turned on.

Use the best guess

doug2517-Jul-13 9:38

17-Jul-13 9:38

well, it could be a mistake I've made but I've managed to find exactly where the error occurs by using #pragma optimize("g", off)
and
#pragma optimize("g", on)

it's one function, I can't see any mistakes

C++

#pragma optimize("g", off)

void AddDataObject(ID3DXFileSaveObject* xFileSave, ID3DXFileData* child, ID3DXFileSaveData* xSaveData)
{
	// Add data for this child then each of it's children
	SIZE_T nChildren = 0;
	child->GetChildren(&nChildren);

	// add child
	GUID templateid, id;
	child->GetType(&templateid);
	child->GetId(&id);
	char name[MAX_PATH];
	
	SIZE_T sz;
	child->GetName(name, &sz);

	SIZE_T dataSize;
	void* data = NULL;

	child->Lock(&dataSize, (LPCVOID*)&data);
	
	if(xSaveData)
	{
		xSaveData->AddDataObject(templateid, name, (const GUID*)&id, dataSize, data, &xSaveData);
	}
	else
	{
		xFileSave->AddDataObject(templateid, name, (const GUID*)&id, dataSize, data, &xSaveData);
	}

	child->Unlock();

	// For each child of child, add child data
	// Add data for all sub children (recurse)
	for(int i=0; i<nChildren; i++)
	{
		ID3DXFileData* ch = NULL;
		if(SUCCEEDED(child->GetChild(i, &ch)))
		{
			// Add data for children of this child (ch)
			AddDataObject(xFileSave, ch, xSaveData);
		}
	}
}

#pragma optimize("g", on)

Richard MacCutchan17-Jul-13 20:57

17-Jul-13 20:57

What problem and where does it occur?

Use the best guess

doug2518-Jul-13 2:48