The Syncfusion® native Blazor components library offers 70+ UI and Data Viz web controls that are responsive and lightweight for building modern web apps.
.NET PDF framework is a high-performance and comprehensive library used to create, read, merge, split, secure, edit, view, and review PDF files in C#/VB.NET.
Historically I have resisted reliance on third party libraries (stability, support and versioning issues) but am intrigued by your products and your source code options. You seem to have figured out what is important to induce me to consider your product!
One thing that is not discussed anywhere on your site that I can find, is how your products fit into existing class hierarchies.
I am new to .NET and still mulling the possibilities, but in other OO environments the first thing I normally to do is subclass all the supplied base classes, particularly for forms and controls, even if I initially don't implement anything new in them. Then inherit everything in my application from those subclasses. That way I can make changes later at the top-level subclass to implement universal functionality enhancements across all applications. Thus in .NET terms, using namespaces, you'd have something like this for your inheritance tree for forms:
Windows.Forms.Form --> DeveloperLib.Form --> App.Form
... or maybe:
Windows.Forms.Form --> DeveloperLib.Form --> ClientXLib.Form --> App.Form
... giving you a global access point for all clients, a specific client, or a specific client app.
This is an aspect of class design that's particularly handy for GUI classes, and I haven't seen this discussed anywhere for .NET; people seem to just be using BCL classes directly in their applications. Doesn't seem like a very forward-thinking approach to me.
Assuming I want to create a hierarchy similar to that outlined above, how would your class libraries plug into such a scheme? If I wanted your Tools library to be part of my inheritance tree, I realize I could take the source code version of Tools and change what the Tools classes inherit from to be, say, my DeveloperLib-level classes rather than directly from the BCL. But that sounds clumsy to maintain and has some potential for conflict with any existing fields, properties or names in my classes (doesn't happen to be an issue for me as I haven't written them yet, but I'm trying to think at a bit of a higher level here).
Do you have any presale docs on your class hierarchy and any recommendations on how to integrate cleanly?
ADAdministrator Syncfusion Team April 26, 2002 06:19 PM UTC
Hi Bob,
Thanks for your interest in our Tools.
With .NET there is no support for generics at the moment. So, there is no easy way to do what you are planning to do. Our classes do have explicit references to BCL classes. At this time this would indeed mean source code changes. But support for generics in .NET cannot be far off. Once .NET does support generics we will definitely want to make it easier for users to do what you have described.
We have no complete class diagram charts yet. We are however in the process of preparing these and should have them done within a week. We will make these available as soon as they are ready.
Regards,
Daniel
Syncfusion
BGBob GrommesApril 26, 2002 07:03 PM UTC
> support for generics in .NET cannot be far off. Once .NET does support generics we will definitely want to make it easier for users to do what you have described.
Hm. You may be correct, here is their work in progress:
http://research.microsoft.com/projects/clrgen/generics.pdf
Thanks for the info and I will look for your class heirarchy docs to appear soon.
--Bob