Printable View
I want to have a help message come when the user Right Clicks a CButton Control. The message would be different for every implementation of the control, so I can't just subclass the control and override OnRightButtonDown member function.
I probobly have to subclass a control with a virtual function for the right button, but I'm not sure if I have to have a virtual function. I need to be able to write the function at design time.
Any suggestions?
Do the help messages you want to display for the various buttons differ not only in the message itself, but also in the way displaying the message is handled? If not, a simple CString member (or something similar) in the derived class could hold the message.
If you are really going to use a virtual function, you will need a separate class for every single button. (They would then be derived from a single common base class that in turn is derived from CButton.)
HTH
How can that be such an insightful remind ? :)
Why not? Subclass the control, add a ON_COMMAND_RANGE handler, and use a std::map to map the control id to a CString. When your range handler gets called, do a lookup in the map to get the CString value.Quote:
Originally Posted by ADSOFT
Is this CMap or std::map ?Quote:
Originally Posted by Eri523
Oops, message mapping already is about map
Left click to do, right click to help! sounds not right in usual format
Nice nofifying message works better, you don't think so ? e.g mousehovre
Excellent suggestions.
I got something to work but I'm not too thrilled about it. I overode the PreTranslate member function of the diaglog box and Trapped the RightMouseButton and got the hwd(window handle of the control).
I know that messing with PreTranslate is not good Framework programing.:confused:, though.
What about creating a function pointer?
I can intialize it to NULL. After overriding the Right Button, it will excute the function if it's not NULL.
I would like the function to be either global or a member function of a FORMVIEW or CDialog.
Any suggestions?
Well, from the semantic point of view, that wouldn't be too much a difference compared to a virtual function. In fact, virtual functions are internally implemented in terms of function pointers. :) But the function pointer approach would be more C-style, not really C++.Quote:
Originally Posted by ADSOFT
I would suggest to try to avoid global functions as long as possible. I don't really know how member pointers to member functions are handled. I simply never had the need to even consider using something like that. Static member functions, however, would be handled much like global functions in that respect. (We already had a recent discussion about that, you remember? ;))Quote:
I would like the function to be either global or a member function of a FORMVIEW or CDialog.
Quote:
Originally Posted by Eri523
I created a CButton derived class with CString member functions and OverRode the OnRButtonDown function. Initalized the CStrings on OnInit of the Dialog. Worked Great!!
I still want to toy with the Static Function pointer stuff. I believe that you can make a function pointer to a member function of a given Class as a member of the Class. In otherwords, I can create two member function pointers of my CButton Derived Class that would pointer to Member functions of CFormView and CDialog. I could set flags as to which to implement or just execute them as long as the function pointer don't point to NULL. ...Of course you are more than welcome to try it before me and let me know.
How does Microsoft/MFC set it up that you are allowed to create a message handler for Bn_Clicked and DblBn_Clicked. We should be able to somehow do the same thing?
Did you consider handling WM_RBUTTONUP (or, perhaps, better, WM_CONTEXTMENU) rather than WM_RBUTTONDOWN?
Yeah, as far as I can tell this is your main point of interest now.Quote:
I still want to toy with the Static Function pointer stuff.
But considering your original post, function pointers would spoil the OOP approach. This is how I would handle the situation:
1. Right-clicked button becomes a source of event to help rendering object (HRO) encapsulating all the required details. At the same time the button becomes a context for the rendering.
2. A button does nothing but notify HRO providing minimal context information (most probably ctrlID would be enough).
3. HRO retrieves all the details corresponding to the context and renders the visual element (balloon for example) in accordance with the details and the context. (This way for example, the source control becomes a parent window for the rendered visual element.)
4. End of story. No place for function pointers though, sorry...
Or you could implement context help (help that uses the '?' icon that the user drags onto a control).
Yep, but you still have to subclass the Control. I was originally looking for a way to work with CButton and not to subclass the control.Quote:
Originally Posted by VictorN
Now, that I accepted that I have to subclass the control (unless you know of a way to overide OnRButtDown without subclassing).
At this point I'm looking for a way to add functionality to my Button Class at design time without haveing to modify the Derived class. All I can think of is a function pointer or a pointer to function of the class type I'm working with?
Isn't the Context Help only for the the Dialog Class(or the parent of the CButton).Quote:
Originally Posted by Arjay
What's your goal? Is it to generate help text for a control? If so, that's what context help is for. It's implemented on the parent window (dialog, etc) that contains controls. It's not implemented for each control (unless the control is a container of other controls).Quote:
Originally Posted by ADSOFT
Sound like it should work:Quote:
Originally Posted by Arjay
Quote:
afx_msg void OnContextMenu( CWnd* pWnd, CPoint pos );
Parameters
pWnd Handle to the window in which the user right clicked the mouse. This can be a child window of the window receiving the message. For more information about processing this message, see the Remarks section.
pos Position of the cursor, in screen coordinates, at the time of the mouse click.
pWnd is a pointer to a window, not a handle????
I read some of the examples and they usually just pop up a menu when the right button is clicked. I haven't seen on where you right click a control. The example leads you to believe that is mostly for the parent window.
I'm goint to try it on a tree control, lets see what happens.
That worked:
Code:void MyDialog::OnContextMenu(CWnd* pWnd, CPoint point)
{
// TODO: Add your message handler code here
if(pWnd == &this->m_tree_database){
AfxMessageBox("RMouse on Tree Control");
}
}
And the same will work for each but tree control (if you will implement it in the control derived class).
For a tree control it is a bit more tricky.
Quote:
Originally Posted by VictorN
The Above code works. I tested it.
Context help for a tree control isn't very interesting. Solve it for a per tree item basis and then you'll have something.
Probobly, the point I was trying to make is that Context help works for a control, if you want to solve for items in the control, that will require more processing.Quote:
Originally Posted by Arjay