|
 I'm working on a project which is Single Document-MFC.
I'm learning database(ODBC) programing vith visual C++ 6.0.
I want to enter a numeric value into an EditBox.
Then this value should be stored in *.mdb table as Long Integer.
I chose catagory as value and variable type as long for EditBox from class wizard.
But I could not write any code for it.
please,help me !
emroz
|
|
|
|
|
Emre Zorlu wrote:
But I could not write any code for it.
What do you mean by it? This is the second time you're asking this question. Don't you think you should provide more details?
// 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
|
|
|
|
|
At a very high level:
1) Get the text from the edit box
2) Validate it
3) Create a DAO object and connect to your database
4) Call the Recordset's AddNew or Update to insert the data
Which of these actions do you need more help with?
I'm going to live forever or die trying!
|
|
|
|
|
when i create a Cwebbrowser contorl in my dll,it occur seriou error.
i seem that the dll doesn't support activeX control.
how can i realize webbrowser in my dll.
gucy
|
|
|
|
|
by the way ,i had added AfxEnableControlContainer() in my dll app.
if i add activeX control using resource edit,the dialog will not show at all.
if i dynamically create the control in the program. create failed.
gucy
|
|
|
|
|
I am using a VC SDK which has a menubar and some drop down menus in it. I want to add tool bar to it and beautify my application.After adding tool bar I want to call all the functionality of the menubar.
any help?
Madhu
|
|
|
|
|
Check the following abstract code snippet.
CMyclass::OnClick1() //called when button1 is clicked
{
Postmessage(WM_USER1);
.
.
. //2
MessageBox("Everything not roght here.");
}
CMyclass::OnUser1() //called when WM_USER1 message is posted
{
Beep(200,300);
.
.
.
.
}
Now what happens is whenever CMyclass::OnClick1() gets called it executes the code till comment two (//2) it doesn't displays the MessageBox(), then it jumps to CMyclass::OnUser1() handler executes it completely, then again comes back to CMyclass::OnClick1() & starts where it left, i.e it displays the MessageBox() & everything goes as expected.
Now the question is why it jumped from CMyclass::OnClick1() to CMyclass::OnUser1() before displaying the MessageBox(), then again comes back & does the rest?
|
|
|
|
|
Simply because you're just putting a message in the message queue of the window. PostMessage returns immediately without wating the message to be processed. So the message is processed when the window extract it from the queue (so when the thread has nothing more to do).
If you want the action to be executed immediately, you must use SendMessage instead (this is the same instead SendMessage wait until the message is processed).
Hope yhis helps!
|
|
|
|
|
I think he was saying that the opposite is happening when it shouldn't be 
You are correct, and I'm pretty sure he knows it too.
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"
|
|
|
|
|
Ooops, yes sorry !
In fact I read it too fast and I just explained the first sentence. Hum, it's a little bit ambigous  !
|
|
|
|
|
I'm not sure why this would happen, but put the PostMessage() after the MessageBox() and it will work as you want.
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"
|
|
|
|
|
Ryan Binns wrote:
I'm not sure why this would happen
Do you think that the debugger is not working correctly in this case? For instance, since the call to PostMessage has returned it continues to step on the other lines after this function but when OnUser1() gets called it starts to step there. Maybe if a breakpoint is set on OnUser1() and then have the function return just to see where the debugger will resume execution. I don't know if you're following me?
// 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 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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
