Results 1 to 27 of 27

Thread: Some unreasonable restrictions in VB6

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Aug 2020
    Posts
    845

    Some unreasonable restrictions in VB6

    In a class, we can define a Public property in a simple way, for example:
    MyClass1.cls
    Code:
    Public Name As String
    However, in a class, we cannot define a Friend property in a simple way, for example:
    Code:
    Friend Name As String
    Also, we cannot define a Public constant in a VB6 class, for example:
    Code:
    Public Const DEFAULT_STRING As String = "Hello World"
    Why is this?

  2. #2
    Frenzied Member PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Newport, UK
    Posts
    1,887

    Re: Some unreasonable restrictions in VB6

    Is that a public property or just a public variable (field?) instead?

    Doesn't a property have a specific property definition? If so can they not be declared Friend?

  3. #3
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    4,094

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by SearchingDataOnly View Post
    Why is this?
    Both shortcomings of the compiler (that TB will probably fix as these are low-hanging fruits).

    Friend variables on a class is a clear omission.

    For the public constants it's more complicated as typelibs cannot contain constants on interfaces or coclasses (only in so called "modules" but these are not produced by VB6 compiler at all).

    But for *private* classes it's completely possible to expose public constants *and* enums in current project scope only -- alas they didn't put the mental effort to implement it.

    cheers,
    </wqw>

  4. #4
    Banned
    Join Date
    Nov 2011
    Posts
    7,803

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by PlausiblyDamp View Post
    Is that a public property or just a public variable (field?) instead?
    Yes it's a field. There is no short-hand way to define a property like there is in C# and VB.Net. You need the full Get/Let/Set boilerplate in VB6.

  5. #5
    PowerPoster
    Join Date
    Jun 2013
    Posts
    6,171

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Niya View Post
    Yes it's a field.
    No, it's a Property.

    Quote Originally Posted by Niya View Post
    There is no short-hand way to define a property like there is in C# and VB.Net. You need the full Get/Let/Set boilerplate in VB6.
    No, ...

    Public L As Long, S As String, D As Date

    ...is defining 3 full Get/Let Class-Properties (as Method-Calls, not "Field-Variables").

    Olaf

  6. #6
    PowerPoster Zvoni's Avatar
    Join Date
    Sep 2012
    Location
    To the moon and then left
    Posts
    3,320

    Re: Some unreasonable restrictions in VB6

    The whole "Friend"-Thing in vb6 is one mess.
    any serious OOP-Language has (at least) three scope modifiers for Class-Members:
    Private, Protected (that's Friend in vb6) and Public

    Purpose: Restricting access to those members, especially in regards to inheritance
    Private = Like the word says. It's private for this Class/Instance. Keep your nose out of it.
    Protected = OK, me and my children can access it. For everyone else: Not your business
    Public = Ah well. That's my public face. Use it.

    Depending on the Language-Implementation, Protected can be accessible as long as the "Child" is within the same File/Unit (as known from Pascal/Delphi) as its parent. Otherwise it's private

    Since vb6 doesn't support inheritance and/or multiple classes per File/module, Friend is basically Public for the Project.

    e.g.: You write an ActiveX-DLL in vb6.
    You have some Classes there with Private, Friend and Public Members
    Private are Private to that class
    Public are accessible from outside that DLL
    Friend are NOT accessible from outside that DLL, but are accessible (like Public members) from inside that dll from anywhere

    Bottom Line: One big Mess

    I wouldn't bother with it
    One System to rule them all, One Code to find them,
    One IDE to bring them all, and to the Framework bind them,
    in the Land of Redmond, where the Windows lie
    ---------------------------------------------------------------------------------
    People call me crazy because i'm jumping out of perfectly fine airplanes.
    ---------------------------------------------------------------------------------
    Code is like a joke: If you have to explain it, it's bad

  7. #7
    Banned
    Join Date
    Nov 2011
    Posts
    7,803

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Schmidt View Post
    No, it's a Property.



    No, ...

    Public L As Long, S As String, D As Date

    ...is defining 3 full Get/Let Class-Properties (as Method-Calls, not "Field-Variables").

    Olaf
    I stand corrected

    Quote Originally Posted by Zvoni View Post

    Bottom Line: One big Mess

    I wouldn't bother with it
    You really think so? I get a lot of value out of Friend in .Net since I have a tendency to put non-UI helper classes and methods into a class library(ActiveX DLL in VB6 terms) that is referenced by the project that has the UI. Friend allows me to hide all the excess clutter that is unneeded by the external project using the library while allowing me to access it fully from anywhere within library itself.

    I think whether one likes or hates Friend this depends entirely on how you approach programming from an architectural standpoint. If you're someone that just dumps everything into a single EXE, you're not going to appreciate Friend. But if you're someone that likes to spread out your programs over one or more DLLs where each is responsible for a specific set of concerns, you will really learn to love the Friend access modifier. I fall into the second category. I despise monolithic designs and as such I tend toward breaking up an application into multiple components.
    Last edited by Niya; Jul 4th, 2022 at 02:04 AM.

  8. #8

    Thread Starter
    Fanatic Member
    Join Date
    Aug 2020
    Posts
    845

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by PlausiblyDamp View Post
    Is that a public property or just a public variable (field?) instead?
    Quote Originally Posted by Niya View Post
    Yes it's a field. There is no short-hand way to define a property like there is in C# and VB.Net. You need the full Get/Let/Set boilerplate in VB6.
    Quote Originally Posted by Niya View Post
    I stand corrected
    As Olaf said, "Public Name As String" represents a Get/Let property, that is, "Public Name As String" is shorthand for Get/Let property.
    Code:
    Public Property Get Name() As String
        Name = m_sName
    End Property
    
    Public Property Let Name(Value As String)
        m_sName = Value
    End Property
    Last edited by SearchingDataOnly; Jul 4th, 2022 at 03:10 AM.

  9. #9

    Thread Starter
    Fanatic Member
    Join Date
    Aug 2020
    Posts
    845

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by wqweto View Post
    Both shortcomings of the compiler (that TB will probably fix as these are low-hanging fruits).

    Friend variables on a class is a clear omission.

    For the public constants it's more complicated as typelibs cannot contain constants on interfaces or coclasses (only in so called "modules" but these are not produced by VB6 compiler at all).

    But for *private* classes it's completely possible to expose public constants *and* enums in current project scope only -- alas they didn't put the mental effort to implement it.

    cheers,
    </wqw>
    I see, thank you, wqweto.

  10. #10

    Thread Starter
    Fanatic Member
    Join Date
    Aug 2020
    Posts
    845

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Schmidt View Post
    No, it's a Property.



    No, ...

    Public L As Long, S As String, D As Date

    ...is defining 3 full Get/Let Class-Properties (as Method-Calls, not "Field-Variables").

    Olaf
    Yes, you are right. Thank you, Olaf.

  11. #11

    Thread Starter
    Fanatic Member
    Join Date
    Aug 2020
    Posts
    845

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Zvoni View Post
    The whole "Friend"-Thing in vb6 is one mess.
    any serious OOP-Language has (at least) three scope modifiers for Class-Members:
    Private, Protected (that's Friend in vb6) and Public

    Purpose: Restricting access to those members, especially in regards to inheritance
    Private = Like the word says. It's private for this Class/Instance. Keep your nose out of it.
    Protected = OK, me and my children can access it. For everyone else: Not your business
    Public = Ah well. That's my public face. Use it.

    Depending on the Language-Implementation, Protected can be accessible as long as the "Child" is within the same File/Unit (as known from Pascal/Delphi) as its parent. Otherwise it's private

    Since vb6 doesn't support inheritance and/or multiple classes per File/module, Friend is basically Public for the Project.

    e.g.: You write an ActiveX-DLL in vb6.
    You have some Classes there with Private, Friend and Public Members
    Private are Private to that class
    Public are accessible from outside that DLL
    Friend are NOT accessible from outside that DLL, but are accessible (like Public members) from inside that dll from anywhere

    Bottom Line: One big Mess

    I wouldn't bother with it
    There is no internal modifier like C# in VB6, so the Friend modifier in VB6 is very important, especially for UDT parameters.

  12. #12
    PowerPoster Zvoni's Avatar
    Join Date
    Sep 2012
    Location
    To the moon and then left
    Posts
    3,320

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Niya View Post
    I stand corrected



    You really think so? I get a lot of value out of Friend in .Net since I have a tendency to put non-UI helper classes and methods into a class library(ActiveX DLL in VB6 terms) that is referenced by the project that has the UI. Friend allows me to hide all the excess clutter that is unneeded by the external project using the library while allowing me to access it fully from anywhere within library itself.

    I think whether one likes or hates Friend this depends entirely on how you approach programming from an architectural standpoint. If you're someone that just dumps everything into a single EXE, you're not going to appreciate Friend. But if you're someone that likes to spread out your programs over one or more DLLs where each is responsible for a specific set of concerns, you will really learn to love the Friend access modifier. I fall into the second category. I despise monolithic designs and as such I tend toward breaking up an application into multiple components.
    Niya, i think you misunderstood.
    Yes, i also use "Protected" in FreePascal a lot, exactly for the same reasons as you.
    My answer was specifically for vb6 and its "Friend"-mechanism

    Quote Originally Posted by SearchingDataOnly View Post
    There is no internal modifier like C# in VB6, so the Friend modifier in VB6 is very important, especially for UDT parameters.
    See above my answer to Niya.
    Additionally: IMO, the "Friend"-Modifier only makes sense when writing an ActiveX-DLL/EXE in VB6, since a "Friend"-Member is still public for all others within the (DLL-) Project!
    "Friend" only gets a meaning if you access it from Outside (e.g. A "client" referencing your ActiveX-DLL/EXE).

    A "classic" for Protected (Friend) are Getters/Setters for Properties, Like in FreePascal
    Code:
    Type
        TMyClass = Class
            Private
                fSomeInteger:Integer;
            Protected
                Function GetSomeInteger:Integer;
                Procedure SetSomeInteger(AnInteger:Integer);
            Public
                Property SomeInteger:Integer Read GetSomeInteger Write SetSomeInteger;
    
    Function TMyClass.GetSomeInteger:Integer;
    Begin
        Result:=fSomeInteger;
    End;
    
    Procedure TMyClass.SetSomeInteger(AnInteger:Integer);
    Begin
        If AnInteger<=0 Then fSomeInteger:=-1 Else fSomeInteger:=AnInteger;
    End;
    Here, for any Code calling the Class from outside the Unit, only the Property "SomeInteger" is visible.
    For any code from within the Unit, the Getter/Setter is visible

    That's the "mess" in vb6: In Freepascal (and probably in other modern languages) the "visible" scope for Protected/Friend is the Unit/Module. In vb6 it's the Project!! Not the Class-module itself
    Last edited by Zvoni; Jul 4th, 2022 at 03:41 AM.
    One System to rule them all, One Code to find them,
    One IDE to bring them all, and to the Framework bind them,
    in the Land of Redmond, where the Windows lie
    ---------------------------------------------------------------------------------
    People call me crazy because i'm jumping out of perfectly fine airplanes.
    ---------------------------------------------------------------------------------
    Code is like a joke: If you have to explain it, it's bad

  13. #13
    Banned
    Join Date
    Nov 2011
    Posts
    7,803

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Zvoni View Post
    Niya, i think you misunderstood.
    Yes, i also use "Protected" in FreePascal a lot, exactly for the same reasons as you.
    My answer was specifically for vb6 and its "Friend"-mechanism
    Friend in VB6 is about the same as Friend in VB.Net in that it allows you to limit types and methods to project in question(ActiveX DLL in VB6 and class library in .Net). Even in VB6 I think it's a great thing to have if you're like me and tend to obsess about avoiding monolithic designs.

    I'm curious, what does Protected do in FreePascal? In C/C#/C++/VB.Net it's exactly like Private except it allows access to members by their subclasses in an inheritance chain.

  14. #14
    PowerPoster Zvoni's Avatar
    Join Date
    Sep 2012
    Location
    To the moon and then left
    Posts
    3,320

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Niya View Post
    I'm curious, what does Protected do in FreePascal? In C/C#/C++/VB.Net it's exactly like Private except it allows access to members by their subclasses in an inheritance chain.
    It's the same.
    https://www.freepascal.org/docs-html/ref/refse34.html
    5.7 Visibility

    For objects, three visibility specifiers exist: private, protected and public. If a visibility specifier is not specified, public is assumed. Both methods and fields can be hidden from a programmer by putting them in a private section. The exact visibility rule is as follows:

    Private
    All fields and methods that are in a private block, can only be accessed in the module (i. e. unit or program) that contains the object definition. They can be accessed from inside the object’s methods or from outside them e. g. from other objects’ methods, or global functions.
    Protected
    Is the same as Private, except that the members of a Protected section are also accessible to descendent types, even if they are implemented in other modules.
    Public
    fields and methods are always accessible, from everywhere. Fields and methods in a public section behave as though they were part of an ordinary record type.
    And i also stand corrected. The visibility for Protected is not the Unit, but the class itself
    Friend in VB6 is about the same as Friend in VB.Net in that it allows you to limit types and methods to project in question(ActiveX DLL in VB6 and class library in .Net). Even in VB6 I think it's a great thing to have if you're like me and tend to obsess about avoiding monolithic designs.
    No it's not the same, IMO.
    In vb6, I can have multiple Classes within a Project, that don't have anything to do with each other (since vb6 doesn't have inheritance), but within that project i can call any Friend-Member of any of those classes from anywhere within that Project.
    In Freepascal i cannot call a protected (Friend) Member of a Class, if my calling code is not a "child" of that class. Within one and the same Project
    Code:
    Unit UMyClass;
    Type
        TMyClass = Class
            Private
                fSomeInteger:Integer;
            Protected
                Function GetSomeInteger:Integer;
                Procedure SetSomeInteger(AnInteger:Integer);
            Public
                Property SomeInteger:Integer Read GetSomeInteger Write SetSomeInteger;
    
    
    Function TMyClass.GetSomeInteger:Integer;
    Begin
        Result:=fSomeInteger;
    End;
    
    Procedure TMyClass.SetSomeInteger(AnInteger:Integer);
    Begin
        If AnInteger<=0 Then fSomeInteger:=-1 Else fSomeInteger:=AnInteger;
    End;
    
    Unit UMyClass2;
    Uses UMyClass;
    Type
        TMyClass2 = Class
            Public 
                Procedure DoSomething;
    
    
    Procedure TMyClass2.DoSomething;
    Var 
      MyClass:TMyClass;
    Begin
        MyClass:=TMyClass.Create;
        MyClass.SetSomeInteger(42);  //--> Compilation Fails!!
    End;
    
    Unit UMyClass3;
    Uses UMyClass;
    Type
       TMyClass3 = Class(TMyClass) //Inheritance!!
            Public
               Procedure DoSomething;
    
    Procedure TMyClass3.DoSomething;
    Begin
        Self.SetSomeInteger(42);  //--> Works!! "Self" is "This" in C++
    End;
    Last edited by Zvoni; Jul 4th, 2022 at 04:01 AM.
    One System to rule them all, One Code to find them,
    One IDE to bring them all, and to the Framework bind them,
    in the Land of Redmond, where the Windows lie
    ---------------------------------------------------------------------------------
    People call me crazy because i'm jumping out of perfectly fine airplanes.
    ---------------------------------------------------------------------------------
    Code is like a joke: If you have to explain it, it's bad

  15. #15
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    4,094

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Zvoni View Post
    That's the "mess" in vb6: In Freepascal (and probably in other modern languages) the "visible" scope for Protected/Friend is the Unit/Module. In vb6 it's the Project!! Not the Class-module itself
    It's pretty much the same. It's just that the namespaces in VB6 coincide with projects i.e. in a project you have only one namespace which is named exactly like your project.

    You cannot have multiple namespaces within a project so that friends can be scoped on a particular namespace, so friends gets scoped on the entire project in VB6 which is logical.

    It's not that different but still because it's not *exactly* like in C++ (nor in Pascal) it does *not* make it a mess. In VB6 it's just as weird as in C++ and Pascal for someone with different background (say Fortran or OCaml).

    cheers,
    </wqw>

  16. #16
    Banned
    Join Date
    Nov 2011
    Posts
    7,803

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Zvoni View Post
    Yea, that's exactly what we have in .Net. But we also have Friend(internal in C#) in addition to those. We also have some interesting combinations, Private Protected and Protected Friend in .Net. Private Protected is like protected except it you it denies access to the member from outside of the project when inheriting. Protected Friend allows project wide access to a member like plain old Friend but it also allows you to access the member outside of the project only from a type derived from the class containing the member(Friend internally, and Protected externally).

  17. #17
    Banned
    Join Date
    Nov 2011
    Posts
    7,803

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Zvoni View Post
    No it's not the same, IMO.
    In vb6, I can have multiple Classes within a Project, that don't have anything to do with each other (since vb6 doesn't have inheritance), but within that project i can call any Friend-Member of any of those classes from anywhere within that Project.
    In Freepascal i cannot call a protected (Friend) Member of a Class, if my calling code is not a "child" of that class. Within one and the same Project
    Ah I see what the issue is now. You're confusing Protected with Friend. These are two different access scopes. They are not synonymous. As you have rightly pointed out, there is no inheritance in VB6 so a Protected scope makes no sense but a Friend scope still makes sense in the language.

  18. #18

    Thread Starter
    Fanatic Member
    Join Date
    Aug 2020
    Posts
    845

    Re: Some unreasonable restrictions in VB6

    Hi Niya, I often see code like the following:
    Code:
    internal class MyClass {
        private int _size;
        private int _version;
    
        public Clone(MyClass obj) {
            this._size = obj._size;
            this._version = obj._version;
        }
    }
    Why does C# allow direct access to private members of an object? Closure?

  19. #19
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    4,094

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by SearchingDataOnly View Post
    Why does C# allow direct access to private members of an object?
    Only own class private members i.e. a method (private or not) in a class is able to access private members of the same class through a reference (of the same class).

    This is the reason why this._size works in first place -- this is a reference of the same class as the method's own class :-))

    Edit: So now you started cross-posting in multiple subforums here and annoy members of both ones -- not very clever. . .

    cheers,
    </wqw>

  20. #20
    Banned
    Join Date
    Nov 2011
    Posts
    7,803

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by wqweto View Post
    Only own class private members i.e. a method (private or not) in a class is able to access private members of the same class through a reference (of the same class).

    This is the reason why this._size works in first place -- this is a reference of the same class as the method's own class :-))
    Note that this isn't true of VB6 though.

    Quote Originally Posted by SearchingDataOnly View Post
    Hi Niya, I often see code like the following:
    Code:
    internal class MyClass {
        private int _size;
        private int _version;
    
        public Clone(MyClass obj) {
            this._size = obj._size;
            this._version = obj._version;
        }
    }

    Why does C# allow direct access to private members of an object?
    It is so by definition:-
    https://docs.microsoft.com/en-us/dot...ywords/private
    Private members are accessible only within the body of the class or the struct in which they are declared
    As long as you're accessing the instance of the same class from within the body of the class itself, it is allowed. There really is no sensible reason for this not to be the case and it eases some potential frustrations. For example, try writing a Clone method for a VB6 class module that doesn't allow you to set it's state through a public interface. You would be forced to expose it's internals when you may not necessarily want to.

    Quote Originally Posted by SearchingDataOnly View Post
    Closure?
    Nothing so exciting. Scoping rules within the same compilation unit(dll, exe etc) are really just as illusions. The compiler only pretends it cannot see private members and refuses to compile when you try to access them externally. The intellisense is also in on this conspiracy, opting to not list private members outside of the class. In other words, all it takes to implement private access modifiers is for the compiler to refuse to compile your code when you don't play along with it's pretense.

  21. #21

    Thread Starter
    Fanatic Member
    Join Date
    Aug 2020
    Posts
    845

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by wqweto View Post
    Only own class private members i.e. a method (private or not) in a class is able to access private members of the same class through a reference (of the same class).

    This is the reason why this._size works in first place -- this is a reference of the same class as the method's own class :-))
    Thanks for your reply, wqweto.

    Under normal circumstances, the access rights of the member variables of the class should refer to "the access rights of the member variables of the instance of the class at runtime", not the access rights in the code window. However, since the C# compiler and documentation really have to interpret it in its own way, we can only accept it. In contrast, VB6's approach is more scientific, but inconvenient and inflexible.

    Quote Originally Posted by wqweto View Post
    Edit: So now you started cross-posting in multiple subforums here and annoy members of both ones -- not very clever. . .
    There is a reason why the same question is being asked in different sub-forums. When this question was asked on the .NET forums, the question was purely a C# question. When this question was asked on the VB6 forum, it was a VB6 related question:

    (1) This question is in addition to the question in post#1, which makes a comparison of the access rights of class members in C# and VB6.

    (2) This question seems to indicate that VB6 does dynamic compilation in the code window, which doesn't seem to be the case for the C#-IDE (VisualStudio.NET).

    (3) This problem is the same as the one in post#1, causing a lot of trouble for my code conversion work (C# to VB6), and I want to find a good solution.
    Last edited by SearchingDataOnly; Jul 5th, 2022 at 08:44 AM.

  22. #22

    Thread Starter
    Fanatic Member
    Join Date
    Aug 2020
    Posts
    845

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by Niya View Post
    Note that this isn't true of VB6 though.

    It is so by definition:-
    https://docs.microsoft.com/en-us/dot...ywords/private

    As long as you're accessing the instance of the same class from within the body of the class itself, it is allowed. There really is no sensible reason for this not to be the case and it eases some potential frustrations. For example, try writing a Clone method for a VB6 class module that doesn't allow you to set it's state through a public interface. You would be forced to expose it's internals when you may not necessarily want to.
    Thank you, Niya. Yes, the C# approach is more convenient and flexible. But as in my reply above:

    Under normal circumstances, the access rights of the member variables of the class should refer to "the access rights of the member variables of the instance of the class at runtime", not the access rights in the code window. However, since the C# compiler and documentation really have to interpret it in its own way, we can only accept it. In contrast, VB6's approach is more scientific, but inconvenient and inflexible.

  23. #23
    Fanatic Member
    Join Date
    Jun 2015
    Posts
    742

    Re: Some unreasonable restrictions in VB6

    vb does not have private variables.

    Code:
    '--------------------  class1  ------------------------------------
    Private a As Long
    Private b As Long
    
    Sub showMe()
        MsgBox "a=" & Hex(a) & " b=" & Hex(b)
    End Sub
    
    Private Sub Class_Initialize()
        a = &H11223344
        b = &H55667788
    End Sub
    
    '-----------------------  form1  ---------------------------------------
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByVal pDest As Long, ByVal pSrc As Long, ByVal ByteLen As Long)
    
    Private Sub Form_Load()
        Dim c As New Class1
        c.showMe
        SetPrivateLng c, &H34, &HAABBCCDD
        SetPrivateLng c, &H38, &H99887766
        c.showMe
    End Sub
    
    Sub SetPrivateLng(obj As Object, offset As Long, value As Long)
        Dim o As Long
        o = ObjPtr(obj) + offset
        CopyMemory ByVal o, ByVal VarPtr(value), 4
    End Sub

  24. #24
    Frenzied Member PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Newport, UK
    Posts
    1,887

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by dz32 View Post
    vb does not have private variables.

    Code:
    '--------------------  class1  ------------------------------------
    Private a As Long
    Private b As Long
    
    Sub showMe()
        MsgBox "a=" & Hex(a) & " b=" & Hex(b)
    End Sub
    
    Private Sub Class_Initialize()
        a = &H11223344
        b = &H55667788
    End Sub
    
    '-----------------------  form1  ---------------------------------------
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByVal pDest As Long, ByVal pSrc As Long, ByVal ByteLen As Long)
    
    Private Sub Form_Load()
        Dim c As New Class1
        c.showMe
        SetPrivateLng c, &H34, &HAABBCCDD
        SetPrivateLng c, &H38, &H99887766
        c.showMe
    End Sub
    
    Sub SetPrivateLng(obj As Object, offset As Long, value As Long)
        Dim o As Long
        o = ObjPtr(obj) + offset
        CopyMemory ByVal o, ByVal VarPtr(value), 4
    End Sub
    That isn't proving that VB doesn't have private variables, it is proving that it is possible to change the contents of memory directly. Obviously if you know where in memory a variable is being held you can change the contents.

  25. #25
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    8,087

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by PlausiblyDamp View Post
    That isn't proving that VB doesn't have private variables, it is proving that it is possible to change the contents of memory directly. Obviously if you know where in memory a variable is being held you can change the contents.
    Yeah, I was thinking the same thing above. Basically, if we're willing to hack enough, we can change anything we like. But that just ignores the whole idea of scoping and lifetime. Niya talked about the compiler (and Intellisense) "conspiring" to make Private variables out of Friend variables. But, virtually by definition, that's what Private variables are.
    Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  26. #26
    Banned
    Join Date
    Nov 2011
    Posts
    7,803

    Re: Some unreasonable restrictions in VB6

    Quote Originally Posted by dz32 View Post
    vb does not have private variables.
    You can also hack the memory in .Net to do this. In addition to this, reflection can also be used to access private members in .Net. It's also possible to do these things in C and C++. This is why I said private members are really just illusions. Private members are only private because your tools like the compiler and IDE conspire to hide them from you when you try to access them outside of their proper scope.

  27. #27
    Fanatic Member
    Join Date
    Jun 2015
    Posts
    742

    Re: Some unreasonable restrictions in VB6

    All your vars are belong to us

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width