Scope
-
I've been digging throught my large stack of C# books in an effort to find some information on how to get multiple source files to work together and haven't found anything usefull. For instance, it seems reasonable to me to place a function call in the event handler and place this function (method) in some other file. My knee-jerk reaction is to make a header file but that doesn't fly here. What keyword do I need to search for? I've looked under scope, modules, visibility, and assemblies and somehow keep missing it. Are all the static methods global within an assembly? Is this good practice? Thanks Ken Galer Electrical Engineer Preferred Utilities Corp. Danbury, CT 06810
-
I've been digging throught my large stack of C# books in an effort to find some information on how to get multiple source files to work together and haven't found anything usefull. For instance, it seems reasonable to me to place a function call in the event handler and place this function (method) in some other file. My knee-jerk reaction is to make a header file but that doesn't fly here. What keyword do I need to search for? I've looked under scope, modules, visibility, and assemblies and somehow keep missing it. Are all the static methods global within an assembly? Is this good practice? Thanks Ken Galer Electrical Engineer Preferred Utilities Corp. Danbury, CT 06810
in this version of c# all parts of a class must be in one file. in the next version you will be able to split the code up using "Partial Types"...
"When the only tool you have is a hammer, a sore thumb you will have."
-
in this version of c# all parts of a class must be in one file. in the next version you will be able to split the code up using "Partial Types"...
"When the only tool you have is a hammer, a sore thumb you will have."
-
I've been digging throught my large stack of C# books in an effort to find some information on how to get multiple source files to work together and haven't found anything usefull. For instance, it seems reasonable to me to place a function call in the event handler and place this function (method) in some other file. My knee-jerk reaction is to make a header file but that doesn't fly here. What keyword do I need to search for? I've looked under scope, modules, visibility, and assemblies and somehow keep missing it. Are all the static methods global within an assembly? Is this good practice? Thanks Ken Galer Electrical Engineer Preferred Utilities Corp. Danbury, CT 06810
Why does it seem reasonable to please the method that the event handler calls in another file? If the method is on the class that has the event handler, just call it. If it belongs to another class, make sure the class with the event handler has a reference to that class (unless it's a static method) and then call it on that object (or Type if it's a static method). This is just practical and common object oriented programming.
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
in this version of c# all parts of a class must be in one file. in the next version you will be able to split the code up using "Partial Types"...
"When the only tool you have is a hammer, a sore thumb you will have."
Philip Fitzsimons wrote: in this version of c# all parts of a class must be in one file. But this doesn't mean that you can't define non-class dependant
enums,delegates, etc... somewhere else. And, if you want to split members into several files to make things more organizable, then you might as well take a look at the#region[^] preprocessor directive. In VS.NET and SharpDevelop, you can expand and collapse the code between two#regionand#endregiondirectives. - Daniël Pelsmaeker
"Let others praise ancient times; I am glad I was born in these." - Ovid (43 BC-AD 17) Roman poet
-
Why does it seem reasonable to please the method that the event handler calls in another file? If the method is on the class that has the event handler, just call it. If it belongs to another class, make sure the class with the event handler has a reference to that class (unless it's a static method) and then call it on that object (or Type if it's a static method). This is just practical and common object oriented programming.
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Heath Stewart wrote: Why does it seem reasonable to please the method that the event handler calls in another file? I'm thinking of a case where the event is caused by a menu selection and that the same code would be run by other events such as a context menu, a toolbar button, or a drag-n-drop. If all these events could just call the same method, this would just be a way to keep things clean and obvious. I realize (now) that this could be a private method in the class. I was thinking a different file because it seems to me (based on very limited experence) that the file size is getting rather large. Just considering the stuff that handles the controls and events, etc. is large enough but if you also include the many different methods (that could be many pages long) called by the events it could get VERY large, hard to navigate, and slow down the build. I'm not sure if I'm being clear. As I buld my the applcation and add more functionality it usually consists of adding another event in form1.cs and adding code for the event. If form1 is the main form for a large project it's easy to imagine 50-100 events and associated code. GASP! :eek: Should I just not worry about it and make use of the methods dropdown box in VS and #region attributes or make some attempt at breaking the code into more managable files? Is is normal to have these large code files in C# projects? I may be stuck in C thinking mode. Thanks, Ken Galer Electrical Engineer Preferred Utilities Corp. Danbury, CT 06810
-
Heath Stewart wrote: Why does it seem reasonable to please the method that the event handler calls in another file? I'm thinking of a case where the event is caused by a menu selection and that the same code would be run by other events such as a context menu, a toolbar button, or a drag-n-drop. If all these events could just call the same method, this would just be a way to keep things clean and obvious. I realize (now) that this could be a private method in the class. I was thinking a different file because it seems to me (based on very limited experence) that the file size is getting rather large. Just considering the stuff that handles the controls and events, etc. is large enough but if you also include the many different methods (that could be many pages long) called by the events it could get VERY large, hard to navigate, and slow down the build. I'm not sure if I'm being clear. As I buld my the applcation and add more functionality it usually consists of adding another event in form1.cs and adding code for the event. If form1 is the main form for a large project it's easy to imagine 50-100 events and associated code. GASP! :eek: Should I just not worry about it and make use of the methods dropdown box in VS and #region attributes or make some attempt at breaking the code into more managable files? Is is normal to have these large code files in C# projects? I may be stuck in C thinking mode. Thanks, Ken Galer Electrical Engineer Preferred Utilities Corp. Danbury, CT 06810
The size of the source file doesn't matter. It's the size of the compiled Type, but this really isn't an issue, either. The only thing that dictates how big an instance of that Type is (an object) is the fields that are holding data. The
System.Windows.Forms.ControlType is huge, for example, but an instance of one really would be that big at all. Yeah, using#regions effectively is a good idea. I use them a lot and they definitely help, as does the member bar at the top of the source file window. The partial classes mention elsewhere in this thread can help this problem, but it really doesn't matter. The main reason for partial classes is for the Avalon presentation layer in Longhorn, where part of the class is defined by XAML, and part of the class is defined in the code-behind file, almost like in ASP.NET except the .aspx file is actually compiled at run-time into a class that derives from your code-behind class, which derives fromSystem.Web.UI.Page(the same concept is true for .ascx files as well). That's just derivitive classes, though, not partial classes.-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----