DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 3 123 LastLast
Results 1 to 15 of 45

Thread: compatibility: ActiveX controls versions

  1. #1
    Brian Leung Guest

    compatibility: ActiveX controls versions


    Hi,

    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.


    thanks

    Brian

  2. #2
    Jim Deutch Guest

    Re: compatibility: ActiveX controls versions

    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. #3
    Jim Deutch Guest

    Re: compatibility: ActiveX controls versions

    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



  4. #4
    Brian Leung Guest

    Re: compatibility: ActiveX controls versions


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



  5. #5
    Brian Leung Guest

    Re: compatibility: ActiveX controls versions


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



  6. #6
    Mark Alexander Bertenshaw Guest

    Re: compatibility: ActiveX controls versions

    Brian -

    You would have thought that it would be OK, but unfortunately adding
    Optional parameters counts as breaking the interface. Instead, you could
    try creating a new version of your interface, and Implementing it in the
    original class. The trick would be to remember to change all your object
    variables so that they are of the new interface.

    --

    ---------------------------------------
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Prime Response
    Brentford
    UK

    "Brian Leung" <bleung@zoo.cam.ac.uk> wrote in message
    news: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
    > >
    > >

    >




  7. #7
    Mark Alexander Bertenshaw Guest

    Re: compatibility: ActiveX controls versions

    Brian -

    You would have thought that it would be OK, but unfortunately adding
    Optional parameters counts as breaking the interface. Instead, you could
    try creating a new version of your interface, and Implementing it in the
    original class. The trick would be to remember to change all your object
    variables so that they are of the new interface.

    --

    ---------------------------------------
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Prime Response
    Brentford
    UK

    "Brian Leung" <bleung@zoo.cam.ac.uk> wrote in message
    news: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
    > >
    > >

    >




  8. #8
    Jim Deutch Guest

    Re: compatibility: ActiveX controls versions

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

    >




  9. #9
    Jim Deutch Guest

    Re: compatibility: ActiveX controls versions

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

    >




  10. #10
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

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

    > >

    >
    >




  11. #11
    Karl E. Peterson Guest

    Re: compatibility: ActiveX controls versions

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

    > >

    >
    >




  12. #12
    Eduardo A. Morcillo Guest

    Re: compatibility: ActiveX controls versions

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

    > >
    > >

    >
    >




  13. #13
    Eduardo A. Morcillo Guest

    Re: compatibility: ActiveX controls versions

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

    > >
    > >

    >
    >




  14. #14
    L.J. Johnson Guest

    Re: compatibility: ActiveX controls versions

    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.

    --
    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. #15
    L.J. Johnson Guest

    Re: compatibility: ActiveX controls versions

    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.

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