|
Toni78 wrote:
I don't know if you're following me?
Yes I am, but no, that can't happen. The only way for the OnUser1() function to be called in through the window procedure, which is of course stopped while the program is stopped.
The most likely explanation for the situation is that the MessageBox() function empties the message queue before it displays.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
The most likely explanation for the situation is that the MessageBox() function empties the message queue before it displays.
Why would it do that? I cannot think of a reason.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Toni78 wrote:
Why would it do that?
So that if there was an enter key sitting in the queue, the message box would not be immediately closed with the default response. The purpose of a message box is for people to read it, not accidentally miss it.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
So that if there was an enter key sitting in the queue, the message box would not be immediately closed with the default response.
Wouldn't the main window handle (or any other window that is supposed to receive the enter key) handle that message? MessageBox should have it's own dialog procedure, right? I am getting confused now.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Toni78 wrote:
Wouldn't the main window handle (or any other window that is supposed to receive the enter key) handle that message? MessageBox should have it's own dialog procedure, right?
Yes you're right, but there is a short period of time in between a window being created and it being displayed. Only a few milliseconds, but enough to warrant emptying the queue first. If the enter key is pressed right in this time (or the key posted to the queue), then the dialog box would disappear before it was shown. Remember that WM_PAINT is the lowest-priority message in the system. All other messages are processed before it.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
You are right. Even though I find it hard that MessageBox empties the queue, I rest my case. My knowledge has reached its limits. I wish I had softice to check out what MessageBox does, but that program is way to expensive.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Toni78 wrote:
I rest my case. My knowledge has reached its limits.
Don't be so upset  . I'm just guessing that it empties the message queue. I can understand logically why it would, but it's not documented that it does. There may be another reason why his app has that behaviour. I don't know what it would be though.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
While it takes a little abstract thought, this isn't all that wierd when you think about the guts of
the DialogBox function.
In your OnClick1 function, you post a message in to the threads message queue.
You then call the MessageBox function.
This then calls the ::DialogBox function after having set up the parameters for you.
The ::DialogBox function displays a Modal dialog. It can also work from console apps.
So it has to have its own message pump.
After having created the MessageBox window (which is all a dlg is), it gets these messages:
MSG(hWnd1, WM_USER1, 0, 0)
MSG(hDlg, WM_NCCREATE, ...)
MSG(hDlg, WM_CREATE, ...)
MSG(hDlg, WM_PAINT, ...)
etc.
It dispatches (DispatchMessage) with them in the order it gets them.
"Aha!" you say, it should filter out the messages not for the dialog. But it can't. For multiple
reasons, some of which mentioned in other responses.
e.g. If you move the dialog about, the window "behind" it needs to get WM_ERASEBKGND, WM_PAINT, WM_NC*
etc.
You may have background activity needing WM_TIMER messages etc.
The point being windows can't *know* not to pass on all but a few messages, so it does.
This is why your beep happens before you see the dialog. If you *really* want it after, post the message
after.
This has been a little wordy, but behind MFC and its On...s, there is SDK code, with messages, pumps,
the whole shebang.
Iain.
|
|
|
|
|
 Argh! Of course. I should have remembered that! Thanks for the explanation 
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Not a problem.
One of my pet peeves is that all these fancy new libraries (MCF, .NET) make it easier to
get started, but can abstract you so far from the underlying OS that is easy to forget
what is *actually* going on.
I'm from the old school a little bit. I like to be able to use the bottom layer before
I then "forget" it and move on to the fluffy easy-making higher layers.
Eeeeh, when I were a lad, we only had 3 8 bit registers, push, pop and we liked it!
Iain.
|
|
|
|
|
Iain Clarke wrote:
Eeeeh, when I were a lad, we only had 3 8 bit registers, push, pop and we liked it!
I still do - I do a lot of embedded programming and love it!! 
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
so does it mean that every control that runs under console app should have atleast a message pump if not the queue.
|
|
|
|
|
I don't know what you mean by "console control", but I presume you mean
an console application.
A message pump is just a fancy name for a loop like the following
while (GetMessage (...)) // Possible using PeekMessage to be more complex
{
if (ShouldWeQuitThisLoop (...))
break;
ProcessTheMessage (...);
DispatchMessage (&msg);
}
This loop (or something very similar) is at the heart of window apps
WinMain ( its in CWinApp::Run () as I remember), DialogBox function,
etc.
So its written for you by microsoft if you just call (e.g) MessageBox.
As I remember, these functions are in USER.DLL. Also there is the message
queue. So using a function that would need a message loop also links in
the queue. Neat, eh?
Essentially, you can all but forget about this, but keep it way back in
your mind for wierd behaviour explanations.
Iain.
|
|
|
|
|
Even though I didn't post the question, thank you for that answer. It all makes sense now.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
I am using crystal report 8.05 to desigen the report.
Report is connected to user DSN . Database used is MYSQL 3.51.
The report is displyed by application developed in VC++.
When I open the report I get the error ' can not open SQL server'. Solution to this problem is to download P2sodbc8.zip file and load P2sodbc8.dll .
I tried it out but still getting the same problem
|
|
|
|
|
Hi !
I want to write a macro which will be used each time an error is found in my source code. This macro will display a text and I want it to display the line in the source code where it is called.
Is it possible to do that ? Is there a way to get the actual line of the source code ?
Thank you for your help,
Jerome
|
|
|
|
|
The __LINE__ is defined as the current line of the source file. It is treated exactly as a string literal, so you can do what you like with it  except modify it, of course
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
At one place
long m_lReturnID;
m_lReturnID=MessageBoxEx(m_hptr,//The HWND handle to the parent dialog
"Hello, are you ok?",
"Ok?",
MB_YESNO|MB_ICONQUESTION|MB_TOPMOST,
LANG_ENGLISH);
______________________________________
At another place
I want to shut up the dialog if the dialog is still on
How to solve this?
Please help me!
Thank you in advance!
|
|
|
|
|
You can't using MessageBoxEx(). You'd have to write your own dialog class, and send it some sort of message from another thread.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Actually, you could simulate a mouse click on the message box to click one of the buttons...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I want to do like this
But I don't know how to simulate a click on the button.
Can you tell me how to finish this function?
|
|
|
|
|
There are two ways:
1. Get the location of one of the buttons (use GetWindowRect()) and send a WM_LBUTTONDOWN message.
2. Send a WM_COMMAND/BN_CLICKED message to the dialog, with the IDOK identifier.
I would probably do the second one. Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I do like below:
PostMessage(WM_COMMAND,IDYES);
SendMessage(WM_COMMAND,IDYES);
But neither of them can shut up the dialog.
what's wrong with me?
|
|
|
|
|
Are you sending it to the correct window?
You have to do:
PostMessage(WM_COMMAND, MAKEWPARAM(BN_CLICKED, IDYES), (LPARAM)hwndYesButton); after getting the window handle to the yes button.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Oh
I call the function after I click a button on my main dialog.
Can that work?
In addition
"hwndYesButton" is an undeclared identifier in my project.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
