Hi
If you had to write a custom control for your application, which type of control would you write?Activex or Ordinary?
What are the advantages/disadvantages of MFC ActiveX versus ordinary MFC control?
Printable View
Hi
If you had to write a custom control for your application, which type of control would you write?Activex or Ordinary?
What are the advantages/disadvantages of MFC ActiveX versus ordinary MFC control?
One of the important things to consider in making this decision is where the control will be used. If you plan to use the control with other applications built upon other languages (ie. Visual Basic), you should should choose ActiveX. ActiveX controls are actually COM components, so, they are designed to be compatible with any language that supports COM. If on the other hand, your application is the only one to use the control, you may be better of just designing a control library (ie. MFC extension dll). The advantage would be that you don't nned to speak COM to talk to the control. Another alternative would be to build an ATL control.
Thanks for opinion.
Actually "to speak COM to talk to the control" isn't problem for me.
I think the advantage of activex is:
-If the control activex, developer can adjust its property, events using IDE( I mean Properties window). But we can't use this feature for ordinary controls.
Advantages of choosing ordinary controls (I am not sure if these are completely right)
-I heard that ordinary MFC controls are faster than activex.
-Also if someone get your ocx control, he/she can use it without lib and header file. But ordinary controls must be shipped with lib and header file. So control writers can protect illegal use of his control by writing ordinary controls.
If flexibility is important writing Activex controls must be chosen.
and
If performance is important writing ordinary MFC control must be chosen.
Do you agree?
And, i searched for controls, there are so many firms that sell .NET controls but i couldn't see anyone advertise activex controls.(for example http://www.dundas.com/Products/index.aspx ). What is wrong with native(unmanaged) control development? For example why didn't Dundas write and sell MFC Chart controls, why are they only .NET?
MFC and ActiveX are older technologies. If you've coded controls in C# and especially in WPF, you'll understand why things have progressed.Quote:
Originally Posted by sawer
Thank you Arjay,
Yes, older but can't be decompiled technologies. So native coding never dies.
For database and web applications,(ERP) C# is ideal but for desktop applications that we use in our computers, i think we will never see .NET base applications.
Am i wrong?
Also we can do whatever can be done with .NET. Both database and web. (To be honest, whatever they try to prove, C#(in general manged world) is only script language/technology)
So still i don't figure out,why did they stop to develop MFC/activex controls?
Sure native code can be reversed engineered. .Net code can be obvuscated. In the end either one can be reverse engineered.Quote:
Originally Posted by sawer
One of the things that .net offers is a more cohesive programming environment. In C++ you needed to learn some sort of windowing technology (Win32, MFC, ATL, WTL, or some other framework) to write the basic application. Need some collections? Roll your own (last resort) or use stl or MFC collection classes. How about sharing data between applications? No unified way to do interprocess communication. You can use memory mapped files, name pipes and the like - yet another learning curve. Actually COM helped greatly with IPC, but yet another learning curve. How about 3d programming? Got to learn DirectX. Network programming. Yep another set of api's. The list goes on and on.Quote:
Originally Posted by sawer
In the latest .Net technologies such as WPF and WCF, the programming is more unified throughout.
For example, imagine if I wanted to create a button and display a movie when I clicked on the button. What technologies would be needed in C++? A experience developer would start walking through the approach and start listing the various technologies. Now what if I said you need to display the movie inside the button? How would you approach the problem now?
What would an inexperienced developer do? Imagine the learning curve for that?
In WPF, an experienced dev can to this in about 5 minutes. I believe I have a reasonable chance of teaching a beginner how to do this with WPF/C#. I don't believe I can teach a beginner how to do this in C++ because of the additional technologies that would be required to get the job done.
Sure you can, but how much time will it take? In terms of databases, in C++ I've interacted with them using raw ODBC, MFC database classes, ATL's OLEDB consumer classes, and ADO. Each one of these was an improvement over the previous (except for maybe the last one). I've also done this in C# and I can tell you there is less setup and the code is cleaner in C#.Quote:
Originally Posted by sawer
Coding in C# definitely isn't like scripting - at all.Quote:
Originally Posted by sawer
I can't speak for them, but I imagine it's about what their customers are asking for. If you have 1000 asking for a .net solution, and 3 asking for ActiveX, as a company, what are you going to target?Quote:
Originally Posted by sawer
This is the main point and I think this is not disadvantage. On the contrary, to learning Win32, ATL, MFC, WTL, STL etc. is making you experienced programmer. You can see engineering. All of them has something to give you.Quote:
Originally Posted by Arjay
First i learned C# and write some database apps to learn it. But when i learned C++(i mean vtable, why pointers are evil etc.), i understood that managed world has nothing with engineering.
It depends on what your goals are. There's nothing wrong with learning and gaining experience. However, from my point of view, I'm interesting in building systems in a reliable and rapid fashion. I can build the same reliable systems that I could have done with C++, but in C# I can do it in 1/4 the time (and have an easier time doing it).Quote:
Originally Posted by sawer
Btw, I'm not here to lobby anyone to switch. For me, I need to investigate newer technologies to find out if they help me get things done better and faster in my work. I first looked at C# in 2002 and wasn't impressed. In about 2004, I took another look and did some more coding. It was much improved and I started to see the benefits. Since then, the framework just becomes more and more evolved and more powerful - especially since the arrival of WPF and WCF. Quite frankly I don't want to go back to doing things the old way.