|
My question is, if it is possible to catch messages inside the DLL.
Sure it is. Windows messages are of one of these two types:- Messages sent to a window (see
SendMessage ),
- messages sent to a thread (see
PostThreadMessage ) Both types of messages are handled similarly by a so called message loop, executed within the thread that created the destination window (case 1) or the destination thread (case 2). The only difference when it comes to the message loop is that the hwnd parameter of the MSG structure received is 0 for messages of the second type.
All of this implies two things:- A responsive window must be created in the context of a thread that performs a message loop: deep deep inside the MFC code there's such a loop that causes your MFC windows to become alive. Without MFC, it's up to you to write the thing.
- If you're trying to catch a message intended for a window that has not been created by the current thread, then you're out of luck.
I'm not going to give you full details here on how to write a message loop thread, but its main code goes more or less like this:
MSG msg;
while(GetMessage(&msg,NULL,0,0)!=0){
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return;
The message loop keeps looping till GetMessage returns zero, which happens upon reception of a WM_QUIT message intended to the thread (see PostQuitMessage for more details).
So, to be able to catch Windows messages inside your non-MFC DLL you will have to set up a message loop thread (possibly with some dependent window) and write also the code to terminate that thread with PostMessage . Lots of fun ahead! Good luck!
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Great!!!
Thanks a lot!
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
For some reason, when I try to open a file in my application, I get an error and my application terminates. It's confusing because I haven't touched any of the code that is used to start the open file dialog and open the file. What's happening is it seems to be passing garbage data to the open file dialog that is longer than the maximum allowable length of data and it is crashing on an assertion. Has anyone encountered this problem or know what I'm talking about and have any idea on how to fix it?
|
|
|
|
|
Post the code where the problem is occuring. I can't think of any known problems but maybe we'll be able to spot something in the code.
Michael
|
|
|
|
|
Here is where the breakdown starts:
void CDocManager::OnFileOpen()
{
// prompt the user (with all document templates)
CString newName;
if (!DoPromptFileName(newName, AFX_IDS_OPENFILE,
OFN_HIDEREADONLY | OFN_FILEMUSTEXIST, TRUE, NULL))
return; // open cancelled
AfxGetApp()->OpenDocumentFile(newName);
// if returns NULL, the user has already been alerted
}
What's happening is the newName variable is getting a piece of data in it that is in one of my dropdown boxes. It's confusing because it has the data in it immediately after the variable declaration statement is executed. So, right after "CString newName;", the newName variable has some data in it and that seems to be the cause of the problem. I'm not sure how the data is getting there or why it is there right after the variable is declared, but... Any thoughts?
|
|
|
|
|
I have had this happen before, and it was usually a header file mismatch, which lead to a binary mismatch, or a debugging info mismatch.
The header files used to build the app do not match the LIBs and/or DLLs used to link and run the app. If your project builds/uses a few different custom DLLs, then there may be a mismatch between the ones that you have, and the ones that your app is expecting to import from at runtime.
A mismatch in your debugging information would cause your editor's "current instruction" pointer to point to code that you are not actually in.
Peace!
-=- James.
|
|
|
|
|
Hi,
I have got a problem with a popup menu that I have created in a CDialogBar.
The menu item is grayed out when the menu is displayed.
I use the same approach for some buttons, but there the menu item is enabled.
Am I doing something wrong, or is there a way to enable the menu item?
Cheers,
/Fredrik
Do you Sonork? I do! 100.11430:PhatBoy
|
|
|
|
|
That could probably be because the menu-item handlers dont exist in the context. Like perhaps you have put them in a view, which is not valid when you show the popup menu, as the focus is on the control bar. Try putting the handlers in the frame window class
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
It works if I put the handler in the frame window class, although I do not quite understand why.
What I am trying to do, is to encapsulate the menu item handler in my derived toolbar class. I handle the WM_RBUTTONDOWN message in the toolbar class to display the menu.
How do I do everything from the toolbar class?
Cheers,
/Fredrik
Do you Sonork? I do! 100.11430:PhatBoy
|
|
|
|
|
Fredrik Skoog wrote:
It works if I put the handler in the frame window class, although I do not quite understand why
Because, by default, if you do not setup an ON_COMMAND* handler for a command, it will be disabled. You also might want to look into how command routing works, so as to understand the order that is used when searching for a Command Handler.
Peace!
-=- James.
|
|
|
|
|
Why the functions GetWindowsDirectory(), GetSystemDirectory() and GetTempPath() failed on Windows XP? The returned folders are 'c:\abc', 'c:\abc\system\123' and 'c:\abc\temppath\123'
|
|
|
|
|
Gosh!!
That is sure funny!
I am sorry, I can't help you there as I havent used XP yet.
But couldnt resist posting this one as I am laughing so hard my stomach muscles hurt
Nish
p.s. do those directories exist? or are they just fantastically made u?
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Of course they don't exist...
|
|
|
|
|
Then there is something wrong with your code or perhaps some virus has totally messed up your machine
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Looks like the children-version of XP
For kids just learning the aplhabet and counting until 20
modified 12-Sep-18 21:01pm.
|
|
|
|
|
|
I tried this eagerly anticipating the results, but was disapointed to find my Windows XP installation does not share yours sense of humor:
E:\WINDOWS
E:\WINDOWS\System32
E:\DOCUME~1\Joshua\LOCALS~1\Temp\
Post the code you used, or the smallest possible snippit that illustrates the effect you're getting, pls.
farewell goodnight last one out turn out the lightsSmashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
The code is listed below. I think there are no tricks to use these functions. If you wish I may send you a jpg screen shot of Microsoft Visual C++ 6.0 (Service Pack 5) in a debug session showing the value of variable 'szdir' after call GetSystemDirectory()...
I am sure I am not crazy...
I am using "Microsoft Windows XP Professional( Build 2600 )", with AVG 6.0 Anti-Virus System resident (Virus Database 174, Release Date 2/1/2002)
CString sWindowsFolder,
sSystemFolder,
sTempFolder;
char szDir[ MAX_PATH ];
GetSystemDirectory( szDir, sizeof( szDir ) );
sSystemFolder = szDir;
GetWindowsDirectory( szDir, sizeof( szDir ) );
sWindowsFolder = szDir;
GetTempPath( sizeof( szDir ), szDir );
sTempFolder = szDir;
|
|
|
|
|
What are the return values for the functions? Do they return the correct length, or do they return 0.
Michael
|
|
|
|
|
The return value when "szdir = c:\abc\SYSTEMDIR\123" is 20, the correct length. The function didn't fail...
|
|
|
|
|
I found the real cause of the problem...
I am executing the 'Application Verifier 2.3' included in "Microsoft Windows XP Application Compatibility Toolkit 2.0" distributed by Microsoft at "http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/685/msdncompositedoc.xml".
The 'Application Verifier' is configured to verify my app.
When I removed my app from 'Application Verifier' the problem disappeared...
If anyone wish to check this 'dead-brain' situation...
Thanks for all funny replies.
|
|
|
|
|
Please tell me how to transfer files from a nds through the internet via the ldap protocol. I am able to get the attributes from an objekt but i can't transfer entries from a filesystem (for example .exe or .doc files). Please help me!
|
|
|
|
|
In Unix we normally have the possibility of analysing the memory dump file (Coredump) when our program bugs out, and we often find the errors this way by using the GBD
I have noticed that in XP (as opposite to Win2k) this file is dump is very often caught and you can choose to send this to Microsoft or look at it..
My question is.. Do you know of any tools that can help us analyse this file..I do not think the VC.Compiler has any "import" options for this like the GDB..
Thanks in anvance for any comments...
Wbr
Lars
Lars Pehrsson
|
|
|
|
|
Check out WINTELLECT NEWS November 2001 by John Robbins.
http://wintellect.com/resources/newsletters/nov2001.asp
And two MSJ BugSlayer Articles:
http://wintellect.com/resources/redirect.asp?url=http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1299/Bugslayer/Bugslayer1299.htm
http://wintellect.com/resources/redirect.asp?url=http://www.microsoft.com/msj/0100/bugslayer/bugslayer0100.asp
|
|
|
|
|
Hello all,
After almost completion of my MDI appl, I figure out that the hot-key CTRL-F6 (switching between windows) is not working anymore (might never have worked ). I haven't change anything in the accelerator resources (it's actually still there). In a default MDI-project of VC++6.0 it does work.
It might have something to do with having a tab-control bar I've included (as part of MainFrm). The doc/view are also splitted, but that should be at another level.
Have any of you any idea's how I can pin-point where it's going wrong? By the way: what messages are sent?
Thanks in advance,
EiSl
|
|
|
|