|
Maximilien wrote: timbk wrote:
afx_msg void OnMsjGuardarConfig();
shouldn't that be :
LRESULT OnMsjGuardarConfig(WPARAM wParam, LPARAM lParam);
Ok , I tried with this:
LRESULT OnMsjGuardarConfig(WPARAM wParam, LPARAM lParam);
instead of
afx_msg LRESULT OnMsjGuardarConfig(WPARAM wParam, LPARAM lParam);
and besides :
afx_msg void OnMsjGuardarConfig();
instead of
afx_msg void OnMsjGuardarConfig();
Is this what you meant?
No erros compiling, but I get the same exception.
|
|
|
|
|
Use WM_APP + 1 instead of WM_USER + 1.
|
|
|
|
|
«_Superman_» wrote: Use WM_APP + 1 instead of WM_USER + 1.
Thanks for your answer, I did what you said, but i get the same exception.
|
|
|
|
|
Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\inpout32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\advapi32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\rpcrt4.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\secur32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\MFC42D.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\MSVCRTD.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\gdi32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\user32.dll', no matching symbolic information found.
Loaded symbols for 'C:\WINDOWS\system32\MFCO42D.DLL'
Loaded 'C:\WINDOWS\system32\imm32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\mfc42loc.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\comctl32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\msvcrt.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\shlwapi.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\uxtheme.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\MSCTF.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\version.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\MSCTFIME.IME', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\ole32.dll', no matching symbolic information found.
Loaded 'C:\Archivos de programa\Internet Download Manager\idmmkb.dll', no matching symbolic information found.
Warning: dialog data checkbox value (2117840950) out of range.
Warning: dialog data checkbox value (1598735280) out of range.
First-chance exception in Calibracion.exe (MFC42D.DLL): 0xC0000005: Access Violation.
Look at the warnings about checkboxes , there were a lot more , but once i saved the file generated by Myapp, all these checkboxes warnings desappeared , but these two not, i can't find them.
Another thing , when the exception comes up the debugger jumps to a asembler code :
5F430BE2 call dword ptr [eax+98h]
5F430BE8 test eax,eax
5F430BEA je 5F430BF3
5F430BEC mov eax,1
5F430BF1 jmp 5F430C01
5F430BF3 mov ecx,dword ptr [ebp-4]
5F430BF6 cmp ecx,dword ptr [ebp+8]
5F430BF9 jne 5F430BFD
5F430BFB jmp 5F430BFF
5F430BFD jmp 5F430BB1
5F430BFF xor eax,eax
.
.
|
|
|
|
|
The ecxeption is a first chance exception :First-chance exception in MyApp.exe (MFC42D.DLL): 0xC0000005: Access Violation.
The app runs without any exception, but after the PostMessage is sent to the parent dialog , the child dialog do some things wrong , dones't work fine, but there isn't any errors messages.
|
|
|
|
|
You have some conflicting statements here, you cannot say the app works without exception when an exception has occurred.
You also say "the child dialog do some things wrong". So, find out why it is doing those things and fix the program. You need to spend time with your debugger finding out why the exception occurs, and why the other errors happen. From the information you have provided it is impossible to guess what your code is doing.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
I would bet your routine is overwriting part of the stack. When it reaches the return statement, the return address has been clobbered, and BOOM.
|
|
|
|
|
I has Visual Studio 2008 on my Windowx XP machine and this entire Windows installation was later converted into VHD instance to run inside Virtual PC on Windows 7.64. Everytihng was working fine until recently. I am not sure what I changed, maybe nothing at all, but now I am unable to debug most of compiled projects inside this virtual Windows. Visual Studio reports that debugged application is unable to initialize properly or throwing some weird exceptions, sometimes applications starts but then its unable to call some standard Windows APIs like returns 0 from InternetOpen function. Compiler and linker by itself seems to work properly, if I run compiled applications from same virtual machine, they work fine, only problem I see is when I try to debug something using IDE inside Virtual PC. I tried to roll back VHD file to the state when everything was working but it does not help, so I guess its a virtualization problem. Any thoughts how could I fix this?
Update: Never mind, it seems to have nothing to do with virtualization, its a bug in latest Avira Antivir and is described here:
http://www.avira.com/de/support-for-free-faq-detail/faqid/805[^]
and here in English:
https://forum.avira.com/wbb/index.php?page=Thread&postID=1031803[^]
|
|
|
|
|
Currently, I have a Windows EXE application, with several loaded DLLs. DLLs need to communicate with my windows application through PostMessage and SendMessage.
The Windows EXE application + DLLs are all within a single process.
The message should be private among EXE and DLLs.
I was wondering, should I use
+ WM_USER based message
+ WM_APP based message
or RegisterWindowMessage
and why?
What happen if there is an external process (another exe), trying to FindWindow of my Windows application, and send the message with same ID? I wish not to respond, as I am only interested message from DLLs within my own process.
|
|
|
|
|
You may go with WM_USER WM_APP (see discussion below) based message.
Since such messages are 'private', only your application and the DLLs know the protocol: (AFAIK) you may just enforce such a protection mechanism.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
modified on Friday, December 10, 2010 6:16 AM
|
|
|
|
|
Oops! That ain't correct.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Nope. That is correct you can't get any better using RegisterWindowMessage for private (i.e. inside same process) messages.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
The messages are not within the same executable, and therefore I don't consider it as 'private'.
The OP is talking about an executable and a DLL, and is particularly concerned that someone else should not be sending the same message. RegisterWindowMessage() will provide a secure way to accomplish this as the ID is generated at runtime, and the 'other executable' won't know it.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Rajesh R Subramanian wrote: The messages are not within the same executable, and therefore I don't consider it as 'private'.
The DLL is mapped in the executable address space, isn't it?
Rajesh R Subramanian wrote: The OP is talking about an executable and a DLL, and is particularly concerned that someone else should not be sending the same message. RegisterWindowMessage() will provide a secure way to accomplish this as the ID is generated at runtime, and the 'other executable' won't know it.
Using Spy++ (or another hook mechanism) you may know about.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: The DLL is mapped in the executable address space, isn't it?
So, are you telling that using a hardwired message ID is better than having the OS register a dynamic ID for us? Also, the DLL could be mapped into my address space, but it's still a different entity. If I keep on assigning WM_USER + based messages for all my handlers, that would certainly be
1. Poor programming technique
2. Could be error prone, as I might accidentally type in something else (and there are a few more points that the article discusses)
3. Some messages based at WM_USER + have been obsolete, which means that I could possibly collide into what's a standard windows message.
4. And the worst thing is that SOMEONE ELSE can come up with the same message ID and send it to you. (with dynamic creation, it's different, AND unique each time).
CPallini wrote: Using Spy++ (or another hook mechanism) you may know about.
Like I said, if you would want to hack, there's no limits to it.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Rajesh R Subramanian wrote: 1. Poor programming technique
Nope. Unless Microsoft itself is encouraging poor programming techniques.
Rajesh R Subramanian wrote: 2. Could be error prone, as I might accidentally type in something else (and there are a few more points that the article discusses)
Typing MY_OWN_MESSAGE (typical #define used in WM_APP + messages) is as error prone as typing, for instance WM_PAINT.
Rajesh R Subramanian wrote: 3. Some messages based at WM_USER + have been obsolete, which means that I could possibly collide into what's a standard windows message.
I already acknowledged this very point.
Rajesh R Subramanian wrote: 4. And the worst thing is that SOMEONE ELSE can come up with the same message ID and send it to you. (with dynamic creation, it's different, AND unique each time).
That's true, as correctly pointed out by Dr.Newcomer, only if you're distributing your DLLs and them are being used by clients that uses, at the same time, other 'sending messages DLLs' (I find rather hard to fit this in the OP scenario).
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: Typing MY_OWN_MESSAGE (typical #define used in WM_APP + messages) is as error prone as typing, for instance WM_PAINT.
No, it was a different point I was trying to make. Say if you're copy pasting a bunch of messages, you could accidentally define two different messages with the same ID while editing those.
And coming to the... Wait, I think this is stretching far too much for very little. Now we need to decide who of us gets the 'nitpick of the week' award.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
|
The correct way is to use RegisterWindowMessage(). That would ensure the uniqueness of messages. Read the details here: http://www.flounder.com/messages.htm
yccheok wrote: What happen if there is an external process (another exe), trying to FindWindow of my Windows application, and send the message with same ID? I wish not to respond, as I am only interested message from DLLs within my own process.
If you use RegisterWindowMessage(), then the 'other executable' won't know what would be the ID of this unique message.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
That would ensure uniqueness, for well behaving app, not for Spy++ & go hacks... 
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Oh well, if you decide to hack, you could do it anyway. But the idea is to keep it as sane as possible. Also, WM_USER + based messages are obsolete (read it in the essay I linked to).
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Rajesh R Subramanian wrote: But the idea is to keep it as sane as possible. Also, WM_USER + based messages are obsolete (read it in the essay I linked to).
The point about WM_USER is right (I've fixed the OP), anyway, there's nothing wrong using WM_APP in the OP scenario (Dr.Newcomer warns about 'clients using DLLs with conflicting messages...') and the mechanism is the same of the WM_USER one.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: there's nothing wrong using WM_APP in the OP scenario
Well, yes and no. I'm not saying it's WRONG, but there's a better way. Dr. Newcomer, I and Ray Ozzie discussed this over a coffee. Just Kidding. 
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Rajesh R Subramanian wrote: Oh well, if you decide to hack
Oh, no. Unfortunately I'm really poor as hacker... 
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
[Jeremy Clarkson Voice] Some say that it's impossible for the stig Carlo to hack his way out of wet socks. [/Jeremy Clarkson Voice]
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
