|
Dude, what are you doing
CToolBar and CDialog are totally different beasts. To handle the enter key in a dialog, override the CDialog::OnOk() function.
CPUA 0x5041
Sonork 100.11743 Chicken Little
"So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies
Within you lies the power for good - Use it!
|
|
|
|
|
Ah! Well, like you gys said...this stuff is new. The way I pick up things is by seeing samples> I saw the toolbar combobox and thought - oh! Thats how you trap the enter key press! And there was no information telling me that thats NOT the way for a CDialog (none that I have access to....). So now I know.....you treat the two Enter differently. SOrry if I 'm a pain, but your responses truly get me to learn. As for the HIWORD, LOWORD....yes I did understand that post> What I didnt do ( ) was implement your information right away, so hence my duplicate sounding thread.
How did you learn about treating the two different Enters differently? Just curious, but if WM_COMMAND is such a universal sort of message why cant we do that in the CDialog as well? I hope I dont annoy you with this question...I'm trying to generalize as much info as I can because I keep forgetting the individual details....
Appreciate your help,
ns
|
|
|
|
|
At the risk of confusing you more....
ns wrote:
Just curious, but if WM_COMMAND is such a universal sort of message why cant we do that in the CDialog as well
If you create a dialog with no buttons, or any controls that handle the enter key themselves (in other words, a dialog with only simple static controls), then you can handle the enter key this way. But it is not advicable, because CDialog will, by default, call your OnOk() handler.
It's not a matter of it will never work, it's just that it will only work in very special circumstances.
CPUA 0x5041
Sonork 100.11743 Chicken Little
"So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies
Within you lies the power for good - Use it!
|
|
|
|
|
So I'll stumble upon these special circumstances as I grow in my coding experience......
Appreciate your help,
ns
|
|
|
|
|
I am importing OIP22.TLB in one of my header file. I am trying to connect to a oracle database which is on unix box through by VC++ application.
The following is the code I am using:
BSTR bstrDb = m_strOraDb.AllocSysString ();
BSTR bstrUser = m_strOraUser.AllocSysString ();
m_pOraDatabase = m_pOraSession->GetOpenDatabase( bstrDb, bstrUser, ORADB_DEFAULT);
m_strOradDb , m_strOraUser are Const CString
Values in m_strOraDb and m_strOraDb are : "omst", "oms/oms" (Our database name, userid/password, ORADB_DEFAULT = 0)
From above it goes into this routine of OIP22.TLI file:
#pragma implementation_key(36)
inline IDispatch * OraSession::GetOpenDatabase ( BSTR dbname, BSTR connect, long options ) {
IDispatch * _result;
_com_dispatch_method(this, 0x60010002, DISPATCH_PROPERTYGET, VT_DISPATCH, (void*)&_result,
L"\x0008\x0008\x0003", dbname, connect, options);
return _result;
}
It fails just before return_result saying:
First-chance exception in MYAPP.EXE (KERNEL32.DLL): 0xE06D7363
ravi
|
|
|
|
|
From MSDN:
wParam
The high-order word specifies the notification code if the message is from a control. If the message is from an accelerator, this value is 1. If the message is from a menu, this value is zero.
The low-order word specifies the identifier of the menu item, control, or accelerator.
In a sample code I see:
BOOL CToolBarWithCombo::OnCommand(WPARAM wParam, LPARAM lParam)
{
if( wParam == IDOK && lParam == 0 )
Here wParam is just one thing (is IDOK an example of what they call the notification code ?) . I dont see them doing a hiword(wPAram) and loword(wPAram). I'm a bit lost...
Appreciate your help,
ns
|
|
|
|
|
He's taking a shortcut. The only way wParam can be equal to IDOK (1) is if the loword is 1 and the hiword is 0. (looks like he is handling the user pressing the enter key)
CPUA 0x5041
Sonork 100.11743 Chicken Little
"So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies
Within you lies the power for good - Use it!
|
|
|
|
|
THe toolbar has a combobox, and this code is when the user enters text in the edit part of the combobox. The combo has an ID_COMBO1. SO according to MSDN I thought it would be:
LOWORD (wParam) = ID_COMBO1
HIWORD (wParam) = notification code for pressing Enter.
I looked up IDOK and it seems to be the ID of the OK button on a CDialog. So I can even convince myself that LOWORD(wParam) = IDOK because its like pressing an OK button when you hit enter. The notification code for pressing a button is BN_CLICKED = 0. SO your answer makes sense.
====================================
Heres my next followup question
In that case say I had a textbox, a richtextbox and a combobox on my toolbar. Then I enter text in any one of them. According to what I have gathered from you, what I should be looking for is the WM_COMMAND handler is IDOK and BN_CLICKED. SO nothing is telling me what the control was which had text entered in it.....
===========================================
From the combotoolbar sample, they do:
if( rgComboBox[index]->GetEditSel() != 0 )
{
AfxMessageBox("aaa");
} .
I read about GetEDitSEl in mSDN and its associated with highlighted (selected ) text. Yet if I simply enter text in the combobox and hit enter, the text vanishes (it shows up in the dropdown), and the code enters the if block and I get the AfxMessageBox. I have not selected anything !!!!! Yet GetEditSel returns nonzero value!
If I can understand this, then maybe i can use something similar to see if the CEdit had stuff using GEtSEl. Though why that should work is as mysterious as why GetEDitSEl works. The mystery being that I did not select anything...just entered text and hit return!!!!!!
Appreciate your help,
ns
|
|
|
|
|
Ok, I downloaded the code you are refering to. I looked at it, and the code you are refering to is a real hack, it does not always work. Just for the heck of it, enter some text in the comboboxes edit control, now hit the <Home> key on your keyboard to move the caret to the start of the text you just entered. Now hit <Enter>.
Notice that nothing happens? GetEditSel() is returning 0 so the test fails. You are better off using GetFocus() and use that pointer.
CPUA 0x5041
Sonork 100.11743 Chicken Little
"So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies
Within you lies the power for good - Use it!
|
|
|
|
|
I did:
CWnd * pWnd = GetFocus();
and it compiled okay. How does a pointer tell me about what control its a pointer of? I've got a CEdit as well as a CComboBox. I tried this:
if (p == TypeOf(CComboBox))
{
AfxMessageBox("kkk");
}
as a guess but there is nothing called TYpeOf.....how do I recognize my pointer?
Appreciate your help,
ns
|
|
|
|
|
Your toolbar has member variables for the controls, right?
Just compare the returned CWnd* to your member variable.
CWnd *pWnd = GetFocus();
if (pWnd == MyToolBarPointer->m_TheEditControl)
{
}
CPUA 0x5041
Sonork 100.11743 Chicken Little
"So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies
Within you lies the power for good - Use it!
|
|
|
|
|
it should read:
if (*pWnd == ...
The pointer has to be dereferenced.
CPUA 0x5041
Sonork 100.11743 Chicken Little
"So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies
Within you lies the power for good - Use it!
|
|
|
|
|
Gosh! I am so sorry I didnt see the obvious. I got so carried away with your new information that I started looking for even newer ways of doing stuff and forgetting the old stuff...
MAny thanks!
Appreciate your help,
ns
|
|
|
|
|
Geese!
I've created a dockable toolbar in VS C++ 6.0 using MFC's CToolBar like this:
if (!m_wndCalToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP |
CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY |
CBRS_SIZE_DYNAMIC) ||
!m_wndCalToolBar.LoadToolBar(IDR_CALTOOLBAR))
{
TRACE0("Failed to create toolbar\n");
return FALSE; // fail to create
}
// TODO: Delete these three lines if you don't want the toolbar to
// be dockable
m_wndCalToolBar.SetWindowText (_T ("Pulser Firing"));
m_wndCalToolBar.EnableDocking(CBRS_ALIGN_ANY);
DockControlBar(&m_wndCalToolBar);
Problem is, the buttons all come up greyed out, or "unavailable" as I have read. How in the the heck do you make them "available" ?????
I can't find it anywhere in the documentation, and I don't see it here. Please help!
Thank you
Dan Willis
|
|
|
|
|
the buttons in the toolbar need to have IDs, those ID need to be hooked to a callback via the MESSAGE_MAP macro.
In simpler terms, the buttons in the toolbars will behave the same way as menu items do.
If you don't assign a command to them, they will stay grey.
Max..
|
|
|
|
|
Ah! The light turns on.
I haven't done that yet. I knew i still had to handle the command ID's but I didn't realize that there was some code in the background that checked the message map and then grayed accordingly. Oh yeah! Makes alot of sense now. I just didn't know it!
Thank you. Wahoo! Solved this one! Thanks!
Dan Willis
|
|
|
|
|
One of the sceens in the wizard while creating a new MFC appwizard project asks if I want to include automation support. If I check this what do I get? What do I lose?
Appreciate your help,
ns
|
|
|
|
|
it will add a couple of lines to initialize COM, no big deal.
-c
Zzzzz...
|
|
|
|
|
Thanks! SO it can be added as an afterthought if necssary. I guess one would create a project with, and one without and windiff the files to see what the wizard added, if I want to enable the stuff later. Though thats not always the case.....sometimes it seems that the wizard puts in stuff other than code in sone files and those cant be touched.......
Thanks again.
ns
|
|
|
|
|
I was hoping if by any means is it possible for any one on the site to tell me where to get the Vc++ code for buttons that can jump around on screen when entered!!
shoaib.
|
|
|
|
|
You mean like this[^]?
CPUA 0x5041
Sonork 100.11743 Chicken Little
"So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies
Within you lies the power for good - Use it!
|
|
|
|
|
I am a little confused about the DrawItem member function. I have tried to create a button class derived from CButton that displays a bitmap but basically acts like a checkbox control with the pushbutton style. i.e when the button is raised, pushing on the button will cause the button to remain depressed until the next button push.
Since, I couldn't find a class for checkbox yet alone one that would support a bitmap, I decided to create my own class from CButton and set the BS_CHECKBOX style.
Here's the problem which I'm sure is just my lack of understanding. I got the class working except in order to remain depressed I kept track of my own state from the button's OnClick event and combined with the state passed in DrawItem, I drew the button correctly and everything works great...until I put the button in a toolbar. When in a toolbar the button receives the OnClick event but it doesn't pass or reflect the message back to the toolbar and eventually the framewindow.
I'm thinking maybe I shouldn't have used the OnClick event for the button but rather used DrawItem alone but am not sure. I mean, since DrawItem state can be ODS_SELECTED can't I just keep track of whether the button should remain depressed or not in a variable, toggle the state, and draw the button each time ODS_SELECTED is the active state? Not sure if that works the way I think it might.
Or, is there some way to use OnChildNotify or some other event to make sure I handle the OnClick event and pass it to my parent (toolbar or framewindow eventually)??? Maybe I should have derived from CBitmapButton and just added this state info.
Thanks
|
|
|
|
|
JohnnyG wrote:
When in a toolbar the button receives the onclick event but it doesn't pass or reflect the message back to the toolbar and eventually the framewindow.
Actually, it's exactly the opposite. The OnClicked (BN_CLICKED ) notification message is sent to the parent window, or better to the window specified as parent during control creation (the parent window can be changed later).
MFC reflects notification messages (either in the form of WM_NOTIFY or WM_COMMAND ) back to the child control. The message can or can not be processed by the parent then, in dependence to what message macro you use: ON_xxx_REFLECT or ON_xxx_REFLECT_EX (where xxx can be NOTIFY or CONTROL).
If you use the EX extension the message handler function return value is not void, but a BOOL that specifies if the parent can handle the message as well (TRUE) or not (FALSE). Without EX, the parent is called only if the child does not have an handler for the message.
For details see TN062 (Technical Note 62: Message Reflection for Windows Controls) on MSDN.
Paolo
------
"airplane is cool, but space shuttle is even better" (J. Kaczorowski)
|
|
|
|
|
Paolo,
Thanks, for the reply but I'm still confused. I did read TN062 yesterday and here's part of what it says:
If, in your parent window class, you supply a handler for a specific WM_NOTIFY message or a range of WM_NOTIFY messages, your handler will be called only if the child control sending those messages does not have a reflected message handler through ON_NOTIFY_REFLECT(). If you use ON_NOTIFY_REFLECT_EX() in your message map, your message handler may or may not allow the parent window to handle the message. If the handler returns TRUE, the message will be handled by the parent as well, while a call that returns FALSE does not allow the parent to handle it. Note that the reflected message is handled before the notification message.
So, If in my derived button class, I have ON_NOTIFY_REFLECT_EX(BN_CLICKED, OnClicked)and in my OnClicked member function I return TRUE. What do I need in the framewindow class or even the toolbar class? I mean do I need WM_NOTIFY message handler in one or both of these class files? Currently, I have nothing there but in my application class I have: ON_COMMAND(ID_VIEW_FREEZE, OnViewFreeze) because the button, toolbar button, and menu ID is the same. This worked fine when I was using just a plain CBitmapButton.
|
|
|
|
|
JohnnyG wrote:
So, If in my derived button class, I have ON_NOTIFY_REFLECT_EX(BN_CLICKED, onclicked)and in my onclicked member function I return TRUE.
That's correct, but the BN_CLICKED notification is sent as a WM_COMMAND message and so the right macro should be ON_CONTROL_REFLECT_EX.
For the parent window nothing changes, you handle the notification as usual. The different message macro is used by MFC when looking up the message map, so it knows it has to call both handlers.
Paolo
------
Why spend 2 minutes doing it by hand when you can spend all night plus most of the following day writing a system to do it for you? (Chris Maunder)
|
|
|
|