dcsimg


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 45

Thread: compatibility: ActiveX controls versions

  1. #16
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

    Hi Eduardo --

    Yuck. I've heard this, but only experienced it once -- with VB5/SP3. We ended up
    nailing it down to Public Enum's in a standard module, though. Any coincidences
    here, yet?

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


    "Eduardo A. Morcillo" <e_morcillo@yahoo.com> wrote in message
    news:39529b0e@news.devx.com...
    > Sometimes I receive an error telling me that the function/property has
    > changed when there was no change at all (not even in the code). I don't know
    > if that was caused by Optional parameters o by other things. The last time
    > that something like that has happened to me was with the RichEdit control
    > that I'm doing and the function had optional parameters (in fact all
    > parameters are optional).
    >
    > --
    > Eduardo A. Morcillo
    > http://www.domaindlx.com/e_morcillo
    > "Karl E. Peterson" <karl@mvps.org> wrote in message
    > news:39527a1c@news.devx.com...
    > > Hi Jim --
    > >
    > > You're kidding, right? I've never heard anyone complaining about this,

    > before. What
    > > sorts of issues were you having? Just the random, compiler-puked-on-me

    > type? Or
    > > were the problems from *adding* optionals?
    > >
    > > Thanks... Karl
    > > --
    > > http://www.mvps.org/vb
    > >
    > >
    > > "Jim Deutch" <103134.3516@compuserve.com> wrote in message
    > > news:395243a7@news.devx.com...
    > > > I have found that optional parameters in the public interface are bad

    > news
    > > > for binary compatibility: I never use them in public anymore because

    > they
    > > > make bad things happen (as you've observed, though you hadn't made the
    > > > connection).
    > > >
    > > > Just _having_ optional parameters in the public interface (even from the
    > > > very first version) seems to make for successive version problems (VB

    > may
    > > > complain with a bogus error, or may compile but your component won't run
    > > > against the old exe).
    > > >
    > > > Jim Deutch
    > > >
    > > > Brian Leung wrote in message <394f71e6$1@news.devx.com>...
    > > > >
    > > > >Hi Jim,
    > > > >
    > > > >What if I am not changing my public interface... or rather, if I do,
    > > > >it is via optional parameters such that any previous use of the
    > > > >control should still be valid. Even if the changes are
    > > > >only private, if I recompile (and reinstall on another computer
    > > > >using Packaging and Deployment wizard) the previously compiled
    > > > >EXEs no longer see the control as valid.
    > > > >
    > > > >Brian
    > > > >
    > > > >
    > > > >"Jim Deutch" <103134.3516@compuserve.com> wrote:
    > > > >>Brian Leung wrote in message <394f5894$1@news.devx.com>...
    > > > >>>How do I keep my active X controls compatible with previously
    > > > >>>compiled EXEs, after I make modifications of the control and
    > > > >>>recompile them. Right now, I have the component properties
    > > > >>>set to binary compatibility, where I set the compatibility to
    > > > >>>a non changing ocx file.
    > > > >>
    > > > >>In theory, that's all you have to do. In practice, you must also do

    > some
    > > > >>other things.
    > > > >>
    > > > >>You should tightly control what versions of critical system dlls are

    > on
    > > > >your
    > > > >>development machine, especially oleaut32, olepro32, and comcat.

    > Compiling
    > > > >>against later versions will make your control fail to run against

    > earlier
    > > > >>ones.
    > > > >>
    > > > >>Also, you should "chain" your compatible ocx versions IF (and only if)

    > you
    > > > >>make any changes to their public interfaces (ie their public

    > properties,
    > > > >>methods, enums, etc). When these changes are made, the TypeLib

    > Version
    > > > >>number is incremented automatically, and you want it to keep

    > incrementing,
    > > > >>rather than repeating the first increment over and over.
    > > > >>
    > > > >>If you add a completely new interface (a new public class) you should
    > > > break
    > > > >>binary compatibility, rename the project, and make it a whole new

    > control.
    > > > >>
    > > > >>Jim Deutch
    > > > >>
    > > > >>
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >




  2. #17
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

    Hi Eduardo --

    Yuck. I've heard this, but only experienced it once -- with VB5/SP3. We ended up
    nailing it down to Public Enum's in a standard module, though. Any coincidences
    here, yet?

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


    "Eduardo A. Morcillo" <e_morcillo@yahoo.com> wrote in message
    news:39529b0e@news.devx.com...
    > Sometimes I receive an error telling me that the function/property has
    > changed when there was no change at all (not even in the code). I don't know
    > if that was caused by Optional parameters o by other things. The last time
    > that something like that has happened to me was with the RichEdit control
    > that I'm doing and the function had optional parameters (in fact all
    > parameters are optional).
    >
    > --
    > Eduardo A. Morcillo
    > http://www.domaindlx.com/e_morcillo
    > "Karl E. Peterson" <karl@mvps.org> wrote in message
    > news:39527a1c@news.devx.com...
    > > Hi Jim --
    > >
    > > You're kidding, right? I've never heard anyone complaining about this,

    > before. What
    > > sorts of issues were you having? Just the random, compiler-puked-on-me

    > type? Or
    > > were the problems from *adding* optionals?
    > >
    > > Thanks... Karl
    > > --
    > > http://www.mvps.org/vb
    > >
    > >
    > > "Jim Deutch" <103134.3516@compuserve.com> wrote in message
    > > news:395243a7@news.devx.com...
    > > > I have found that optional parameters in the public interface are bad

    > news
    > > > for binary compatibility: I never use them in public anymore because

    > they
    > > > make bad things happen (as you've observed, though you hadn't made the
    > > > connection).
    > > >
    > > > Just _having_ optional parameters in the public interface (even from the
    > > > very first version) seems to make for successive version problems (VB

    > may
    > > > complain with a bogus error, or may compile but your component won't run
    > > > against the old exe).
    > > >
    > > > Jim Deutch
    > > >
    > > > Brian Leung wrote in message <394f71e6$1@news.devx.com>...
    > > > >
    > > > >Hi Jim,
    > > > >
    > > > >What if I am not changing my public interface... or rather, if I do,
    > > > >it is via optional parameters such that any previous use of the
    > > > >control should still be valid. Even if the changes are
    > > > >only private, if I recompile (and reinstall on another computer
    > > > >using Packaging and Deployment wizard) the previously compiled
    > > > >EXEs no longer see the control as valid.
    > > > >
    > > > >Brian
    > > > >
    > > > >
    > > > >"Jim Deutch" <103134.3516@compuserve.com> wrote:
    > > > >>Brian Leung wrote in message <394f5894$1@news.devx.com>...
    > > > >>>How do I keep my active X controls compatible with previously
    > > > >>>compiled EXEs, after I make modifications of the control and
    > > > >>>recompile them. Right now, I have the component properties
    > > > >>>set to binary compatibility, where I set the compatibility to
    > > > >>>a non changing ocx file.
    > > > >>
    > > > >>In theory, that's all you have to do. In practice, you must also do

    > some
    > > > >>other things.
    > > > >>
    > > > >>You should tightly control what versions of critical system dlls are

    > on
    > > > >your
    > > > >>development machine, especially oleaut32, olepro32, and comcat.

    > Compiling
    > > > >>against later versions will make your control fail to run against

    > earlier
    > > > >>ones.
    > > > >>
    > > > >>Also, you should "chain" your compatible ocx versions IF (and only if)

    > you
    > > > >>make any changes to their public interfaces (ie their public

    > properties,
    > > > >>methods, enums, etc). When these changes are made, the TypeLib

    > Version
    > > > >>number is incremented automatically, and you want it to keep

    > incrementing,
    > > > >>rather than repeating the first increment over and over.
    > > > >>
    > > > >>If you add a completely new interface (a new public class) you should
    > > > break
    > > > >>binary compatibility, rename the project, and make it a whole new

    > control.
    > > > >>
    > > > >>Jim Deutch
    > > > >>
    > > > >>
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >




  3. #18
    Brian Leung Guest

    Re: compatibility: ActiveX controls versions


    "L.J. Johnson" <ljjohnsn@flash.net> wrote:
    >Jim,
    >
    >> Just _having_ optional parameters in the public interface (even from the
    >> very first version) seems to make for successive version problems (VB

    may
    >> complain with a bogus error, or may compile but your component won't run
    >> against the old exe).

    >
    >Really? I use a *lot* of them (lacking the true polymorphism VB 7 is
    >supposed to give us), and haven't seemed to have any *additional* version
    >problems, other than the ones we already know and love.
    >

    Hi Jim,

    so how did you get around the problems that you know about and
    love? Mark was saying that adding optional parameters causes
    it to count as breaking the public interface. Is there a way
    around this, so that all previous EXEs remain compatible?

    Thanks,

    Brian

  4. #19
    Brian Leung Guest

    Re: compatibility: ActiveX controls versions


    "L.J. Johnson" <ljjohnsn@flash.net> wrote:
    >Jim,
    >
    >> Just _having_ optional parameters in the public interface (even from the
    >> very first version) seems to make for successive version problems (VB

    may
    >> complain with a bogus error, or may compile but your component won't run
    >> against the old exe).

    >
    >Really? I use a *lot* of them (lacking the true polymorphism VB 7 is
    >supposed to give us), and haven't seemed to have any *additional* version
    >problems, other than the ones we already know and love.
    >

    Hi Jim,

    so how did you get around the problems that you know about and
    love? Mark was saying that adding optional parameters causes
    it to count as breaking the public interface. Is there a way
    around this, so that all previous EXEs remain compatible?

    Thanks,

    Brian

  5. #20
    Jim Deutch Guest

    Re: compatibility: ActiveX controls versions

    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...

    Jim Deutch

    Karl E. Peterson wrote in message <39527a1c@news.devx.com>...
    >Hi Jim --
    >
    >You're kidding, right? I've never heard anyone complaining about this,

    before. What
    >sorts of issues were you having? Just the random, compiler-puked-on-me

    type? Or
    >were the problems from *adding* optionals?
    >





  6. #21
    Jim Deutch Guest

    Re: compatibility: ActiveX controls versions

    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...

    Jim Deutch

    Karl E. Peterson wrote in message <39527a1c@news.devx.com>...
    >Hi Jim --
    >
    >You're kidding, right? I've never heard anyone complaining about this,

    before. What
    >sorts of issues were you having? Just the random, compiler-puked-on-me

    type? Or
    >were the problems from *adding* optionals?
    >





  7. #22
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

    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




  8. #23
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

    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. #24
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

    Hi Brian --

    > Mark was saying that adding optional parameters causes
    > it to count as breaking the public interface. Is there a way
    > around this, so that all previous EXEs remain compatible?


    Yeah, that's correct -- *adding* anything to existing props/events/methods will
    indeed fry the compatability. To avoid that, the choices are just two, really.
    Either design the "perfect interface" from the get-go <g>, or extend the existing
    interface with new P/E/M's.

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




  10. #25
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

    Hi Brian --

    > Mark was saying that adding optional parameters causes
    > it to count as breaking the public interface. Is there a way
    > around this, so that all previous EXEs remain compatible?


    Yeah, that's correct -- *adding* anything to existing props/events/methods will
    indeed fry the compatability. To avoid that, the choices are just two, really.
    Either design the "perfect interface" from the get-go <g>, or extend the existing
    interface with new P/E/M's.

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




  11. #26
    Brian Leung Guest

    Re: compatibility: ActiveX controls versions


    >Yeah, that's correct -- *adding* anything to existing props/events/methods

    will
    >indeed fry the compatability. To avoid that, the choices are just two,

    really.
    >Either design the "perfect interface" from the get-go <g>, or extend the

    existing
    >interface with new P/E/M's.


    Hi Karl,

    ****.

    cheers,

    Brian



  12. #27
    Brian Leung Guest

    Re: compatibility: ActiveX controls versions


    >Yeah, that's correct -- *adding* anything to existing props/events/methods

    will
    >indeed fry the compatability. To avoid that, the choices are just two,

    really.
    >Either design the "perfect interface" from the get-go <g>, or extend the

    existing
    >interface with new P/E/M's.


    Hi Karl,

    ****.

    cheers,

    Brian



  13. #28
    L.J. Johnson Guest

    Re: compatibility: ActiveX controls versions

    Brian,

    > so how did you get around the problems that you know about and
    > love? Mark was saying that adding optional parameters causes
    > it to count as breaking the public interface. Is there a way
    > around this, so that all previous EXEs remain compatible?


    Adding optional parameters break compatibility, those are the rules.
    Remember that optional parameters aren't necessarily "optional" -- they
    aren't from ASP, for example.

    --
    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>




  14. #29
    L.J. Johnson Guest

    Re: compatibility: ActiveX controls versions

    Brian,

    > so how did you get around the problems that you know about and
    > love? Mark was saying that adding optional parameters causes
    > it to count as breaking the public interface. Is there a way
    > around this, so that all previous EXEs remain compatible?


    Adding optional parameters break compatibility, those are the rules.
    Remember that optional parameters aren't necessarily "optional" -- they
    aren't from ASP, for example.

    --
    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>




  15. #30
    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>




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