Reuseability of controls
-
Good Morning Fellow Coders; I have a treeView that I have developed over the years. It has all the things that I need it to do in most of my apps including the ability for the user to persist it to a file on the hard drive. The problem is that I use it in many apps that I write but, as I adapt it to different apps it can only open files for a the app it was compiled in. My questions is this. How do I re-use it and keep the ability to open any of these files from any app I use it in? Do I create a stand-alone project for just the tree then change the namespace or do I have to make a control out of it? Any thoughts will be appreciated... tia rafone
Statistics are like bikini's... What they reveal is astonishing ... But what they hide is vital ...
-
Good Morning Fellow Coders; I have a treeView that I have developed over the years. It has all the things that I need it to do in most of my apps including the ability for the user to persist it to a file on the hard drive. The problem is that I use it in many apps that I write but, as I adapt it to different apps it can only open files for a the app it was compiled in. My questions is this. How do I re-use it and keep the ability to open any of these files from any app I use it in? Do I create a stand-alone project for just the tree then change the namespace or do I have to make a control out of it? Any thoughts will be appreciated... tia rafone
Statistics are like bikini's... What they reveal is astonishing ... But what they hide is vital ...
Rafone wrote:
How do I re-use it and keep the ability to open any of these files from any app I use it in?
You redesign it with extensibility points. In your example, saving and retrieving the tree state from a file and you having different file formats for various applications, you would add the ability of being able to query in all ways necessary the state and structure of the tree. Another class is responsible for persisting this to where ever you need it (file, database, whereever). If you have multiple ways of storing it you have multiple classes responsible for persisting the information. Single responsiblity principle.
-
Rafone wrote:
How do I re-use it and keep the ability to open any of these files from any app I use it in?
You redesign it with extensibility points. In your example, saving and retrieving the tree state from a file and you having different file formats for various applications, you would add the ability of being able to query in all ways necessary the state and structure of the tree. Another class is responsible for persisting this to where ever you need it (file, database, whereever). If you have multiple ways of storing it you have multiple classes responsible for persisting the information. Single responsiblity principle.
Let me see if I can clarify. Right now I use it in a couple of apps. If I try to open one of the files made from myApp in myApp2 I get an exception... "Unable to find assembly 'myApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'."} All I have done was to copy my tree.cs file from myApp to myApp2 and changed the namespace so it will work in myApp2. So...is this because the namespace's are different? If so can I just reference the myApp namespace in myApp2 and use the tree components from myApp? tia rafone
Statistics are like bikini's... What they reveal is astonishing ... But what they hide is vital ...
-
Let me see if I can clarify. Right now I use it in a couple of apps. If I try to open one of the files made from myApp in myApp2 I get an exception... "Unable to find assembly 'myApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'."} All I have done was to copy my tree.cs file from myApp to myApp2 and changed the namespace so it will work in myApp2. So...is this because the namespace's are different? If so can I just reference the myApp namespace in myApp2 and use the tree components from myApp? tia rafone
Statistics are like bikini's... What they reveal is astonishing ... But what they hide is vital ...
Hi, as long as you included a reference to your DLL, you can refer to its public types, either using the full name (mySpace.mySubspace...MyClass) or using a using statement (using mySpace.mySubspace; ) and a short name (MyClass instance=new MyClass()). There is no need to modify namespace names, they exist to help you keep things apart (avoid name clashes), not to make your job more difficult. PS: the types need to be public, VS often creates classes without attributes, just prefix "public". :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
-
Hi, as long as you included a reference to your DLL, you can refer to its public types, either using the full name (mySpace.mySubspace...MyClass) or using a using statement (using mySpace.mySubspace; ) and a short name (MyClass instance=new MyClass()). There is no need to modify namespace names, they exist to help you keep things apart (avoid name clashes), not to make your job more difficult. PS: the types need to be public, VS often creates classes without attributes, just prefix "public". :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
-
Excellent! Exactly what I needed. Thanks Luc rafone
Statistics are like bikini's... What they reveal is astonishing ... But what they hide is vital ...
You're welcome. :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.