What are you trying to do? Do you already have a VB6 from that is using the MMListTree? If so are you trying to convert it to .Net? If so, why? VB6 still works within ArcMap. We (ArcFM) still have VB6 controls running within ArcMap without any problems.
If you have samples (besides the one that comes in the Developer SDK) would be nice if you could send me.
This is the problem:
I have a VB6 application for ArcFm 9.2.1 version and we trying to upgrade to .NET.
This VB6 application has an ocx control called MMListTree.ocx. This ocx file contains a control called “Miner & Mine List Item Tree View Control”
The control implements an object called MMListTree that can be added to a windows form.
Open Visual Studio and go to the ToolBox and tell me if you see an MMListTree?
In the version 10.1 there is not an object called MMListTree inside the ToolBox in the Visual Studio 2010, so the only way to bring this object into the form is by adding a COM Reference to the MMListTree.ocx. When I do the reference to this ocx, it adds other libraries. However, five of the new libraries that are added have broken connections. These are the broken libraries that are added to the list of references that are broken: mmControls, mmFramework, mmFrameworkUI, mmGeodatabase and MMListItemTree
I just got an email from your product team:
Hi Luis -
Here is what I was told by the product team....
MMListTree is the same place it has always been, mmListTree.ocx. There is a Word Doc (attached) that explains how to use this in Visual Studio and an Esri Add-In (also attached) that uses the MMListTree control on a dummy form that shows the contents of our selection tab as an example. If you use this method, in order to continue to use our tree control, you need a valid Infragistics license to recompile that code.
If moving to .NET, it is recommend that you use a native .NET control provided by Microsoft, rather than continuing to leverage our old Infragistics control.
- Easier development experience
- Way more resources when you run into problems
- Fine control over how your tree control behaves specific to your application
- Can more easily customize the experience/look-and-feel
- Comes built into the framework and is written by Microsoft
There are 2 controls, depending on if you are using Windows Forms or WPF, but both are simply called TreeView.
When we re-wrote the attribute editor, features tab and graphics tab, we abandoned the Infragistics control and went this route ourselves, using native .NET features to mimic the look and feel of the old controls. We'd recommend everyone else do the same, if you are going to to convert your code, this is a great time to get rid of it.
Hopefully this gets you moving in the right direction.