DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 3 FirstFirst 123
Results 31 to 45 of 45

Thread: compatibility: ActiveX controls versions

  1. #31
    L.J. Johnson Guest

    Re: compatibility: ActiveX controls versions

    Jim,

    > Just as Eduardo and L.J. said: bogus error messages that prevent
    > recompiling, and the only way to get around them is to not have any
    > Optionals in the public interface (seems they're OK when Private). This

    is
    > VB5 SP3: they probably did better in VB6...


    Yes, I'm puzzled by this. I've used them extensively in VB 5.0 (all SPs) and
    VB 6.0.

    --
    L.J. Johnson, Slightly Tilted Software
    Microsoft MVP (Visual Basic)
    LJJohnson@SlightlyTiltedSoftware.com or LJJohnson@mvps.org
    <http://www.SlightlyTiltedSoftware.com>
    Ask The NT Pro at <http://www.inquiry.com>




  2. #32
    Mark Alexander Bertenshaw Guest

    Re: compatibility: ActiveX controls versions

    Karl -

    I found one good explanation for this behaviour at Matthew Cromer's website
    (www.sdaconsulting.com, I think). He thinks that the Enum problem occurs as
    a result of the anomalous case-changing "ability" of Enum values. Just in
    case some haven't come across this, I'll explain: we all know that if you
    change the case of one or more characters in declarations of a variable,
    procedure, or type name, then all uses of this name are changed to match it.
    Changing the case of these uses will cause the operation to undo when you
    move away from it. All, except items in an Enum, where the change in case
    propagates back to the declaration - this is definitely a bug in VB5. And
    Matthew Cromer thinks that this may be enough to cause a change in interface
    declaration.

    Interestingly, I have just tried this in VB 6 SP3. It looks as if the fix
    is not to cause ANY change in the case of ANY enumeration type item.

    Add this to a module:


    Private Enum ETest
    FFdd
    FFee
    FFff
    End Enum

    Sub Summat
    Dim test as ETest

    test = FFdd

    End Sub


    Now change the case of "FFdd" in both the declaration and in "Summat", and
    you'll see nowt!

    --

    ---------------------------------------
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Prime Response
    Brentford
    UK
    "Karl E. Peterson" <karl@mvps.org> wrote in message
    news:39538b15@news.devx.com...
    > Hi Jim --
    >
    > > Just as Eduardo and L.J. said: bogus error messages that prevent
    > > recompiling, and the only way to get around them is to not have any
    > > Optionals in the public interface (seems they're OK when Private). This

    is
    > > VB5 SP3: they probably did better in VB6...

    >
    > Point of clarification -- LJ seemed as puzzled as I at the idea of

    Optionals causing
    > compatability problems?
    >
    > Anyway, this I just haven't seen. They did do a rebuild of one DLL that

    was causing
    > some issues with compatability in VB5/SP3. (You had to actually ask for

    it, to get
    > it.) But the issue there was with Enums, if I recall. Is this doc'd

    anywhere in the
    > KB, or just "net.legend"?
    >
    > Thanks... Karl
    > --
    > http://www.mvps.org/vb
    >
    >
    >




  3. #33
    Mark Alexander Bertenshaw Guest

    Re: compatibility: ActiveX controls versions

    Karl -

    I found one good explanation for this behaviour at Matthew Cromer's website
    (www.sdaconsulting.com, I think). He thinks that the Enum problem occurs as
    a result of the anomalous case-changing "ability" of Enum values. Just in
    case some haven't come across this, I'll explain: we all know that if you
    change the case of one or more characters in declarations of a variable,
    procedure, or type name, then all uses of this name are changed to match it.
    Changing the case of these uses will cause the operation to undo when you
    move away from it. All, except items in an Enum, where the change in case
    propagates back to the declaration - this is definitely a bug in VB5. And
    Matthew Cromer thinks that this may be enough to cause a change in interface
    declaration.

    Interestingly, I have just tried this in VB 6 SP3. It looks as if the fix
    is not to cause ANY change in the case of ANY enumeration type item.

    Add this to a module:


    Private Enum ETest
    FFdd
    FFee
    FFff
    End Enum

    Sub Summat
    Dim test as ETest

    test = FFdd

    End Sub


    Now change the case of "FFdd" in both the declaration and in "Summat", and
    you'll see nowt!

    --

    ---------------------------------------
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Prime Response
    Brentford
    UK
    "Karl E. Peterson" <karl@mvps.org> wrote in message
    news:39538b15@news.devx.com...
    > Hi Jim --
    >
    > > Just as Eduardo and L.J. said: bogus error messages that prevent
    > > recompiling, and the only way to get around them is to not have any
    > > Optionals in the public interface (seems they're OK when Private). This

    is
    > > VB5 SP3: they probably did better in VB6...

    >
    > Point of clarification -- LJ seemed as puzzled as I at the idea of

    Optionals causing
    > compatability problems?
    >
    > Anyway, this I just haven't seen. They did do a rebuild of one DLL that

    was causing
    > some issues with compatability in VB5/SP3. (You had to actually ask for

    it, to get
    > it.) But the issue there was with Enums, if I recall. Is this doc'd

    anywhere in the
    > KB, or just "net.legend"?
    >
    > Thanks... Karl
    > --
    > http://www.mvps.org/vb
    >
    >
    >




  4. #34
    Jim Deutch Guest

    Re: compatibility: ActiveX controls versions

    Karl E. Peterson wrote in message <39538b15@news.devx.com>...
    >> Just as Eduardo and L.J. said: bogus error messages that prevent
    >> recompiling, and the only way to get around them is to not have any
    >> Optionals in the public interface (seems they're OK when Private).


    >Anyway, this I just haven't seen. They did do a rebuild of one DLL that

    was causing
    >some issues with compatability in VB5/SP3. (You had to actually ask for

    it, to get
    >it.) But the issue there was with Enums, if I recall. Is this doc'd

    anywhere in the
    >KB, or just "net.legend"?



    Me? Superstitious?

    I could swear this has happened to me. More than once. But not
    reproducibly. So I avoid it. And I'll continue to do so. But maybe I'll
    keep quiet about it from now on...

    Jim Deutch



  5. #35
    Jim Deutch Guest

    Re: compatibility: ActiveX controls versions

    Karl E. Peterson wrote in message <39538b15@news.devx.com>...
    >> Just as Eduardo and L.J. said: bogus error messages that prevent
    >> recompiling, and the only way to get around them is to not have any
    >> Optionals in the public interface (seems they're OK when Private).


    >Anyway, this I just haven't seen. They did do a rebuild of one DLL that

    was causing
    >some issues with compatability in VB5/SP3. (You had to actually ask for

    it, to get
    >it.) But the issue there was with Enums, if I recall. Is this doc'd

    anywhere in the
    >KB, or just "net.legend"?



    Me? Superstitious?

    I could swear this has happened to me. More than once. But not
    reproducibly. So I avoid it. And I'll continue to do so. But maybe I'll
    keep quiet about it from now on...

    Jim Deutch



  6. #36
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

    Hi Jim --

    "Jim Deutch" <103134.3516@compuserve.com> wrote in message
    news:39578d11@news.devx.com...
    > Karl E. Peterson wrote in message <39538b15@news.devx.com>...
    > >> Just as Eduardo and L.J. said: bogus error messages that prevent
    > >> recompiling, and the only way to get around them is to not have any
    > >> Optionals in the public interface (seems they're OK when Private).

    >
    > >Anyway, this I just haven't seen. They did do a rebuild of one DLL that

    > was causing
    > >some issues with compatability in VB5/SP3. (You had to actually ask for

    > it, to get
    > >it.) But the issue there was with Enums, if I recall. Is this doc'd

    > anywhere in the
    > >KB, or just "net.legend"?

    >
    >
    > Me? Superstitious?
    >
    > I could swear this has happened to me. More than once. But not
    > reproducibly. So I avoid it. And I'll continue to do so. But maybe I'll
    > keep quiet about it from now on...


    Heheheheh... Yeah, that sounds best. ;-)

    Later... Karl
    --
    http://www.mvps.org/vb






  7. #37
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

    Hi Jim --

    "Jim Deutch" <103134.3516@compuserve.com> wrote in message
    news:39578d11@news.devx.com...
    > Karl E. Peterson wrote in message <39538b15@news.devx.com>...
    > >> Just as Eduardo and L.J. said: bogus error messages that prevent
    > >> recompiling, and the only way to get around them is to not have any
    > >> Optionals in the public interface (seems they're OK when Private).

    >
    > >Anyway, this I just haven't seen. They did do a rebuild of one DLL that

    > was causing
    > >some issues with compatability in VB5/SP3. (You had to actually ask for

    > it, to get
    > >it.) But the issue there was with Enums, if I recall. Is this doc'd

    > anywhere in the
    > >KB, or just "net.legend"?

    >
    >
    > Me? Superstitious?
    >
    > I could swear this has happened to me. More than once. But not
    > reproducibly. So I avoid it. And I'll continue to do so. But maybe I'll
    > keep quiet about it from now on...


    Heheheheh... Yeah, that sounds best. ;-)

    Later... Karl
    --
    http://www.mvps.org/vb






  8. #38
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

    Hi Mark --

    Nowt? Sorry, I'm not sure I followed all that. But it is an interesting idea. Did
    you test it and find it to be true?

    Later... Karl
    --
    http://www.mvps.org/vb


    "Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote in message
    news:3956a608@news.devx.com...
    > Karl -
    >
    > I found one good explanation for this behaviour at Matthew Cromer's website
    > (www.sdaconsulting.com, I think). He thinks that the Enum problem occurs as
    > a result of the anomalous case-changing "ability" of Enum values. Just in
    > case some haven't come across this, I'll explain: we all know that if you
    > change the case of one or more characters in declarations of a variable,
    > procedure, or type name, then all uses of this name are changed to match it.
    > Changing the case of these uses will cause the operation to undo when you
    > move away from it. All, except items in an Enum, where the change in case
    > propagates back to the declaration - this is definitely a bug in VB5. And
    > Matthew Cromer thinks that this may be enough to cause a change in interface
    > declaration.
    >
    > Interestingly, I have just tried this in VB 6 SP3. It looks as if the fix
    > is not to cause ANY change in the case of ANY enumeration type item.
    >
    > Add this to a module:
    >
    >
    > Private Enum ETest
    > FFdd
    > FFee
    > FFff
    > End Enum
    >
    > Sub Summat
    > Dim test as ETest
    >
    > test = FFdd
    >
    > End Sub
    >
    >
    > Now change the case of "FFdd" in both the declaration and in "Summat", and
    > you'll see nowt!
    >
    > --
    >
    > ---------------------------------------
    > Mark Alexander Bertenshaw
    > Programmer/Analyst
    > Prime Response
    > Brentford
    > UK
    > "Karl E. Peterson" <karl@mvps.org> wrote in message
    > news:39538b15@news.devx.com...
    > > Hi Jim --
    > >
    > > > Just as Eduardo and L.J. said: bogus error messages that prevent
    > > > recompiling, and the only way to get around them is to not have any
    > > > Optionals in the public interface (seems they're OK when Private). This

    > is
    > > > VB5 SP3: they probably did better in VB6...

    > >
    > > Point of clarification -- LJ seemed as puzzled as I at the idea of

    > Optionals causing
    > > compatability problems?
    > >
    > > Anyway, this I just haven't seen. They did do a rebuild of one DLL that

    > was causing
    > > some issues with compatability in VB5/SP3. (You had to actually ask for

    > it, to get
    > > it.) But the issue there was with Enums, if I recall. Is this doc'd

    > anywhere in the
    > > KB, or just "net.legend"?
    > >
    > > Thanks... Karl
    > > --
    > > http://www.mvps.org/vb
    > >
    > >
    > >

    >
    >




  9. #39
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

    Hi Mark --

    Nowt? Sorry, I'm not sure I followed all that. But it is an interesting idea. Did
    you test it and find it to be true?

    Later... Karl
    --
    http://www.mvps.org/vb


    "Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote in message
    news:3956a608@news.devx.com...
    > Karl -
    >
    > I found one good explanation for this behaviour at Matthew Cromer's website
    > (www.sdaconsulting.com, I think). He thinks that the Enum problem occurs as
    > a result of the anomalous case-changing "ability" of Enum values. Just in
    > case some haven't come across this, I'll explain: we all know that if you
    > change the case of one or more characters in declarations of a variable,
    > procedure, or type name, then all uses of this name are changed to match it.
    > Changing the case of these uses will cause the operation to undo when you
    > move away from it. All, except items in an Enum, where the change in case
    > propagates back to the declaration - this is definitely a bug in VB5. And
    > Matthew Cromer thinks that this may be enough to cause a change in interface
    > declaration.
    >
    > Interestingly, I have just tried this in VB 6 SP3. It looks as if the fix
    > is not to cause ANY change in the case of ANY enumeration type item.
    >
    > Add this to a module:
    >
    >
    > Private Enum ETest
    > FFdd
    > FFee
    > FFff
    > End Enum
    >
    > Sub Summat
    > Dim test as ETest
    >
    > test = FFdd
    >
    > End Sub
    >
    >
    > Now change the case of "FFdd" in both the declaration and in "Summat", and
    > you'll see nowt!
    >
    > --
    >
    > ---------------------------------------
    > Mark Alexander Bertenshaw
    > Programmer/Analyst
    > Prime Response
    > Brentford
    > UK
    > "Karl E. Peterson" <karl@mvps.org> wrote in message
    > news:39538b15@news.devx.com...
    > > Hi Jim --
    > >
    > > > Just as Eduardo and L.J. said: bogus error messages that prevent
    > > > recompiling, and the only way to get around them is to not have any
    > > > Optionals in the public interface (seems they're OK when Private). This

    > is
    > > > VB5 SP3: they probably did better in VB6...

    > >
    > > Point of clarification -- LJ seemed as puzzled as I at the idea of

    > Optionals causing
    > > compatability problems?
    > >
    > > Anyway, this I just haven't seen. They did do a rebuild of one DLL that

    > was causing
    > > some issues with compatability in VB5/SP3. (You had to actually ask for

    > it, to get
    > > it.) But the issue there was with Enums, if I recall. Is this doc'd

    > anywhere in the
    > > KB, or just "net.legend"?
    > >
    > > Thanks... Karl
    > > --
    > > http://www.mvps.org/vb
    > >
    > >
    > >

    >
    >




  10. #40
    Brian Leung Guest

    Re: compatibility: ActiveX controls versions


    RE enums,

    I don't know if this issue is related, but maybe someone can
    explain it to me, or tell me if this occurs frequently.

    I have a public enum in a std_module. Most of the time, I can
    use this enum in classes, either as public members or passing
    as arguments. However, for some programs for reason I don't know
    I get a compile error:


    enum types defined in standard modules or private classes cannot
    be used in public object modules as parameters or return types
    for public procedures.

    This compile error only occurs for some programs

    Brian


    "Karl E. Peterson" <karl@mvps.org> wrote:
    >Hi Mark --
    >
    >Nowt? Sorry, I'm not sure I followed all that. But it is an interesting

    idea. Did
    >you test it and find it to be true?
    >
    >Later... Karl
    >--
    >http://www.mvps.org/vb
    >
    >
    >"Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote in message
    >news:3956a608@news.devx.com...
    >> Karl -
    >>
    >> I found one good explanation for this behaviour at Matthew Cromer's website
    >> (www.sdaconsulting.com, I think). He thinks that the Enum problem occurs

    as
    >> a result of the anomalous case-changing "ability" of Enum values. Just

    in
    >> case some haven't come across this, I'll explain: we all know that if

    you
    >> change the case of one or more characters in declarations of a variable,
    >> procedure, or type name, then all uses of this name are changed to match

    it.
    >> Changing the case of these uses will cause the operation to undo when

    you
    >> move away from it. All, except items in an Enum, where the change in

    case
    >> propagates back to the declaration - this is definitely a bug in VB5.

    And
    >> Matthew Cromer thinks that this may be enough to cause a change in interface
    >> declaration.
    >>
    >> Interestingly, I have just tried this in VB 6 SP3. It looks as if the

    fix
    >> is not to cause ANY change in the case of ANY enumeration type item.
    >>
    >> Add this to a module:
    >>
    >>
    >> Private Enum ETest
    >> FFdd
    >> FFee
    >> FFff
    >> End Enum
    >>
    >> Sub Summat
    >> Dim test as ETest
    >>
    >> test = FFdd
    >>
    >> End Sub
    >>
    >>
    >> Now change the case of "FFdd" in both the declaration and in "Summat",

    and
    >> you'll see nowt!
    >>
    >> --
    >>
    >> ---------------------------------------
    >> Mark Alexander Bertenshaw
    >> Programmer/Analyst
    >> Prime Response
    >> Brentford
    >> UK
    >> "Karl E. Peterson" <karl@mvps.org> wrote in message
    >> news:39538b15@news.devx.com...
    >> > Hi Jim --
    >> >
    >> > > Just as Eduardo and L.J. said: bogus error messages that prevent
    >> > > recompiling, and the only way to get around them is to not have any
    >> > > Optionals in the public interface (seems they're OK when Private).

    This
    >> is
    >> > > VB5 SP3: they probably did better in VB6...
    >> >
    >> > Point of clarification -- LJ seemed as puzzled as I at the idea of

    >> Optionals causing
    >> > compatability problems?
    >> >
    >> > Anyway, this I just haven't seen. They did do a rebuild of one DLL

    that
    >> was causing
    >> > some issues with compatability in VB5/SP3. (You had to actually ask

    for
    >> it, to get
    >> > it.) But the issue there was with Enums, if I recall. Is this doc'd

    >> anywhere in the
    >> > KB, or just "net.legend"?
    >> >
    >> > Thanks... Karl
    >> > --
    >> > http://www.mvps.org/vb
    >> >
    >> >
    >> >

    >>
    >>

    >
    >



  11. #41
    Brian Leung Guest

    Re: compatibility: ActiveX controls versions


    RE enums,

    I don't know if this issue is related, but maybe someone can
    explain it to me, or tell me if this occurs frequently.

    I have a public enum in a std_module. Most of the time, I can
    use this enum in classes, either as public members or passing
    as arguments. However, for some programs for reason I don't know
    I get a compile error:


    enum types defined in standard modules or private classes cannot
    be used in public object modules as parameters or return types
    for public procedures.

    This compile error only occurs for some programs

    Brian


    "Karl E. Peterson" <karl@mvps.org> wrote:
    >Hi Mark --
    >
    >Nowt? Sorry, I'm not sure I followed all that. But it is an interesting

    idea. Did
    >you test it and find it to be true?
    >
    >Later... Karl
    >--
    >http://www.mvps.org/vb
    >
    >
    >"Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote in message
    >news:3956a608@news.devx.com...
    >> Karl -
    >>
    >> I found one good explanation for this behaviour at Matthew Cromer's website
    >> (www.sdaconsulting.com, I think). He thinks that the Enum problem occurs

    as
    >> a result of the anomalous case-changing "ability" of Enum values. Just

    in
    >> case some haven't come across this, I'll explain: we all know that if

    you
    >> change the case of one or more characters in declarations of a variable,
    >> procedure, or type name, then all uses of this name are changed to match

    it.
    >> Changing the case of these uses will cause the operation to undo when

    you
    >> move away from it. All, except items in an Enum, where the change in

    case
    >> propagates back to the declaration - this is definitely a bug in VB5.

    And
    >> Matthew Cromer thinks that this may be enough to cause a change in interface
    >> declaration.
    >>
    >> Interestingly, I have just tried this in VB 6 SP3. It looks as if the

    fix
    >> is not to cause ANY change in the case of ANY enumeration type item.
    >>
    >> Add this to a module:
    >>
    >>
    >> Private Enum ETest
    >> FFdd
    >> FFee
    >> FFff
    >> End Enum
    >>
    >> Sub Summat
    >> Dim test as ETest
    >>
    >> test = FFdd
    >>
    >> End Sub
    >>
    >>
    >> Now change the case of "FFdd" in both the declaration and in "Summat",

    and
    >> you'll see nowt!
    >>
    >> --
    >>
    >> ---------------------------------------
    >> Mark Alexander Bertenshaw
    >> Programmer/Analyst
    >> Prime Response
    >> Brentford
    >> UK
    >> "Karl E. Peterson" <karl@mvps.org> wrote in message
    >> news:39538b15@news.devx.com...
    >> > Hi Jim --
    >> >
    >> > > Just as Eduardo and L.J. said: bogus error messages that prevent
    >> > > recompiling, and the only way to get around them is to not have any
    >> > > Optionals in the public interface (seems they're OK when Private).

    This
    >> is
    >> > > VB5 SP3: they probably did better in VB6...
    >> >
    >> > Point of clarification -- LJ seemed as puzzled as I at the idea of

    >> Optionals causing
    >> > compatability problems?
    >> >
    >> > Anyway, this I just haven't seen. They did do a rebuild of one DLL

    that
    >> was causing
    >> > some issues with compatability in VB5/SP3. (You had to actually ask

    for
    >> it, to get
    >> > it.) But the issue there was with Enums, if I recall. Is this doc'd

    >> anywhere in the
    >> > KB, or just "net.legend"?
    >> >
    >> > Thanks... Karl
    >> > --
    >> > http://www.mvps.org/vb
    >> >
    >> >
    >> >

    >>
    >>

    >
    >



  12. #42
    René Whitworth Guest

    Re: compatibility: ActiveX controls versions

    This occurs if, for example, you create a usercontrol.
    The enums, although public, defined in a .BAS module are NOT usable for the
    "outworld".
    This means you can't use an enum defined in a .BAS module for a public
    property/function in your usercontrol.
    In order to use an enum here you'll have to define it in the usercontrol as
    public.

    --
    Hope this helps ...

    Rene Whitworth
    Whitworth Software Solutions - Germany
    http://www.w-s-s.de
    Please reply to the newsgroup :-)


    "Brian Leung" <bleung@zoo.cam.ac.uk> schrieb im Newsbeitrag
    news:3958ae4b$1@news.devx.com...
    >
    > RE enums,
    >
    > I don't know if this issue is related, but maybe someone can
    > explain it to me, or tell me if this occurs frequently.
    >
    > I have a public enum in a std_module. Most of the time, I can
    > use this enum in classes, either as public members or passing
    > as arguments. However, for some programs for reason I don't know
    > I get a compile error:
    >
    >
    > enum types defined in standard modules or private classes cannot
    > be used in public object modules as parameters or return types
    > for public procedures.
    >
    > This compile error only occurs for some programs
    >
    > Brian
    >
    >
    > "Karl E. Peterson" <karl@mvps.org> wrote:
    > >Hi Mark --
    > >
    > >Nowt? Sorry, I'm not sure I followed all that. But it is an interesting

    > idea. Did
    > >you test it and find it to be true?
    > >
    > >Later... Karl
    > >--
    > >http://www.mvps.org/vb
    > >
    > >
    > >"Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote in message
    > >news:3956a608@news.devx.com...
    > >> Karl -
    > >>
    > >> I found one good explanation for this behaviour at Matthew Cromer's

    website
    > >> (www.sdaconsulting.com, I think). He thinks that the Enum problem

    occurs
    > as
    > >> a result of the anomalous case-changing "ability" of Enum values. Just

    > in
    > >> case some haven't come across this, I'll explain: we all know that if

    > you
    > >> change the case of one or more characters in declarations of a

    variable,
    > >> procedure, or type name, then all uses of this name are changed to

    match
    > it.
    > >> Changing the case of these uses will cause the operation to undo when

    > you
    > >> move away from it. All, except items in an Enum, where the change in

    > case
    > >> propagates back to the declaration - this is definitely a bug in VB5.

    > And
    > >> Matthew Cromer thinks that this may be enough to cause a change in

    interface
    > >> declaration.
    > >>
    > >> Interestingly, I have just tried this in VB 6 SP3. It looks as if the

    > fix
    > >> is not to cause ANY change in the case of ANY enumeration type item.
    > >>
    > >> Add this to a module:
    > >>
    > >>
    > >> Private Enum ETest
    > >> FFdd
    > >> FFee
    > >> FFff
    > >> End Enum
    > >>
    > >> Sub Summat
    > >> Dim test as ETest
    > >>
    > >> test = FFdd
    > >>
    > >> End Sub
    > >>
    > >>
    > >> Now change the case of "FFdd" in both the declaration and in "Summat",

    > and
    > >> you'll see nowt!
    > >>
    > >> --
    > >>
    > >> ---------------------------------------
    > >> Mark Alexander Bertenshaw
    > >> Programmer/Analyst
    > >> Prime Response
    > >> Brentford
    > >> UK
    > >> "Karl E. Peterson" <karl@mvps.org> wrote in message
    > >> news:39538b15@news.devx.com...
    > >> > Hi Jim --
    > >> >
    > >> > > Just as Eduardo and L.J. said: bogus error messages that prevent
    > >> > > recompiling, and the only way to get around them is to not have any
    > >> > > Optionals in the public interface (seems they're OK when Private).

    > This
    > >> is
    > >> > > VB5 SP3: they probably did better in VB6...
    > >> >
    > >> > Point of clarification -- LJ seemed as puzzled as I at the idea of
    > >> Optionals causing
    > >> > compatability problems?
    > >> >
    > >> > Anyway, this I just haven't seen. They did do a rebuild of one DLL

    > that
    > >> was causing
    > >> > some issues with compatability in VB5/SP3. (You had to actually ask

    > for
    > >> it, to get
    > >> > it.) But the issue there was with Enums, if I recall. Is this doc'd
    > >> anywhere in the
    > >> > KB, or just "net.legend"?
    > >> >
    > >> > Thanks... Karl
    > >> > --
    > >> > http://www.mvps.org/vb
    > >> >
    > >> >
    > >> >
    > >>
    > >>

    > >
    > >

    >




  13. #43
    René Whitworth Guest

    Re: compatibility: ActiveX controls versions

    This occurs if, for example, you create a usercontrol.
    The enums, although public, defined in a .BAS module are NOT usable for the
    "outworld".
    This means you can't use an enum defined in a .BAS module for a public
    property/function in your usercontrol.
    In order to use an enum here you'll have to define it in the usercontrol as
    public.

    --
    Hope this helps ...

    Rene Whitworth
    Whitworth Software Solutions - Germany
    http://www.w-s-s.de
    Please reply to the newsgroup :-)


    "Brian Leung" <bleung@zoo.cam.ac.uk> schrieb im Newsbeitrag
    news:3958ae4b$1@news.devx.com...
    >
    > RE enums,
    >
    > I don't know if this issue is related, but maybe someone can
    > explain it to me, or tell me if this occurs frequently.
    >
    > I have a public enum in a std_module. Most of the time, I can
    > use this enum in classes, either as public members or passing
    > as arguments. However, for some programs for reason I don't know
    > I get a compile error:
    >
    >
    > enum types defined in standard modules or private classes cannot
    > be used in public object modules as parameters or return types
    > for public procedures.
    >
    > This compile error only occurs for some programs
    >
    > Brian
    >
    >
    > "Karl E. Peterson" <karl@mvps.org> wrote:
    > >Hi Mark --
    > >
    > >Nowt? Sorry, I'm not sure I followed all that. But it is an interesting

    > idea. Did
    > >you test it and find it to be true?
    > >
    > >Later... Karl
    > >--
    > >http://www.mvps.org/vb
    > >
    > >
    > >"Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote in message
    > >news:3956a608@news.devx.com...
    > >> Karl -
    > >>
    > >> I found one good explanation for this behaviour at Matthew Cromer's

    website
    > >> (www.sdaconsulting.com, I think). He thinks that the Enum problem

    occurs
    > as
    > >> a result of the anomalous case-changing "ability" of Enum values. Just

    > in
    > >> case some haven't come across this, I'll explain: we all know that if

    > you
    > >> change the case of one or more characters in declarations of a

    variable,
    > >> procedure, or type name, then all uses of this name are changed to

    match
    > it.
    > >> Changing the case of these uses will cause the operation to undo when

    > you
    > >> move away from it. All, except items in an Enum, where the change in

    > case
    > >> propagates back to the declaration - this is definitely a bug in VB5.

    > And
    > >> Matthew Cromer thinks that this may be enough to cause a change in

    interface
    > >> declaration.
    > >>
    > >> Interestingly, I have just tried this in VB 6 SP3. It looks as if the

    > fix
    > >> is not to cause ANY change in the case of ANY enumeration type item.
    > >>
    > >> Add this to a module:
    > >>
    > >>
    > >> Private Enum ETest
    > >> FFdd
    > >> FFee
    > >> FFff
    > >> End Enum
    > >>
    > >> Sub Summat
    > >> Dim test as ETest
    > >>
    > >> test = FFdd
    > >>
    > >> End Sub
    > >>
    > >>
    > >> Now change the case of "FFdd" in both the declaration and in "Summat",

    > and
    > >> you'll see nowt!
    > >>
    > >> --
    > >>
    > >> ---------------------------------------
    > >> Mark Alexander Bertenshaw
    > >> Programmer/Analyst
    > >> Prime Response
    > >> Brentford
    > >> UK
    > >> "Karl E. Peterson" <karl@mvps.org> wrote in message
    > >> news:39538b15@news.devx.com...
    > >> > Hi Jim --
    > >> >
    > >> > > Just as Eduardo and L.J. said: bogus error messages that prevent
    > >> > > recompiling, and the only way to get around them is to not have any
    > >> > > Optionals in the public interface (seems they're OK when Private).

    > This
    > >> is
    > >> > > VB5 SP3: they probably did better in VB6...
    > >> >
    > >> > Point of clarification -- LJ seemed as puzzled as I at the idea of
    > >> Optionals causing
    > >> > compatability problems?
    > >> >
    > >> > Anyway, this I just haven't seen. They did do a rebuild of one DLL

    > that
    > >> was causing
    > >> > some issues with compatability in VB5/SP3. (You had to actually ask

    > for
    > >> it, to get
    > >> > it.) But the issue there was with Enums, if I recall. Is this doc'd
    > >> anywhere in the
    > >> > KB, or just "net.legend"?
    > >> >
    > >> > Thanks... Karl
    > >> > --
    > >> > http://www.mvps.org/vb
    > >> >
    > >> >
    > >> >
    > >>
    > >>

    > >
    > >

    >




  14. #44
    Brian Leung Guest

    Re: compatibility: ActiveX controls versions


    Hi Rene,

    Yes that is helpful. I wasn't making a usercontrol, but
    was making an add-in, where the classes would not have been
    directly accessible anyways...so I didn't consider the "outworld".
    Anyhow, that was the problem. The solution was simply to use
    Friend rather than public functions.

    Cheers,

    Brian


    "René Whitworth" <R.Whitworth@w-s-s.de> wrote:
    >This occurs if, for example, you create a usercontrol.
    >The enums, although public, defined in a .BAS module are NOT usable for

    the
    >"outworld".
    >This means you can't use an enum defined in a .BAS module for a public
    >property/function in your usercontrol.
    >In order to use an enum here you'll have to define it in the usercontrol

    as
    >public.
    >
    >--
    >Hope this helps ...
    >
    >Rene Whitworth
    >Whitworth Software Solutions - Germany
    >http://www.w-s-s.de
    >Please reply to the newsgroup :-)
    >
    >
    >"Brian Leung" <bleung@zoo.cam.ac.uk> schrieb im Newsbeitrag
    >news:3958ae4b$1@news.devx.com...
    >>
    >> RE enums,
    >>
    >> I don't know if this issue is related, but maybe someone can
    >> explain it to me, or tell me if this occurs frequently.
    >>
    >> I have a public enum in a std_module. Most of the time, I can
    >> use this enum in classes, either as public members or passing
    >> as arguments. However, for some programs for reason I don't know
    >> I get a compile error:
    >>
    >>
    >> enum types defined in standard modules or private classes cannot
    >> be used in public object modules as parameters or return types
    >> for public procedures.
    >>
    >> This compile error only occurs for some programs
    >>
    >> Brian
    >>
    >>
    >> "Karl E. Peterson" <karl@mvps.org> wrote:
    >> >Hi Mark --
    >> >
    >> >Nowt? Sorry, I'm not sure I followed all that. But it is an interesting

    >> idea. Did
    >> >you test it and find it to be true?
    >> >
    >> >Later... Karl
    >> >--
    >> >http://www.mvps.org/vb
    >> >
    >> >
    >> >"Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote in message
    >> >news:3956a608@news.devx.com...
    >> >> Karl -
    >> >>
    >> >> I found one good explanation for this behaviour at Matthew Cromer's

    >website
    >> >> (www.sdaconsulting.com, I think). He thinks that the Enum problem

    >occurs
    >> as
    >> >> a result of the anomalous case-changing "ability" of Enum values.

    Just
    >> in
    >> >> case some haven't come across this, I'll explain: we all know that

    if
    >> you
    >> >> change the case of one or more characters in declarations of a

    >variable,
    >> >> procedure, or type name, then all uses of this name are changed to

    >match
    >> it.
    >> >> Changing the case of these uses will cause the operation to undo when

    >> you
    >> >> move away from it. All, except items in an Enum, where the change

    in
    >> case
    >> >> propagates back to the declaration - this is definitely a bug in VB5.

    >> And
    >> >> Matthew Cromer thinks that this may be enough to cause a change in

    >interface
    >> >> declaration.
    >> >>
    >> >> Interestingly, I have just tried this in VB 6 SP3. It looks as if

    the
    >> fix
    >> >> is not to cause ANY change in the case of ANY enumeration type item.
    >> >>
    >> >> Add this to a module:
    >> >>
    >> >>
    >> >> Private Enum ETest
    >> >> FFdd
    >> >> FFee
    >> >> FFff
    >> >> End Enum
    >> >>
    >> >> Sub Summat
    >> >> Dim test as ETest
    >> >>
    >> >> test = FFdd
    >> >>
    >> >> End Sub
    >> >>
    >> >>
    >> >> Now change the case of "FFdd" in both the declaration and in "Summat",

    >> and
    >> >> you'll see nowt!
    >> >>
    >> >> --
    >> >>
    >> >> ---------------------------------------
    >> >> Mark Alexander Bertenshaw
    >> >> Programmer/Analyst
    >> >> Prime Response
    >> >> Brentford
    >> >> UK
    >> >> "Karl E. Peterson" <karl@mvps.org> wrote in message
    >> >> news:39538b15@news.devx.com...
    >> >> > Hi Jim --
    >> >> >
    >> >> > > Just as Eduardo and L.J. said: bogus error messages that prevent
    >> >> > > recompiling, and the only way to get around them is to not have

    any
    >> >> > > Optionals in the public interface (seems they're OK when Private).

    >> This
    >> >> is
    >> >> > > VB5 SP3: they probably did better in VB6...
    >> >> >
    >> >> > Point of clarification -- LJ seemed as puzzled as I at the idea of
    >> >> Optionals causing
    >> >> > compatability problems?
    >> >> >
    >> >> > Anyway, this I just haven't seen. They did do a rebuild of one DLL

    >> that
    >> >> was causing
    >> >> > some issues with compatability in VB5/SP3. (You had to actually

    ask
    >> for
    >> >> it, to get
    >> >> > it.) But the issue there was with Enums, if I recall. Is this doc'd
    >> >> anywhere in the
    >> >> > KB, or just "net.legend"?
    >> >> >
    >> >> > Thanks... Karl
    >> >> > --
    >> >> > http://www.mvps.org/vb
    >> >> >
    >> >> >
    >> >> >
    >> >>
    >> >>
    >> >
    >> >

    >>

    >
    >



  15. #45
    Brian Leung Guest

    Re: compatibility: ActiveX controls versions


    Hi Rene,

    Yes that is helpful. I wasn't making a usercontrol, but
    was making an add-in, where the classes would not have been
    directly accessible anyways...so I didn't consider the "outworld".
    Anyhow, that was the problem. The solution was simply to use
    Friend rather than public functions.

    Cheers,

    Brian


    "René Whitworth" <R.Whitworth@w-s-s.de> wrote:
    >This occurs if, for example, you create a usercontrol.
    >The enums, although public, defined in a .BAS module are NOT usable for

    the
    >"outworld".
    >This means you can't use an enum defined in a .BAS module for a public
    >property/function in your usercontrol.
    >In order to use an enum here you'll have to define it in the usercontrol

    as
    >public.
    >
    >--
    >Hope this helps ...
    >
    >Rene Whitworth
    >Whitworth Software Solutions - Germany
    >http://www.w-s-s.de
    >Please reply to the newsgroup :-)
    >
    >
    >"Brian Leung" <bleung@zoo.cam.ac.uk> schrieb im Newsbeitrag
    >news:3958ae4b$1@news.devx.com...
    >>
    >> RE enums,
    >>
    >> I don't know if this issue is related, but maybe someone can
    >> explain it to me, or tell me if this occurs frequently.
    >>
    >> I have a public enum in a std_module. Most of the time, I can
    >> use this enum in classes, either as public members or passing
    >> as arguments. However, for some programs for reason I don't know
    >> I get a compile error:
    >>
    >>
    >> enum types defined in standard modules or private classes cannot
    >> be used in public object modules as parameters or return types
    >> for public procedures.
    >>
    >> This compile error only occurs for some programs
    >>
    >> Brian
    >>
    >>
    >> "Karl E. Peterson" <karl@mvps.org> wrote:
    >> >Hi Mark --
    >> >
    >> >Nowt? Sorry, I'm not sure I followed all that. But it is an interesting

    >> idea. Did
    >> >you test it and find it to be true?
    >> >
    >> >Later... Karl
    >> >--
    >> >http://www.mvps.org/vb
    >> >
    >> >
    >> >"Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote in message
    >> >news:3956a608@news.devx.com...
    >> >> Karl -
    >> >>
    >> >> I found one good explanation for this behaviour at Matthew Cromer's

    >website
    >> >> (www.sdaconsulting.com, I think). He thinks that the Enum problem

    >occurs
    >> as
    >> >> a result of the anomalous case-changing "ability" of Enum values.

    Just
    >> in
    >> >> case some haven't come across this, I'll explain: we all know that

    if
    >> you
    >> >> change the case of one or more characters in declarations of a

    >variable,
    >> >> procedure, or type name, then all uses of this name are changed to

    >match
    >> it.
    >> >> Changing the case of these uses will cause the operation to undo when

    >> you
    >> >> move away from it. All, except items in an Enum, where the change

    in
    >> case
    >> >> propagates back to the declaration - this is definitely a bug in VB5.

    >> And
    >> >> Matthew Cromer thinks that this may be enough to cause a change in

    >interface
    >> >> declaration.
    >> >>
    >> >> Interestingly, I have just tried this in VB 6 SP3. It looks as if

    the
    >> fix
    >> >> is not to cause ANY change in the case of ANY enumeration type item.
    >> >>
    >> >> Add this to a module:
    >> >>
    >> >>
    >> >> Private Enum ETest
    >> >> FFdd
    >> >> FFee
    >> >> FFff
    >> >> End Enum
    >> >>
    >> >> Sub Summat
    >> >> Dim test as ETest
    >> >>
    >> >> test = FFdd
    >> >>
    >> >> End Sub
    >> >>
    >> >>
    >> >> Now change the case of "FFdd" in both the declaration and in "Summat",

    >> and
    >> >> you'll see nowt!
    >> >>
    >> >> --
    >> >>
    >> >> ---------------------------------------
    >> >> Mark Alexander Bertenshaw
    >> >> Programmer/Analyst
    >> >> Prime Response
    >> >> Brentford
    >> >> UK
    >> >> "Karl E. Peterson" <karl@mvps.org> wrote in message
    >> >> news:39538b15@news.devx.com...
    >> >> > Hi Jim --
    >> >> >
    >> >> > > Just as Eduardo and L.J. said: bogus error messages that prevent
    >> >> > > recompiling, and the only way to get around them is to not have

    any
    >> >> > > Optionals in the public interface (seems they're OK when Private).

    >> This
    >> >> is
    >> >> > > VB5 SP3: they probably did better in VB6...
    >> >> >
    >> >> > Point of clarification -- LJ seemed as puzzled as I at the idea of
    >> >> Optionals causing
    >> >> > compatability problems?
    >> >> >
    >> >> > Anyway, this I just haven't seen. They did do a rebuild of one DLL

    >> that
    >> >> was causing
    >> >> > some issues with compatability in VB5/SP3. (You had to actually

    ask
    >> for
    >> >> it, to get
    >> >> > it.) But the issue there was with Enums, if I recall. Is this doc'd
    >> >> anywhere in the
    >> >> > KB, or just "net.legend"?
    >> >> >
    >> >> > Thanks... Karl
    >> >> > --
    >> >> > http://www.mvps.org/vb
    >> >> >
    >> >> >
    >> >> >
    >> >>
    >> >>
    >> >
    >> >

    >>

    >
    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center