|
It looks ok to me. Time to break out the debugger. Put a breakpoint on your SendMessage and follow the execution to see where it doesn't work.
Judy
|
|
|
|
|
Trevy wrote: BEGIN_MESSAGE_MAP(CMotionAnalyzerDlg, CDialog)
......
ON_COMMAND(ID_TEMPERATURE_CELSIUS, OnTemperatureCelsius)
WM_MENU_CELSIUS()
END_MESSAGE_MAP()
First, remove WM_MENU_CELSIUS from the MessageMap - you're handling it yourself from the WindowProc.
Next, WM_MENU_CELSIUS a user-defined windows message. You need to define it.
#define WM_MENU_CELSIUS WM_APP
Lastly, I would change your SendMessage to PostMesasge. The difference is whether you wait for the message to be processed.
Judy
|
|
|
|
|
Hi have written an addin for the Outlook 2003. All in-coming mails are proparelly backup in the .Msg file at particular location on the disk. The objective of the saving the file in the .MSG format is that on double clicking on the .Msg file it will open in the MS Outlook, or even if we do drag and drop it will open in MS Outlook. The basic thing i want to do is to set passward to .Msg file for opening in MS Outlook. It should either ask for user name and password or any other strategy of authetication. Once it passes this user name and password it should open in MS Outlook, Help me...
-- modified at 8:20 Wednesday 14th March, 2007
Ganesh Paul SPIAN
|
|
|
|
|
Hi guys, I'm new in VS2005 and I can't find the Memory Window that I could open with "View->debug Windows->Memory" in VS6.
Where can I find that window ?
Thanks a lot
|
|
|
|
|
In "Debug" -> "Windows" -> "Memory" (only when you are debugging)
|
|
|
|
|
Hi all,
This might be a stupid question(s) but here goes:
Does a registered dll stay in memory?
And does a dll that doesn't need registered stay in memory?
Thanx in advance.
Regards,
The only programmers that are better than C programmers are those who code in 1's and 0's..... 
Programm3r My Blog: ^_^
|
|
|
|
|
Naively, all kind of DLLs (registered and unregistered ones) are loaded in memory by the OS loader when a process needs to get linked with.
Standard DLLs (such as User32.dll) don't need registration, registration is required only by COM DLLs.
Hope that helps.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: Hope that helps.
CPallini, yes it does help, thank you very much. But the other thing is after the function call will the dll still reside in memory? (Registered and those who don't need registration)
Thanx for your reply.
Regards,
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r My Blog: ^_^
|
|
|
|
|
Programm3r wrote: But the other thing is after the function call will the dll still reside in memory? (Registered and those who don't need registration)
Which function call ?
In fact, you have two ways to load your dll. Either explicitely (by using LoadLibrary) or implicitely (you link to a library provided with the dll that contains information about how to load the dll's).
In the first case, the Dll is loaded when you call LoadLibrary and is released when you call FreeLibrary (if there is no other application that uses it). Or it is released when your application exits.
In the second case, the dll is loaded when your application is started an is released when your application terminates.
|
|
|
|
|
Cedric Moonen wrote: Which function call ?
Thanx Cédric, you have already answered my question in your thread.
Regards,
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r My Blog: ^_^
|
|
|
|
|
Registration of a DLL has nothing to do with when the DLL is loaded into the address space of the process that uses the DLL. Registration of a DLL is only needed if the DLL exposes a function called DllRegisterServer which usually is only applicable for COM DLLs.
Read more about DLL loading here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thank you very much Roger.
Regards,
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r My Blog: ^_^
|
|
|
|
|
Programm3r wrote: But the other thing is after the function call will the dll still reside in memory?
Oh YES, of course...
The OS loader may discard the DLL if the process detaches from. For an ordinary DLL, if the process implicitely links with (e.g. you have used the DLL's *.lib as input for the LINKER; this is the most common way...) the detaching happens on process termination; on the other hand, if the process explicitely links with (via LoadLibrary call), then the process can, at any time, discard the library by means of the corrensponding FreeLibrary call.
COM uses a completely different approach, a component DLL may be discarded by the COM when the component it's no more needed, i.e. when the reference count of the component reaches 0 (see life cycle of COM components in MSDN, however, basically, calling Release() on a COM pointer, allows COM to discard the related DLL).
Hope that helps
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Thank sfor your help CPallini, really appreciate it.
Regards,
The only programmers that are better than C programmers are those who code in 1's and 0's..... 
Programm3r My Blog: ^_^
|
|
|
|
|
you're welcome.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Now tell me an MFCxx.dll is a COM dll or a standard DLL?
Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.
|
|
|
|
|
VuNic wrote: Now tell me an MFCxx.dll is a COM dll or a standard DLL?
none. you have to provide it with your application binary, or place it in the path...
|
|
|
|
|
That's what a standard win32 dll dear.
Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.
|
|
|
|
|
VuNic wrote:
That's what a standard win32 dll dear.
he he he
|
|
|
|
|
Hello comunity,
i try to save a struct variables to a map!
Simple struct with some CStrings as member!
Which one(Map) to use for that: CMapStringToOb, CMapStringToPtr, CMapWordToPtr?
regards
break;
|
|
|
|
|
in the context of MFC, I would use CMapStringToPtr or CMapWordToPtr depending on the key.
but I strongly suggest you start using STL and std::map.
|
|
|
|
|
Maximilien wrote: I strongly suggest you start using STL and std::map
I second that.
MFC also has a template version called CMap which works similar to std::map. Haven't tried it though since I prefer the STL version.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I thought CMap used a hash table and thus was similar to the non-standard hash_map as opposed to std::map.
std::map does not (as far as I know) provide constant average lookup times where CMap does. This would, in my opinion, indicate that std::map is not a good substitute (as far as performance is concerned) for CMap.
This is the main reason I still use CMap, at least until the new "standard" version of hash_map finally gets fully approved.
Maybe I'm missing something so correct me if that's incorrect
|
|
|
|
|
Regarding the performance issue you're probably right, but I cannot verify this since, like I said, I haven't used CMap very much. Whether this performance boost is necessary or not would depend on how the map is used and how frequently elements have to be looked up.
I prefer the STL version due to portability reasons, CMap only exists in MFC library.
If I e.g. develop software in C++ aimed for an embedded system I wouldn't find CMap in that environment. So if I know how to use the STL library I can write more portable code.
If the std::map implementation becomes a performance issue I will first re-evaluate my design and if I find the design to be allright I probably will write my own mapping container using a hash table or similar.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: So if I know how to use the STL library I can write more portable code
Fair enough. I would agree that the portability issue is a big one. I hesitated to use hash_map only because of all the warnings about each library implementing slightly different variations of it and the fact that the "standard" extension for it will likely be of a different name. I'd hate to learn a specific library only to have to change once again when the standard was ratified.
I'm stuck in a windows only OS environment so the MFC's portability issues have been non-existent but I keep forgetting that's not the case for everyone.
Anyway, I'm constantly struggling to understand it all and I posted the comment out of fear that I may have missed something between std::map, hash_map, and CMap. My main concern was the comparison between std::map and CMap since, as far as I know, std::map does not use a hashing table and thus the similarities are not enough to consider one a direct replacement for the other. CMap and hash_map appear, at first glance, to be closer.
One of these years this stuff may all finally make some sense to me. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
