443,627 Members | 2,339 Online
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,627 IT Pros & Developers. It's quick & easy.

# Static Class Constants (VB 2005)

 P: n/a Is there any way to create a constant in a class that can be used both with an instantiated object and without. For example: dim ClassConst as string = myClass.ConstantString dim myObj = new MyClass ClassConst = myObj.ConstantString Inside the class MyClass Class MyClass public const ConstantString = "Some Constant String" End Class In Beta 2, ConstantString was available in either of the above cases without complaint. In the RTM version, I can't do both. I don't want to turn off the warning as doing so may actually introduce another bug in my code later because I didn't see the warning. Thanks, Mike. Dec 8 '05 #1
29 Replies

 P: n/a If it's a constant, why not always reference it through the type name? What do you gain by accessing it through an instance? "Michael D. Ober" wrote in message news:uj*************@TK2MSFTNGP14.phx.gbl... Is there any way to create a constant in a class that can be used both with an instantiated object and without. For example: dim ClassConst as string = myClass.ConstantString dim myObj = new MyClass ClassConst = myObj.ConstantString Inside the class MyClass Class MyClass public const ConstantString = "Some Constant String" End Class In Beta 2, ConstantString was available in either of the above cases without complaint. In the RTM version, I can't do both. I don't want to turn off the warning as doing so may actually introduce another bug in my code later because I didn't see the warning. Thanks, Mike. Dec 8 '05 #2

 P: n/a Marina, "Marina" schrieb: If it's a constant, why not always reference it through the type name? What do you gain by accessing it through an instance? What do you loose by accessing it through an instance? -- M S Herfried K. Wagner M V P V B Dec 8 '05 #3

 P: n/a Michael i use the release version of Visual studio 2005 ( professional edition ) Public Class Form1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim ClassConst As String = XMyClass.ConstantString MsgBox(ClassConst) Dim myObj = New XMyClass ClassConst = myObj.ConstantString MsgBox(ClassConst) End Sub End Class Class XMyClass Public Const ConstantString = "Some Constant String" End Class this works without anny problems on my dev computer ( no warnings ) regards Michel Posseth [MCP] "Michael D. Ober" wrote in message news:uj*************@TK2MSFTNGP14.phx.gbl... Is there any way to create a constant in a class that can be used both with an instantiated object and without. For example: dim ClassConst as string = myClass.ConstantString dim myObj = new MyClass ClassConst = myObj.ConstantString Inside the class MyClass Class MyClass public const ConstantString = "Some Constant String" End Class In Beta 2, ConstantString was available in either of the above cases without complaint. In the RTM version, I can't do both. I don't want to turn off the warning as doing so may actually introduce another bug in my code later because I didn't see the warning. Thanks, Mike. Dec 8 '05 #4

 P: n/a Code readability. Mike. "Marina" wrote in message news:OE*************@tk2msftngp13.phx.gbl... If it's a constant, why not always reference it through the type name? What do you gain by accessing it through an instance? "Michael D. Ober" wrote in message news:uj*************@TK2MSFTNGP14.phx.gbl... Is there any way to create a constant in a class that can be used both with an instantiated object and without. For example: dim ClassConst as string = myClass.ConstantString dim myObj = new MyClass ClassConst = myObj.ConstantString Inside the class MyClass Class MyClass public const ConstantString = "Some Constant String" End Class In Beta 2, ConstantString was available in either of the above cases without complaint. In the RTM version, I can't do both. I don't want to turn off the warning as doing so may actually introduce another bug in my code later because I didn't see the warning. Thanks, Mike. Dec 8 '05 #5

 P: n/a There are times when accessing through an instance makes more sense - it ensures I'm working with the correct object/class type. Other times, accessing through the class type make more sense - when trying to verify class type of an unknown string representation of the object. In the latter case, class type verification can then be done without the overhead of creating an object that then gets immediately thrown away. Mike Ober. "Herfried K. Wagner [MVP]" wrote in message news:OA**************@TK2MSFTNGP15.phx.gbl... Marina, "Marina" schrieb: If it's a constant, why not always reference it through the type name? What do you gain by accessing it through an instance? What do you loose by accessing it through an instance? -- M S Herfried K. Wagner M V P V B Dec 8 '05 #6

 P: n/a Apparently you lose the ability to compile without getting a warner. You also lose code clarity, as now it is not obvious this is a constant. It could just be an instance property of the class, and it's not at all obvious that it is not. Where as seeing the type name in front, you see that this something that exists only once for the class. The point is, if you don't gain anything by doing it, and you lose readability, then why do it? "Herfried K. Wagner [MVP]" wrote in message news:OA**************@TK2MSFTNGP15.phx.gbl... Marina, "Marina" schrieb: If it's a constant, why not always reference it through the type name? What do you gain by accessing it through an instance? What do you loose by accessing it through an instance? -- M S Herfried K. Wagner M V P V B Dec 8 '05 #7

 P: n/a Regardless of Option Explicit and Option Strict settings on a brand new form with a single button, I get the error "Access of shared member, constant member, enum member or nested type through an instance; qualifying expression will not be evaluated." on your code sample. VS 2005 Standard RTM. Mike. "m.posseth" wrote in message news:ev**************@TK2MSFTNGP14.phx.gbl... Michael i use the release version of Visual studio 2005 ( professional edition ) Public Class Form1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim ClassConst As String = XMyClass.ConstantString MsgBox(ClassConst) Dim myObj = New XMyClass ''''''''''''' Error is on this line ClassConst = myObj.ConstantString MsgBox(ClassConst) End Sub End Class Class XMyClass Public Const ConstantString = "Some Constant String" End Class this works without anny problems on my dev computer ( no warnings ) regards Michel Posseth [MCP] "Michael D. Ober" wrote in message news:uj*************@TK2MSFTNGP14.phx.gbl... Is there any way to create a constant in a class that can be used both with an instantiated object and without. For example: dim ClassConst as string = myClass.ConstantString dim myObj = new MyClass ClassConst = myObj.ConstantString Inside the class MyClass Class MyClass public const ConstantString = "Some Constant String" End Class In Beta 2, ConstantString was available in either of the above cases without complaint. In the RTM version, I can't do both. I don't want to turn off the warning as doing so may actually introduce another bug in my code later because I didn't see the warning. Thanks, Mike. Dec 8 '05 #8

 P: n/a If this is about a constant, how does that help ensure you are working with the right class? There is no inheritance issue here. "Michael D. Ober" wrote in message news:OI**************@TK2MSFTNGP10.phx.gbl... There are times when accessing through an instance makes more sense - it ensures I'm working with the correct object/class type. Other times, accessing through the class type make more sense - when trying to verify class type of an unknown string representation of the object. In the latter case, class type verification can then be done without the overhead of creating an object that then gets immediately thrown away. Mike Ober. "Herfried K. Wagner [MVP]" wrote in message news:OA**************@TK2MSFTNGP15.phx.gbl... Marina, "Marina" schrieb: > If it's a constant, why not always reference it through the type name? > What do you gain by accessing it through an instance? What do you loose by accessing it through an instance? -- M S Herfried K. Wagner M V P V B Dec 8 '05 #9

 P: n/a "Marina" schrieb: If this is about a constant, how does that help ensure you are working with the right class? There is no inheritance issue here. That's true, but especially when dealing with public constants it seems completely irrelevant to me whether or not the member belongs to an instance or the class itself. I agree that it doesn't make much sense to obtain a reference to an object using complicated code only to access one of the public constants of the class. -- M S Herfried K. Wagner M V P V B Dec 8 '05 #10

 P: n/a I think for readability issues, and to make the developer aware that they are accessing a constant or static member, that warning is there. And that is why it is a warning, not an error. So if it's something one wants to do, they can. Though again, for readability and consistentcy reasons my opinion is that the class name should be used in these cases. "Herfried K. Wagner [MVP]" wrote in message news:ez*************@TK2MSFTNGP12.phx.gbl... "Marina" schrieb: If this is about a constant, how does that help ensure you are working with the right class? There is no inheritance issue here. That's true, but especially when dealing with public constants it seems completely irrelevant to me whether or not the member belongs to an instance or the class itself. I agree that it doesn't make much sense to obtain a reference to an object using complicated code only to access one of the public constants of the class. -- M S Herfried K. Wagner M V P V B Dec 8 '05 #11

 P: n/a Yes, this is a change in the VB.NET language and you will be force to change it. C#, and other languages have always done it this way. I think for the sake of better code clarity it was a good move, also this does not require any more work from the developer. It's is now obvious if a line of code is calling a shared/static or instance specific method. It can be a pain when moving code from 1.0 to 2.0, but at least the error is easy to identify, and easy to fix. Schneider. "Michael D. Ober" wrote in message news:uq*************@TK2MSFTNGP15.phx.gbl... Regardless of Option Explicit and Option Strict settings on a brand new form with a single button, I get the error "Access of shared member, constant member, enum member or nested type through an instance; qualifying expression will not be evaluated." on your code sample. VS 2005 Standard RTM. Mike. "m.posseth" wrote in message news:ev**************@TK2MSFTNGP14.phx.gbl... Michael i use the release version of Visual studio 2005 ( professional edition ) Public Class Form1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim ClassConst As String = XMyClass.ConstantString MsgBox(ClassConst) Dim myObj = New XMyClass ''''''''''''' Error is on this line ClassConst = myObj.ConstantString MsgBox(ClassConst) End Sub End Class Class XMyClass Public Const ConstantString = "Some Constant String" End Class this works without anny problems on my dev computer ( no warnings ) regards Michel Posseth [MCP] "Michael D. Ober" wrote in message news:uj*************@TK2MSFTNGP14.phx.gbl... Is there any way to create a constant in a class that can be used both with an instantiated object and without. For example: dim ClassConst as string = myClass.ConstantString dim myObj = new MyClass ClassConst = myObj.ConstantString Inside the class MyClass Class MyClass public const ConstantString = "Some Constant String" End Class In Beta 2, ConstantString was available in either of the above cases without complaint. In the RTM version, I can't do both. I don't want to turn off the warning as doing so may actually introduce another bug in my code later because I didn't see the warning. Thanks, Mike. Dec 8 '05 #12

 P: n/a "schneider" schrieb: Yes, this is a change in the VB.NET language and you will be force to change it. No! It's a warning which can be disabled. C#, and other languages have always done it this way. VB is not C#. The keyword is called 'Shared' in VB.NET. Shared members are /shared/ between /all/ instances of a class. They belong to all instances and thus are accessible on instance variables. -- M S Herfried K. Wagner M V P V B Dec 8 '05 #13

 P: n/a Mike, \\\ Public Class myConstantClass Private Shared mValue As String = "WhatEverConstantString" Public Shared ReadOnly Property ConstantString() As String Get Return mValue End Get End Property End Class /// I hope this helps, Cor Dec 8 '05 #14

 P: n/a "Cor Ligthert [MVP]" schrieb: \\\ Public Class myConstantClass Private Shared mValue As String = "WhatEverConstantString" Public Shared ReadOnly Property ConstantString() As String Get Return mValue End Get End Property End Class /// I doubt that this will solve the OP's problem, which is the same in both cases, regardless if you are using a constant or a read-only property: A shared member is accessed through a variable of the class' type. -- M S Herfried K. Wagner M V P V B Dec 8 '05 #15

 P: n/a i have the idea that this is not what the TS wants and Cor why not Public Class myConstantClass Public Shared ReadOnly Property ConstantString() As String Get Return "WhatEverConstantString" End Get End Property End Class And indeed it turned out that my IDE had two warning options off so with this code Public Class Form1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim ClassConst As String = XMyClass.ConstantString MsgBox(ClassConst) Dim myObj As New XMyClass ClassConst = myObj.ConstantString MsgBox(ClassConst) End Sub End Class Class XMyClass Public Const ConstantString As String = "Some Constant String" End Class i see a nag under this line myObj.ConstantString i think the best solution would be to declare all these sort constants as readonly propertys with the shared keyword regards Michel posseth "Herfried K. Wagner [MVP]" wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... "Cor Ligthert [MVP]" schrieb: \\\ Public Class myConstantClass Private Shared mValue As String = "WhatEverConstantString" Public Shared ReadOnly Property ConstantString() As String Get Return mValue End Get End Property End Class /// I doubt that this will solve the OP's problem, which is the same in both cases, regardless if you are using a constant or a read-only property: A shared member is accessed through a variable of the class' type. -- M S Herfried K. Wagner M V P V B Dec 8 '05 #16

 P: n/a Herfried K. Wagner [MVP] wrote: Sorry Herfried, I have to take issue with you on this one I'm afraid "schneider" schrieb: Yes, this is a change in the VB.NET language and you will be force to change it. No! It's a warning which can be disabled. It's a warning that you're doing something wrong. C#, and other languages have always done it this way. VB is not C#. The keyword is called 'Shared' in VB.NET. There's a keyword called 'AddressOf' as well, but it doesn't get the address of anything. Shared members are /shared/ between /all/ instances of a class. They belong to all instances No, conceptually they belong to the *class*, not to any instance. and thus are accessible on instance variables. Them being accessible on instance variables was to my mind a language design error. Note that Shared items can be accessed even when a class *cannot* have instances - how can they then be said to 'belong to all instances' ? This new compiler warning is a good thing. -- Larry Lard Replies to group please Dec 8 '05 #17

 P: n/a "Larry Lard" schrieb: Sorry Herfried, I have to take issue with you on this one I'm afraid No problem. I like those "issues" ;-). > Yes, this is a change in the VB.NET language and you will be force to > change > it. No! It's a warning which can be disabled. It's a warning that you're doing something wrong. Well, it's an error if you configure the compiler to raise a complile-time error. And it's not problem if you configure the compiler to take no action at all. Although I have never accessed a shared member through an instance variable, I don't think that this is such a big problem. Maybe it's a problem for C# developers who come to VB. > C#, and other languages have always done it this way. VB is not C#. The keyword is called 'Shared' in VB.NET. There's a keyword called 'AddressOf' as well, but it doesn't get the address of anything. Well, that's another story. I remember Bruce McKinney first complaining about the existance of 'AddressOf' in VB.NET some years ago. I believe that a keyword is important, regardless of its name. Personally, I do not like the C# solution. Shared members are /shared/ between /all/ instances of a class. They belong to all instances No, conceptually they belong to the *class*, not to any instance. As already said, this doesn't apply to VB.NET. It's an implementation detail that they do not belong to a certain instance. "Visual Basic Language Specification -- 9.2.4 'Shared' Methods": | The 'Shared' modifier indicates a method is a /shared method/. | A shared method does not operate on a specific instance of a type | and may be invoked directly from a type rather than through a particular | instance of a type. It is valid, however, to use an instance to qualify | a shared method. "Visual Basic Language Concepts -- Shared Members": | Shared members are properties, procedures, and fields that are shared | by all instances of a class. "Visual Basic Language Reference -- 'Shared'": | The 'Shared' keyword indicates that one or more declared programming | elements are shared. Shared elements are not associated with a specific | instance of a class or structure. You can access them by qualifying them | either with the class or structure name, or with the variable name of a | specific instance of the class or structure. .... and thus are accessible on instance variables. Them being accessible on instance variables was to my mind a language design error. Note that Shared items can be accessed even when a class *cannot* have instances - how can they then be said to 'belong to all instances' ? They belong to the set of instances, which can be empty. This new compiler warning is a good thing. Well, I'm glad that it can be disabled... -- M S Herfried K. Wagner M V P V B Dec 8 '05 #18

 P: n/a Michael and Herfried, Just because my idea was, what is the benefit of a constant in 2005. In my opinion is this much nicer to get the same result. I was sure somebody would give a reaction on my sample. Cor Dec 9 '05 #19

 P: n/a "Herfried K. Wagner [MVP]" Probably we don't disagree if you have read what I write 3 or 4 times. VB is not C#. The keyword is called 'Shared' in VB.NET. Shared members are /shared/ between /all/ instances of a class. They belong to all instances and thus are accessible on instance variables. And the normal way is to place those in the first (0) stack of the program. I don't know how Net does it, however I assume the same or otherwise the method will result in the same. In my opinion it is what is called a shared class no class but a module. That in the C world people started to call this a class because of the fact that it was in almost the same way described does not mean that it is a class. (Despite that in my opinion all dificult ways in describing are choosen to avoid to tell this) I see not why it can than not used as a real class and automaticly take no care of the "Shared" keyword.. That in the German language "See" is in English "Lake" what in Dutch "Meer" while in French "Mer" is the same as in English "See" does not say anything about the used object at all. Just my thought, Cor Dec 9 '05 #20

 P: n/a Hi Cor , Maybe my reponse should have been more clear i think the best solution would be to declare all these sort constants as readonly propertys with the shared keyword cause wasn`t this wat you showed , however it looks like this is a workaround for the TS ( it is not exactly what he wants ) i was only wondering why you did not do this ( maybe i am missing a obvious reasson ) Public Class myConstantClass Public Shared ReadOnly Property ConstantString() As String Get Return "WhatEverConstantString" End Get End Property End Class regards Michel Posseth "Cor Ligthert [MVP]" wrote in message news:uL**************@TK2MSFTNGP14.phx.gbl... Michael and Herfried, Just because my idea was, what is the benefit of a constant in 2005. In my opinion is this much nicer to get the same result. I was sure somebody would give a reaction on my sample. Cor Dec 9 '05 #21

 P: n/a Ah, Sorry Michel, I see it now. I was hoping on a long discussion about saving one bit by doing it not this way. Of course just use the string is even better. :-))) Cor Dec 9 '05 #22

 P: n/a doh, again a possibility for misunderstanding I was hoping on a long discussion about saving one bit by doing it not this way. I was hoping on a long discussion about saving one bit by doing it by not using a read only property but a constant :-) Cor Dec 9 '05 #23

 P: n/a Cor, "Cor Ligthert [MVP]" schrieb: VB is not C#. The keyword is called 'Shared' in VB.NET. Shared members are /shared/ between /all/ instances of a class. They belong to all instances and thus are accessible on instance variables. [...] In my opinion it is what is called a shared class no class but a module. I agree. I have never liked the idea of "static classes" as available in C#. Static classes are semantically nonsense. They are no classes, and they should not be types. They are simply a grouping mechanism which should be as lightweight as namespaces are. To me it seems that some OOP purists simply didn't want to use a semantically more correct term such as module, unit, or group because it's not an OO term. That in the C world people started to call this a class because of the fact that it was in almost the same way described does not mean that it is a class. (Despite that in my opinion all dificult ways in describing are choosen to avoid to tell this) Exactly true! -- M S Herfried K. Wagner M V P V B Dec 9 '05 #24

 P: n/a "Cor Ligthert [MVP]" schrieb: Just because my idea was, what is the benefit of a constant in 2005. In my opinion is this much nicer to get the same result. I was sure somebody would give a reaction on my sample. Read-only properties and constants are treated differently by the compiler. While constants' values are embedded into assemblies using your library at compile-time, the value of read-only properties is determined at runtime. Thus it's not necessary to recompile dependent libraries when changing the return value of a read-only property opposed to a constants. I use public constants in very few cases only. Often constants are an implementation detail only. -- M S Herfried K. Wagner M V P V B Dec 9 '05 #25

 P: n/a Herfried, Read-only properties and constants are treated differently by the compiler. While constants' values are embedded into assemblies using your library at compile-time, the value of read-only properties is determined at runtime. Thus it's not necessary to recompile dependent libraries when changing the return value of a read-only property opposed to a constants. I use public constants in very few cases only. Often constants are an implementation detail only. Exact this answer was what I expected and than I find a read-only property something nicer. However are you sure of that assembly part, I did not try it yet, however I am almost sure that in the way Michel made it, (forgive me my mistake) will result in the same constant in the ILS. Those strings are immutable you know? :-) Cor Dec 9 '05 #26

 P: n/a Beta 2 worked - a public constant could be accessed via the Class Name or via an Object reference. Mike. "schneider" wrote in message news:uM***************@TK2MSFTNGP15.phx.gbl... Yes, this is a change in the VB.NET language and you will be force to change it. C#, and other languages have always done it this way. I think for the sake of better code clarity it was a good move, also this does not require any more work from the developer. It's is now obvious if a line of code is calling a shared/static or instance specific method. It can be a pain when moving code from 1.0 to 2.0, but at least the error is easy to identify, and easy to fix. Schneider. "Michael D. Ober" wrote in message news:uq*************@TK2MSFTNGP15.phx.gbl... Regardless of Option Explicit and Option Strict settings on a brand new form with a single button, I get the error "Access of shared member, constant member, enum member or nested type through an instance; qualifying expression will not be evaluated." on your code sample. VS 2005 Standard RTM. Mike. "m.posseth" wrote in message news:ev**************@TK2MSFTNGP14.phx.gbl... Michael i use the release version of Visual studio 2005 ( professional edition ) Public Class Form1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim ClassConst As String = XMyClass.ConstantString MsgBox(ClassConst) Dim myObj = New XMyClass ''''''''''''' Error is on this line ClassConst = myObj.ConstantString MsgBox(ClassConst) End Sub End Class Class XMyClass Public Const ConstantString = "Some Constant String" End Class this works without anny problems on my dev computer ( no warnings ) regards Michel Posseth [MCP] "Michael D. Ober" wrote in message news:uj*************@TK2MSFTNGP14.phx.gbl... > Is there any way to create a constant in a class that can be used both > with > an instantiated object and without. For example: > > dim ClassConst as string = myClass.ConstantString > > dim myObj = new MyClass > ClassConst = myObj.ConstantString > > Inside the class MyClass > > Class MyClass > > public const ConstantString = "Some Constant String" > > End Class > > In Beta 2, ConstantString was available in either of the above cases > without > complaint. In the RTM version, I can't do both. I don't want to turn off > the warning as doing so may actually introduce another bug in my code > later > because I didn't see the warning. > > Thanks, > Mike. > > > Dec 9 '05 #27

 P: n/a I'm working with the interface to a legacy VMS system. Data records are returned in a string of format "FileChannel & vbNL & RecordData". This interface can return multiple records per call and each record can potentially be from a different channel. I need to be able to do the following: dim basechannel as somechannel ' SomeChannel is an object that is created based on the VMS RMS File definition, which I have access to and have a VB 6 cross compiler that generates the .NET VB2005 class object. (RMS allows overlapping field layouts) dim haveObjType2 as boolean = false for each s as string in LegacyInterface.GetData(, , ) dim channel as string = LegacyInterface.GetChannel(s) if ChannelType1.Channel = channel and haveObjType2 then ' Process ChannelType1 data only if ChannelType2 data has been found dim objType1 as new ChannelType1(s) ' Do something with objType1 case ChannelType2.Channel: dim objType2 as new ChannelType2(s) haveObjType2 = true ' Do something with it LegacyInterface.Update(objType2.Channel, objType2.buffer) case ChannelType3.Channel ' not needed either end select next s Why go through the overhead of creating non-required types. Also, in some cases, I may have to create objType1 depending on what is returned in objType2. I didn't design the underlying RMS database structure - it's not even 1st Normal form. Note that I ALWAYS use Option Strict On and Option Explicit On. I've had too many experiences where VB 6 didn't pick up a type cast failure at compile time and the application didn't work as expected. I want the compiler to tell me when there is a type casting problem. Here's a sample of the output of the RMS cross compiler: Option Explicit On Option Strict On Option Compare Text Public Class COMMENT4 ' Created with DefToCls v.4.1.10 ' Created on #11/11/2005 1:58:33 PM# ' VMS Source File has VBTags ' VMS Source File Header for \\JAGUAR\VMSDEVHOME\def\4COMMENT.DEF ' ! ' !TITLE: WA$SOURCE:4COMMENT.DEF ' ! ' !22-DEC-95 NSB CREATED NEW DEF ' !31-MAY-96 MVD CHANGE COMMENT_TYPE TO 3 CHAR ' !01-AUG-96 MVD CHANGE COMMENT_TYPE TO 5 CHAR AND MOVE TO KEY ' !07-AUG-96 MVD CHANGE DATE TO 10 CHARACTERS ' !4-MAR-97 NSB ADDED SUB_TYPES VARIANT AND DOCUMENTAION ' !16-JAN-99 NSB MODIFIED TO THE FINAL FORMAT ' ! ' ! THE NEW FORMAT ' ! ' ! VB_CHANNEL=COMMENT ' ! VB_RECORD_LENGTH=105 ' ! ' RECORD TYPE$_4COMMENT Public Const RecSize as Integer = 105 Private buffer As String Public Sub New() init End Sub Public Sub New(ByVal value As String) buffer = LSet(value, 105) End Sub Public Sub init() buffer = Space(105) End Sub ' These two functions are to keep the code later simpler to read Private Function fetch(ByVal start As Integer, ByVal chars As Integer) As String fetch = Mid(buffer, start, chars) End Function Private Sub putch(ByRef s As String, ByVal start As Integer, ByVal chars As Integer) Mid(buffer, start, chars) = LSet(s, chars) End Sub ' VAX Channels Public Const Channel as String = "COMMENT" 'DBServer Key Fields Public Const VBKey_KEY0 as String = "KEY0" 'Key ACCT_NUM not in .OPN file Public Const VBKey_ACCT_NUM as String = "ACCT_NUM" 'DBServer Data Fields Public Property BUF() as String Get Return fetch(1, 105) End Get Set(ByVal value as string) putch(value, 1, 105) End Set End Property Public Property KEY0() as String Get Return fetch(1, 19) End Get Set(ByVal value as string) putch(value, 1, 19) End Set End Property ' Multiple fields cut out - they follow the same code sequence as BUF and KEY0 'Formatted Print Property Public Shadows ReadOnly Property ToString(Optional ByVal prefix As String = "", Optional ByVal indent As Boolean = False) As String Get Dim IndentChar As String If indent Then IndentChar = vbTab Else IndentChar = "" Dim fp As String = "" fp &= IndentChar & "KEY0: '" & KEY0 & "'" & vbNewLine fp &= IndentChar & "OFFICE: '" & OFFICE & "'" & vbNewLine fp &= IndentChar & "ACCT_NUM: '" & ACCT_NUM & "'" & vbNewLine fp &= IndentChar & "COMMENT_TYPE: '" & COMMENT_TYPE & "'" & vbNewLine fp &= IndentChar & "PRODUCT: '" & PRODUCT & "'" & vbNewLine fp &= IndentChar & "T_IME: '" & T_IME & "'" & vbNewLine fp &= IndentChar & "D_ATE: '" & D_ATE & "'" & vbNewLine fp &= IndentChar & "COLLECTOR: '" & COLLECTOR & "'" & vbNewLine fp &= IndentChar & "CMMT: '" & CMMT & "'" & vbNewLine prefix = Trim\$(prefix) If prefix <> "" Then Dim lines() As String = Split(fp, vbNewLine) fp = "" For i As Integer = LBound(lines) To UBound(lines) If Left(lines(i), Len(IndentChar) + Len(prefix)) = (IndentChar & prefix) Then fp &= lines(i) & vbNewLine Next i End If Return fp End Get End Property Public Function Clone() As COMMENT4 Return New COMMENT4(buffer) End Function End Class Mike. "Marina" wrote in message news:uP**************@TK2MSFTNGP14.phx.gbl... If this is about a constant, how does that help ensure you are working with the right class? There is no inheritance issue here. "Michael D. Ober" wrote in message news:OI**************@TK2MSFTNGP10.phx.gbl... There are times when accessing through an instance makes more sense - it ensures I'm working with the correct object/class type. Other times, accessing through the class type make more sense - when trying to verify class type of an unknown string representation of the object. In the latter case, class type verification can then be done without the overhead of creating an object that then gets immediately thrown away. Mike Ober. "Herfried K. Wagner [MVP]" wrote in message news:OA**************@TK2MSFTNGP15.phx.gbl... Marina, "Marina" schrieb: > If it's a constant, why not always reference it through the type name? > What do you gain by accessing it through an instance? What do you loose by accessing it through an instance? -- M S Herfried K. Wagner M V P V B URL:http://classicvb.org/petition/ Dec 9 '05 #28

 P: n/a It depends on the optimizer. A read only property that returns a constant string should be caught and converted to a constant at compile time. A read only property that computes it's result based on internal object state cannot be optimized into a single return value. Mike Ober. "Cor Ligthert [MVP]" wrote in message news:%2****************@TK2MSFTNGP14.phx.gbl... Herfried, Read-only properties and constants are treated differently by the compiler. While constants' values are embedded into assemblies using your library at compile-time, the value of read-only properties is determined at runtime. Thus it's not necessary to recompile dependent libraries when changing the return value of a read-only property opposed to a constants. I use public constants in very few cases only. Often constants are an implementation detail only. Exact this answer was what I expected and than I find a read-only property something nicer. However are you sure of that assembly part, I did not try it yet, however I am almost sure that in the way Michel made it, (forgive me my mistake) will result in the same constant in the ILS. Those strings are immutable you know? :-) Cor Dec 9 '05 #29

 P: n/a "Michael D. Ober" schrieb: It depends on the optimizer. A read only property that returns a constant string should be caught and converted to a constant at compile time. A read only property that computes it's result based on internal object state cannot be optimized into a single return value. I have to disagree. Converting it to a constant at compile time for the reasons described in another reply (stronger dependency between multiple components). -- M S Herfried K. Wagner M V P V B Dec 9 '05 #30

### This discussion thread is closed

Replies have been disabled for this discussion.

### Similar topics

Browse more Visual Basic .NET Questions on Bytes