I've derived a custom control from ATL::CWindowImpl<CMyCustomControl> and declared DECLARE_WND_CLASS(_T("CMyCustomControl")).
I've also made a dialog resource with a custom control with the class name CMyCustomControl.
How do I go about registering the control properly so I can display it on the dialog?
There are thre typical way to create custom controls in WTL.
DECLARE_WND_CLASS/DECLARE_WND_SUPERCLASS + RegisterClassEx API to register class by name + custom control reference in dialog template to instantiate control through class name
Implement window class, esp. inheriting from CWindowImpl, and create control manually, esp. from OnCreate/OnInitDialog
Implement window class, instantiate standard control through dialog template, and subclass the control instance to alter its behavior (e.g. static with hyperlinks, custom list view, edit control with color highlighting etc)
With all three you need to do more than just a macro in class definition. You will find great examples here: http://www.viksoe.dk/code/all_wtl.htm under "Controls" section.
Certainly the fourth method is implementing an ActiveX control.
Related
I'm using raw Win32 and C++ for a project. As I understand it, I am able to superclass Windows controls by retrieving the class information, replacing the procedure, then registering this as a new class and using it when creating a new window. Subclassing is done by replacing the window's procedure after the window is created. The advantage of superclassing is that you are able to process messages before CreateWindow() returns.
I'm looking to see if it's possible to superclass a dialog box created with CreateDialog() because I'd like to use a resource file for the dialog layout. The problem is that I don't know how I would provide my superclass when I create a dialog box. Is it even possible? Any idea how MFC handles this?
If you use an extended dialog box template to create your dialog, you can specify a custom window class as part of the DLGTEMPLATEEX definition.
The dialog manager will create and layout your dialog as normal, and call your window procedure for any dialog messages. You can use the DefDlgProc function to obtain default processing for any dialog messages you don't want to handle yourself.
I am more use to Qt than MFC, but I have the following concern:
I was creating a panel with 4 buttons, all these buttons have the same purpose, if you click on them it opens another dialog.
This dialog has the exact same layout for the 4 buttons.
However since a dialog is associated to a class via the enum { IDD = ...} I was wondering if it was actually possible to use the same template of dialog for more than one object or if I had to actually create 4 dialogs doing basically the same thing with a different id??
The resource ID in the statement enum { IDD = <resource ID> }; defines a compile-time constant, that is passed to the CDialog-c'tor (by default1)) to construct the native controls from a dialog template resource. This is then passed to one of the dialog creation functions (CreateDialog, etc.) to do the heavy lifting.
There are no restrictions to prevent using a single dialog template for multiple CDialog-derived classes.
1) You can pass the dialog template resource ID directly to the CDialog-c'tor in your custom class implementation, and do not need to use the standard enumerated value IDD.
Background
I am woefully inexperienced with MFC and C++.
I have a set of dialogs that all have a small section with the same set of controls and extremely similar code.
I would like to separate that small section of controls from all dialogs move the code from all the dialog classes into a single class.
Problem
I'm not sure how to go about it. All my ideas all seem to have their own problems because I am so inexperienced.
Could I make a super class these dialogs inherit from that creates the controls dynamically given an (x, y) and that hooks up all the connections and communicates the few specifics through virtual methods?
The problem is I don't know the specifics:
Where would the super class inherit from? (CWnd? CDialog?)
Where would I create the controls in the super class? (OnInit? Constructor?)
Where would I initialize the super class in its subclasses? (OnInit? Constructor?)
Would I just have two message maps? One for the super class and one for the sub class?
Are there any other pitfalls I should watch out for?
The small section that you want to reuse can be an ordinary modeless dialog, derived from CDialog. You can create its controls with the resource editor - just like any other dialog - so they won't have to be created dynamically. The trick is to turn off the dialog's titlebar style (in the resource editor) so it will not be visually apparent that this section is a separate dialog. It will blend right in with the parent dialog.
For each place you want to reuse this dialog just create it and place it on the parent dialog with (x, y) coordinates using SetWindowPos.
I want to make a custom made component (a line chart), that would be used in other applications.
I don't know 2 things:
Where should I use (within component class!) the methods for drawing, like FillRect
or PolyLine? In OnPaint handler that I should define and map it in MESSAGE MAP? Will
it (OnPaint handler) be called from OnPaint handler of the dialog of the application
or where from?
How to connect the component, once it is made, to the test application, which will
for example be dialog based? Where should I instantiate that component? From an
OnCreate method of the MyAppDialog.cpp?
I started coding in MFC few days ago and I'm so confused about it.
Thanks in advance,
Cheers.
Painting the control is handled exactly like it would be if it wasn't a control. Given that you're using MFC, that (at least normally) means you do the drawing in the View class' OnDraw (MFC normally handles OnPaint internally, so you rarely touch it).
Inserting the resulting ActiveX control in the host application will be done like inserting any other ActiveX control. Assuming you're doing your development in Visual Studio, you'll normally do that by opening the dialog, right clicking inside the dialog box, and clicking "Insert ActiveX Control..." in the menu that pops up. Pick your control from the list, and it'll generate a wrapper class for the control and code to create an object of that class as needed. From the viewpoint of the dialog code, it's just there, and you can use it about like any other control.
For create new component in MFC, you must create a class from the window class (CWND),
after that you can have your MessageMap for the component and your methods and also can override CWND::OnDraw method to draw the thing you want.
Before that I suggest you to take a look to device context
http://msdn.microsoft.com/en-us/library/azz5wt61(VS.80).aspx
Good Luck friend.
I have several forms that have common sections and I would like to pull them out into their own resource. Basically I am looking for a way to make a CFormView into a windows control that I can insert into another CFormView.
You can create a modaless dialog from the same resource template and create it on a form view. This means you need to refactor your code so the event handlers can be reused between the dialog and your original form view.
CFormView expects it's parent to be a frame. To remove that dependency you need to override all functions that reference the parent frame, which is tedious to do, and each version of MFC may introduce new functions that references the parent frame.