MFC SDI Explorer-style project -- How can I use 3rd party ActiveX OCXs in the treeview/listview panes?

[GS]

Hi,
I'm just starting to use C++ (vs2008 Pro) after working with VB[A] for
some years. I'm trying to convert a VB6 project to C++ MFC so I can
continue to use my existing OCXs. These are a treVw.ocx, fileVw.ocx,
and Farpoint's Spread.ocx.

I have these working in a Dialog-based project right now, but I want a
splitter between the treeview and fileview OCXs. An added complication
is that the fileview and Spread OCX need to occupy the same real estate
on the form so switching views is just a matter of toggling their
visibility. I already have this working in the Dialog-based project,
but I need a splitter to adjust pane widths.

For clarity.., at this point I've only duplicated the UI. The only
other functionality added thus far is using CHM help, and so I'm at a
really early stage in the conversion. I want to get the UI functioning
as expected before adding any more content.

In VB a splitter is easily achieved using a label. My research into
doing this in C++ concludes that although it's doable, ..some very
complex (to me at this point) code is necessary.

The Explorer-style project already produces a project with a dialog
having a splitter that works as I need it to. I just don't know how to
code for my OCXs to occupy the panes as needed. (Nor do I know if the
OCXs will work in the default form!)

Any help/suggestions will be most appreciated!
Also, any recommendations for good books on C++ MFC programming would
be most helpful...

[retiredmvp]

The MFC splitter normally contains two CView-derived classes. The wizard-generated explorer style app uses a CTreeView and a CListView. If you want to use your ocx's instead of those views then change both views to be derived from CFormView. A CFormView is very much like a dialog and it supports all kinds of controls. What you did in your dialog based test project will work the same way with CFormViews.

It is possible to change the wizard-produced views but it is probably safer to generate new view classes (Project menu, Add Class, MFC...) to generate the new CFormView-based classes and use them to completely replace the wizard-generated views in your project.

[GS]

Post by retiredmvp
The MFC splitter normally contains two CView-derived classes. The
wizard-generated explorer style app uses a CTreeView and a CListView.
If you want to use your ocx's instead of those views then change both
views to be derived from CFormView. A CFormView is very much like a
dialog and it supports all kinds of controls. What you did in your
dialog based test project will work the same way with CFormViews.
It is possible to change the wizard-produced views but it is probably
safer to generate new view classes (Project menu, Add Class, MFC...)
to generate the new CFormView-based classes and use them to
completely replace the wizard-generated views in your project.

Thank you so much! (I was beginning to think this group was dead!)

As stated, I'm new to C++ MFC and so don't have enough background with
it to move forward beyond what I've stumbled into using the wizards.
I've concluded, meanwhile, that I might be better off starting with an
empty project and building just what I need. To help my learning curve
I've ordered a few (seemingly good) books specifically about MFC
programming from amazon.

My goal:
I'm hoping to create a template (that I can build other projects from)
that starts with a main() function to evaluate startup conditions prior
to presenting a UI. This will include my licensing code which consists
of a dialog, a code module, and a crypto class. This is the approach I
use currently in VB6 and hope it's possible to continue the concept in
C++ MFC. Any additional direction you could recommend will be most
appreciated!

[retiredmvp]

This group is dead. The most active place to post MFC questions is
http://stackoverflow.com/questions/tagged/c%2b%2b

You can certainly do what you describe, but in an MFC GUI it has to start in InitInstance. MFC does main() - actually winMain() - so it can initialize some things, then it calls InitInstance.

[GS]

Post by retiredmvp
This group is dead. The most active place to post MFC questions is
http://stackoverflow.com/questions/tagged/c%2b%2b
You can certainly do what you describe, but in an MFC GUI it has to
start in InitInstance. MFC does main() - actually winMain() - so it
can initialize some things, then it calls InitInstance.

Thank you.., I appreciate your interest! I'll follow your link...