A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm designing a C# "Windows Forms" thick client, for displaying biomedical signals. There may be a web-based client too, in the future.
I'm preparing to evaluate 3rd-party graph components to embed in this application; among them, one is an ActiveX component and another is a .NET component. I've seen that Developer Studio makes it easy to embed an ActiveX control in a form, and to invoke its API from C# code; and, this particular ActiveX component documents this scenario as being one of the ways in which its use is supported.
In both cases, the component license includes source code.
It seems to me that maybe there are reasons to prefer one implementation over the other, but I don't know; maybe they're about the same.
What do you think: is there an important difference?
From a deployment perspective, the .Net component will require .Net runtime. Not all machines have this, so it would need to be downloaded and installed on the client.
The infrastructure to support ActiveX is more-or-less part of almost all Windows machines at this point.
> From a deployment perspective, the .Net component will require .Net runtime. Not all machines have this, so it would need to be downloaded and installed on the client.
No, I think that the rest of the application is a .NET Windows Forms application, and so it can be assumed that the .Net runtime *is* already installed.
The things that I imagined might be different are:
* Performance: the cost of pushing graph's plots from C# over the ActiveX interface, contrasted with the cost of a .NET graphing component making GDI calls via the .NET framework
* Security: is there any advantage to having only "managed" (i.e. .NET) code in a thick client? The application won't be downloaded from the internet; it will be shipped on CD, or PCs may be shipped with the application pre-installed.
* Web client: whether, and how or where (server-side or browser-side) the component may be reusable in a web-based client
* ?what else?
"No, I think that the rest of the application is a .NET Windows Forms application, and so it can be assumed that the .Net runtime *is* already installed.
Will your web-based version also be .net based?
I'm curious: what's the benefit of a web-based .net app?
Once the .net runtime is installed (no small feat), installing an actual program is trivial (xcopy,etc.).
What are the compelling benefits of a web based app that outweigh the costs of development?
I'd hope that the .NET based control supported .NET based data structures eg ADO.NET datasets or collections with an IEnumerable interface.
If the .NET component is a straight port of an ActiveX, then there's not a lot of value using it especially as the Ax is likely to be more mature.
Thursday, May 05, 2005
> I'd hope that the .NET based control supported .NET based data structures eg ADO.NET datasets or collections
That's a good point, Mark.
Actually the data I want to display (in the thick client) is coming from a network stream or from a disk file; I'll be feeding it to the graph as a primitive array of numbers: so the component doesn't need to integrate with other APIs (it only needs to be callable from my C#, and able to be placed on top of a .NET Form).
.NET is much better technology than ActiveX.
There are many nightmares with deployment and versioning, etc... .NET has solved most these issues. Look into smart client
Thursday, May 05, 2005
You want to use a native (100% managed) .NET component for that.
ActiveX components are "unmanaged" by definition and directly access Windows API and manage their own memory allocations - which might be considered dangerous in .NET runtime environment.
Using ActiveX/COM components in a .NET application also introduces additional overhead such as type conversion, marshalling etc.
Saturday, May 14, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz