C# and MFC

[C Glenn]

Can an application be created using C# and MFC?

Can I use ActiveX objects created with MFC in a C# app?

 

[ALI RAZA]

1) Micorosoft Foundation Classes (MFC) are used for design of GUI etc, but
in C# there are lots of classes provided to work with GUIs like
Microsoft.Forms, so you cannot use MFC in C#.

2) use the ActiveX Importer Tool to import it in C#

ALI RAZA SHAIKH
MCAD.net

 

[Nicholas Paldino [.NET/C# MVP]]

C Glenn,

You can use objects created in MFC by compiling your unmanaged code with
the /clr switch (although it might blow up if you use it with an MFC
project, better to have the managed code contained somewhere else).

Also, you can expose MFC objects by creating COM wrappers for them and
then importing those into .NET.

See Ali Raza's response for using ActiveX controls in .NET.

Hope this helps.

 

[Alvin Bruney - ASP.NET MVP]

You can split the two so that one is an unmanaged assembly that is loaded by
the managed assembly - Is that what you are asking? Anyway what is the point
of combining the two? MFC is used for windows apps, C# is used for the same
thing under managed code

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006

 

[C Glenn]

The point to my question lies in the bigger question, is the .NET
highway going to take my client where he wants to go?

My client requested that his app be built in .NET but he's now asking me
for features that the .NET components don't provide. In fact, in some
cases, he is asking me for Access97 component behavior (ComboBoxes and
Continuous Forms). I can't fault him for it either, the dropdown
ComboBox behavior in Access is more advanced (I understand that .NET 2
will include autocomplete or incremental search), and Continuous Forms
are really cool.

Looking at sites like Programmer's Paradise and seeing the component
packages makes us wonder if we wouldn't be better off buying something
packaged. I don't think he's going to be happy with anything out there
though -- some of his other requirements are things I've never heard of.
(Not unreasonable, just different.)

Anyway, that's the reason for the question. I'm wondering if ActiveX
components might be an option and how much trouble they would be.

Thanks.

 

[Richard Grimes]

The point to my question lies in the bigger question, is the .NET
highway going to take my client where he wants to go?

MFC is an application framework. Windows forms has few of the features
that MFC has. For example, MFC has command routing so that toolbars,
menus and the status bar are all connected, so if you highlight a menu
item the helpstring will appear in the status bar, and if there is a
toolbar button associated with a menu item the menu item has the toolbar
button icon. MFC also has document management features. You get all of
that for free with MFC.

You can do all of that with Windows Forms, but you have to write the
code to do it. Microsoft took the decision not to give you those
application framework features in WinForms. I think there are two
reasons for this: 1) WinForms is ported from VB6 (I have no evidence of
this, but the similarities between the two are tangible) 2) they didn't
want to give us too many features because they wanted developers to
eventually move over to Avalon.

My client requested that his app be built in .NET but he's now asking
me for features that the .NET components don't provide. In fact, in
some cases, he is asking me for Access97 component behavior
(ComboBoxes and Continuous Forms). I can't fault him for it either,
the dropdown ComboBox behavior in Access is more advanced (I
understand that .NET 2 will include autocomplete or incremental
search), and Continuous Forms are really cool.

As mentioned in other posts, if you have an activex control you can use
COM interop to use it on a .NET form. BTW a .NET form is a COM object -
it has to be able to provide drag and drop, which is an OLE32 feature.

Anyway, that's the reason for the question. I'm wondering if ActiveX
components might be an option and how much trouble they would be.

I cannot speak about the components that you cite, but in general COM
interop works well. If you want a book on the subject the best one (and
the *only* one to consider IMO) is Adam Nathan's ".NET and COM: The
complete interoperability guide" (and it is).

Richard