We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy.
Unfortunately, activation email could not send to your email. Please try again.

Class library structure

Thread ID:

Created:

Updated:

Platform:

Replies:

201 Apr 26,2002 09:55 AM Apr 26,2002 03:03 PM Windows Forms 2
loading
Tags: Tools
Bob Grommes
Asked On April 26, 2002 09:55 AM

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?

Administrator [Syncfusion]
Replied On April 26, 2002 02:19 PM

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

Bob Grommes
Replied On April 26, 2002 03:03 PM

> 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

CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.

;