🔒 Locked

Multithreading :: MFC

Started by kuphryn Apr 17, 2002 at 4:26 PM 3 replies 450+ views

Original Post

Apr 17, 2002 at 4:26 PM

Hi. I am working on my first "real" Windows program. I am at a point in the implementing process where I see a need to multithread one specific job. I will give a good example of something that is very similar to what I am to implement. I will then give my thoughts on a possible solution. I have no prior experience with multithreading, but Jeff Prosise''s book does wonders. I am design a dialog box with a progress bar *very similar* to the one you see when you download a file using IE. When you download a large file (your download bandwidth is slow), you can see the progress of the download process. The process bar is easy to implement. The part that makes IE progress bar special is you can *still use* IE during the download process. The key is multithread. Here is my design. ----- -User activate a feature (via menu) -View creates a dialogbox w/ progressbar (position 0) -Dialogbox sends a message to MainFrm. -MainFrm redirect message to View -View calls function in Document to begin data processing -View also passes the function a pointer to dialogbox -Document starts a new thread (worker thread) -Thread begin processing data -Thread sends message back to Document when applicable -Document calls updated progressbar via pointer to dialog ----- Again, this is my first experiment with multithread. Is there anything wrong with the design above? I left some small features out. I will include it soon. Thanks, Kuphryn

Stoffel

Apr 17, 2002 at 5:57 PM

quote:
Original post by kuphryn
-User activate a feature (via menu)
-View creates a dialogbox w/ progressbar (position 0)
-Dialogbox sends a message to MainFrm.
-MainFrm redirect message to View
-View calls function in Document to begin data processing

If you send a command instead of a message from your dialog box, it will get routed to the document automagically. Look up "command routing".

quote:

-View also passes the function a pointer to dialogbox
-Document starts a new thread (worker thread)
-Thread begin processing data
-Thread sends message back to Document when applicable
-Document calls updated progressbar via pointer to dialog

Just be sure that the dialog and the document don''t both have to know about each other. You shouldn''t have any circular dependencies. This may require reversing the direction of your queries and commands, but it''s hard to tell from here.

kuphryn

Author

kuphryn

Apr 17, 2002 at 6:37 PM

Thanks.

Kuphryn

Shannon Barber

Mod

368

Shannon Barber

Apr 17, 2002 at 8:58 PM

Unless there''s another way to do it, the message pump has to spin in order for the progress bar to be updated (on the screen). And there''s some issues with using a CWnd pointer from another thread (IIRC, MFC uses TLS to store the message map).

You can have the worker thread send a custom message to the main window/thread that tells it to update the progress bar, or you can update the progress bar using WM_TIMER messages by polling the current progress/state.

Also, making the dialog modeless is probably a good idea if you want to keep using the app.

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

[Look for information | GDNet Start Here | GDNet Search Tool | GDNet FAQ | MSDN RTF[L] | SGI STL Docs | STFW | Asking Smart Questions ]

[Free C++ Libraries | Boost | ACE | Loki | MTL | Blitz++ ]

Shamelessly ripped from Oluseyi

kuphryn

Author

kuphryn

Apr 18, 2002 at 1:48 AM

Thanks.

Yes. I did made the dialog box a modeless.

Kuphryn

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.