Here's a question though... Which is more efficient... void IncRef(int & i) { ++i; } or this... void IncRef(int i) { ++i; } The way I think about it is we are still passing pointer to another variable in a previous stack frame. Therefore in this case would it make any difference performance wise since we are still just dealing with a number whether it be a memory location or an integer. I know that if this was a pointer I would be correct in this case but I'm not sure about references. Please feedback though I may be wrong.

Please note that Microsoft really are trying to kill off DAO. If you want to future proof your application I would reccommend switching to ADO (there are some C++ wrapper classes for this).

aaahhhh COM run for the hills. Truthfully this is my usually reaction. But FEAR NOT!!! Your dealing with an OCX file. Simply register the file on your system using regsvr32.exe. Then in the fabulous VC6 menu system 'Project', 'Add to Project', 'Components and Controls' then choose the Registered ActiveX Controls folder and select your component. This will automatically generate all the wrapper classes for you (up yours VB boys :laugh:) Then you can drag and drop on your new active control and get events, manipulate it whatever. #import is really used for interacting with ATL COM objects that are not ActiveX based.

Ensure that in your WORK() method nothing is trying to steal the capture of the mouse. Check for SetCapture() API calls.

screw COM, it's for VB programmers ;P There are multiple options you have. You could try the following... - Use sockets. CSocket kicks butt for simple communication and free of charge you also them communcating on different machines. - Create a dummy window and try using a registered windows message (RegisterWindowMessage in MSDN). - Use pipes. Never done this myself but its another form of process communcation. - If you really want to pass a lot of data and want it to be very speedy but at the same time a bit of a management nightmare try creating some shared memory between the applications.

You should only use RegisterWindowMessage() to send messages to another application running in a different process. For internal window message communication you shouldn't really use this. But don't worry if you do when your application shuts down (providing another application hasn't registered the same message) the operating system will gradually release its mapped resource on this string. If you are just doing this from within your own application have a look at ON_MESSAGE in MSDN. This is the correct way to deal with custom messages from within your application (unless of course you want to pass messages between GUI threads which would use ON_THREAD_MESSAGE)

I tried the same thing a while back. And it does seem that WM_KEYUP messages do not get processed. Who knows? A solution to your problem is a simple keyboard hook. This makes it very reliable to get all keyboard messages back. All it involves is a simple call to SetWindowsHookEx and a call back function for the handling the keyboard messages. Here's a link to a code project article that answers this problem... http://www.codeproject.com/dll/keyboardhook.asp?target=keyboard%7Chook

Well there's a few ways to tackle this problem. Indeed you could use a timer. But the most important thing for you to understand is how message queues in Windows work. However, first the answer to your question. Try creating your own custom message ad handler for it first therefore at the top of your dialog CPP file... #define WM_MYOWNMESSAGE WM_USER + 1001; ... Then in the header file put... afx_msg LRESULT OnMyOwnMessage(WPARAM wParam, LPARAM lParam); ...Then the appropriate body for it... LRESULT CMyDialog::OnMyOwnMessage(WPARAM wParam, LPARAM lParam) { ... Show the file dialog box (I know it has to be modal) return 0; }; ... And finally in the body put... ON_MESSAGE(WM_MYOWNMESSAGE, OnMyOwnMessage) ... in the BEGIN_MESSAGE_MAP section... ... To call the message handler put this in the OnInitDialog function just before it returns... PostMessage(WM_MYOWNMESSAGE, 0, 0); So okay, this should work. But why should this work? You could do the same thing with a timer (Its another message WM_TIMER). Well as you well know OnInitDialog gets called when all the handles for all the windows you are creating are created but not shown. We post a custom message on to the message queue of the dialog box. This eventually gets processed. As I'm placing it on the message queue in OnInitDialog it will only get processed after this point in which the dialog box will be shown. I'm sure there are other ways but I find this one works very well for me :!)

I haven't looked at IPMessenger but the ideas behind are quite simple. For a peer to peer network program on an Intranet one of the best things to do is send out a UDP broadcast message. Other computers on the same subnet could then reply and peer to peer links can be created between each instance of the program. Other than that, a server needs to be used somewhere along the line (but then it wouldn't be true peer to peer). I advise reading a good book on TCP/IP. It might be also worth investigating TCP/IP multicasting to form a node tree. :wtf:

Yeah, thanks for that comprehensive answer to the complex subject of multithreading and message queueing that I was trying to find out about. :wtf:

;PHere's an interesting question... What are the consequences of creating windows (by using either Create(..) or DoModal() in a worker thread. Since a worker thread has no message queue and AfxGetMainWnd() returns the window associated with the thread, how will it work? Should it work? What are the effects? The reason I'm asking, is I've noticed some part of the program I'm been assigned to create windows in worker threads. I know the best way is to create a GUI thread and assign the m_pMainWnd variable to the created window. I really just want to know the effects of windows in worker threads. Regards, GeMe_Hendrix ;P