get the current document from a different thread

I have an MDI application and I'm trying to use an additional thread to perform some heavy tasks.
But in my thread I fail to get the active child frame with the method MDIGetActive (it returns NULL).

I am aware of the thread local storage of MFC and I have tried to change the module state but with no success.

Does any know how to get to my document from within my thread?

Who is Participating?
JackThorntonConnect With a Mentor Commented:
You generally cannot *directly* access/manipulate GUI objects from outside the thread that created them. The internal Windows GUI mechanisms are not, for whatever reason, threadsafe.

Some things you can do:

(a) make a "global" pointer to the current document, updated from within your GUI thread.

(b) give your thread class a method that allows the GUI thread to "register" the current document when it changes. This method would copy appropriate names/pointers to a member variable, and can be protected with a critical section. Better solution than (a), if for no other reason than I hate globals ;-)

(c) if your worker thread has a message loop, post a thread message to your thread whenever the current (topmost) document changes.

No matter how you go about it, your GUI thread will have to take some of the responsibility of passing information to your worker thread.

- jack
Jack: GUI Objects and Windows are different things (in this respect). Windows (as the OS) Windows (as the colorful thingies) serialize their messages through the queue - no matter from what thread they come. MFC, however, is a different issue

aikimen: two important things:

a) MFC's doc/view architecture is not threadsafe, so you have to synchronize access to your document class on your own. Do you know how to work with Critical Sections (& the like)?

b) Best is, the UI thread passes the document to the worker thread. Use one of the suggestions Jack suggested, or (my favourite) : If you use AfxBeginThread to create for a worker thread, just pass the CDocument * as pParam.

You are responsible to make sure the worker thread doesn't exist (or at least, doesn't access the CDocument anymore) when the document object is deleted.

aikimenAuthor Commented:
I will try to splite the pointes for both the comments.
Train for your Pen Testing Engineer Certification

Enroll today in this bundle of courses to gain experience in the logistics of pen testing, Linux fundamentals, vulnerability assessments, detecting live systems, and more! This series, valued at $3,000, is free for Premium members, Team Accounts, and Qualified Experts.

aikimenAuthor Commented:
I have tried splitting the points but it looks I did not succeed doing so. I appreciate both answers.
I willing to give peterchen his share of points but I don't know how. Any suggestions are welcome.

You can make an "empty" question with a subject like "points for peterchen" and however many points you want to award. When he answers, you can award the points.

One point I was trying to make vis-a-vis Windows & the GUI is that, for example, you cannot seem to SendMessage from one thread to a window created by another thread or you get what appears to be a deadly embrace. That means the supposed "serialization" method/technique/implementation that intercepts the call, puts the message on the target queue, then returns the answer to the caller is not thread safe.

- jack
peterchen092700Commented: split the points, you neet to post a request on the Community Support opage, since EE staff must detract some of your points here.

jack: from MSDN, SendMessage docs
However, the sending thread will process messages from its queue while waiting for its message to be processed.
This prevents the deadly embrace
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.