|
Is it safe to pass MFC objects inbetween threads .
I dont fell any issue but ...
is there any special case were i should not pass
an MFC object inbetween thread.
Vikas Amin
Embin Technology
Bombay
|
|
|
|
|
vikas amin wrote: is there any special case were i should not pass
Yeah CDC objects.
Instead use HDC.
Jesus Loves ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
--Owner Drawn
--Nothing special
--Defeat is temporary but surrender is permanent
--Never say quits
--Jesus is Lord
|
|
|
|
|
|
It depends on what you mean by "pass" MFC objects and what kind of MFC objects you are "passing".
For instance you should never access any GUI objects from a worker thread to prevent a deadlock situation. Read this[^] if you want to know more. This article is also great to know about thread handling.
In the article forum that belongs to the article there is also a discussion regarding your original question.
I know that CAsyncSocket has some issues when being accessed from different threads, but I can't remember them at the top of my head.
Creating MFC objects, such as CString objects, on the heap and "pass" them to another thread using ::PostMessage is always save provided that you forget about the object in the thread that created the object setting the pointer to NULL and you only have one receiving thread.
You could also use some container class, such as std::queue, to "pass" objects from one thread to another. But then you have to provide synchronization with mutual exclusions such as CRITICAL_SECTION to prevent two threads accessing the same object simultaniously. You simply "lock" the container when accessing objects in the container and "unlock" the container when you're done.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
-- modified at 6:11 Friday 13th January, 2006 Added hint about article forum discussion.
|
|
|
|
|
many MFC classes (not sure if its all) are very specific to the thread it was created in.
So if you pass MFC objects from one thread to another, and when you try to use it it will ASSERT.
-Prakash
|
|
|
|
|
vikas amin wrote: Is it safe to pass MFC objects inbetween threads .
Not all, MFc library isnot consider as thread safe library
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
thx for the information u have provided
Vikas Amin
Embin Technology
Bombay
|
|
|
|
|
Hi，
I encountered a problem about wprintf() to display unicode chars which is >
255 in my console app. I am sure I have defined _UNICODE in my VC6 Project
Setting.
I had a search with google and found that my question was some like the
case:
http://blog.kalmbachnet.de/?postid=23 .
Is it true that there are some bugs in wprintf()?
Thanks for your help.
David
|
|
|
|
|
We can set a window "always on top" by using SetWindowPos() with HWND_TOPMOST. I wonder is there a way to make a window is not only "always on top" but also "always activated". It means that window will be always activated, but we will still be able to activate another windows. Plz help me solve this problem. Tnx alot.
|
|
|
|
|
Only one window can be the active window. We can't activate another window but still have the first active - That would mean there would be two active windows. What are you trying to achieve?
Steve
|
|
|
|
|
What do you mean by "activated"?
Usually "activated" means that the window has the input focus which means that no other window will get keyboard input for instance.
Is this really what you want? (I don't think so, but that's just me...)
Only one window at any given time can be "active" in that sense.
Perhaps you mean that the title bar of the window should still look as if the window is "active" even if another window has got the input focus.
That's another thing and should be possible, but I don't have a solution for it.
However, I don't consider it very user friendly since the user will have multiple windows that seems to have input focus.
What is it you want to accomplish?
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
|
Tnx alot. Two windows cant be activated. But could we make a window always activated ??? I try to use PostMessage() with WM_MOUSEACTIVATE in a while loop but it make my program run very slowly and the result is not always as I want. Anyone have a solution ?
-- modified at 6:45 Friday 13th January, 2006
|
|
|
|
|
Do you want your window to be the only activated window in the whole system or just within your application? Either way you could use the SetWindowsHookEx API to install a WH_CBT hook to do this. If it's system wide the hook procudure will have to live in a DLL further complicating you life.
Steve
|
|
|
|
|
I am assuming you are writing the code for the window you want to keep always activated. If yes, you can handle "WM_ACTIVATEAPP" in its WndProc. This message is sent to any window that is about to lose focus or to gain focus, the difference between losing and gaining focus is the WPARAM - it is FALSE if it islosing focus.
Thus, you can use that message to trap the fact that you are about to lose focus (some other window is trying to come on top). Once you sense that, you can take corrective action by calling
SetWindowPos( hWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE );<br />
ShowWindow( hWnd, SW_SHOWNORMAL );
That should return the window to active state - quite rude to other windows though!
Now, assuming that you are NOT directly writing the code of this window, you can write a small hidden program that will always run in the background, and constantly call GetForegroundWindow() [see here[^]] or GetTopWindow() [see here[^]], and compare the HWND value it gets with the handle of your window. To do that, it must first get the HWND handle of your window, which it can initially get by calling FindWindow(). If it ever sees that the top window is something else than your window, it can call the same functions as described above with the handle of your window to bring it on top again.
Disclaimer - I have not tried this actually. Let me know if this works.
Koushik Biswas
-- modified at 19:55 Friday 13th January, 2006
|
|
|
|
|
overload the WM_KILLFOCUS of your windows, and then, call WM_SETFOCUS from within...
this way, whenever the window looses the focus, it gets it back
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VisualCalc 3.0]
|
|
|
|
|
In function WindowProc(), I switch msg WM_KILLFOCUS and then, I PostMessage WM_SETFOCUS (i try SetFocus() function too), but it cant keep the focus for my window. When I click another windows, my window lose the focus. Is there anything wrong ?
|
|
|
|
|
Map the WM_NCACTIVATE ,and in that set any of your child controls to set focus ;-
void CTestDlg::OnNcActivate(<br />
BOOL bActive<br />
)<br />
{<br />
int a;<br />
c_edit.SetFocus ();
::SendMessage (this->m_hWnd ,WM_ACTIVATE,0,0);<br />
}
-- modified at 9:50 Friday 13th January, 2006
|
|
|
|
|
I am assuming you are writing the code for the window you want to keep always activated. If yes, you can handle "WM_ACTIVATEAPP" in its WndProc. This message is sent to any window that is about to lose focus or to gain focus, the difference between losing and gaining focus is the WPARAM - it is FALSE if it islosing focus.
Thus, you can use that message to trap the fact that you are about to lose focus (some other window is trying to come on top). Once you sense that, you can take corrective action by calling
SetWindowPos( hWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE );<br />
ShowWindow( hWnd, SW_SHOWNORMAL );
That should return the window to active state - quite rude to other windows though!
Now, assuming that you are NOT directly writing the code of this window, you can write a small hidden program that will always run in the background, and constantly call GetForegroundWindow() [see here[^]] or GetTopWindow() [see here[^]], and compare the HWND value it gets with the handle of your window. To do that, it must first get the HWND handle of your window, which it can initially get by calling FindWindow(). If it ever sees that the top window is something else than your window, it can call the same functions as described above with the handle of your window to bring it on top again.
Disclaimer - I have not tried this actually. Let me know if this works.
Koushik Biswas
|
|
|
|
|
I try the first, it make the window "always on top", not "always activated".
The second, I think it will not succeed. Because it is not really "always activated" : another window will be activated (by a click ex.), and then, we activate the window we want. That's what you do, but it's not the achieve.
Tnx alot.
-- modified at 21:48 Friday 13th January, 2006
|
|
|
|
|
Hi,
I have a dialog will get input from a 2D barcode scanner,
about a couple hundred characters.
I already override the PreTranslateMessage but still
not sure what's best way to capture the scanner input
as stdin.
I think my problem is that I am not too familiar with
Windows messaging. So, When I got a lot messages
inside PreTranslateMessage, I don't know how to filter
out & convert the data I want.
Can someone give me some suggestions?
Thanks,
Kevin
|
|
|
|
|
I'm not sure what you're asking....Does the scanner input come in a keyboard messages?
Steve
|
|
|
|
|
kevincwong wrote: Capture all keyboard input inside a dialog
You can do this by overriding PreTranslateMessage
append this code inside your PreTranslateMessage handler.
if(pMsg->message == WM_KEYDOWN)
{
}</code>
Regards,
Rajesh R. Subramanian
You have an apple and me too. We exchange those and We have an apple each.
You have an idea and me too. We exchange those and We have two ideas each.
|
|
|
|
|
Rajesh,
Great! that's exactly what I want. I know I read it from somewhere
before but just can not remember how to do so.
btw, when I pressed a key (for example 'a', the pMsg->wParm is 65,
']' is 221), I think the pMsg->wParm is the scancode (not ASCII code).
Am I correct?
Thank for you help!!
Kevin
|
|
|
|
|
kevincwong wrote: btw, when I pressed a key (for example 'a', the pMsg->wParm is 65,
']' is 221), I think the pMsg->wParm is the scancode (not ASCII code).
No, in the cases of the normal non-special keys, the values will be the ASCII codes for the keyboard key pressed (not the actual character received). So when you press <A> on the keyboard, you get a value of 65, which is the same as 'A'. This should be the code received regardless of things like SHIFT or CTRL key state.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
