ADODBConstants minor issues

Hi...

just noticed that in ADODBConstants pool there are a few constants
missing that I looked for:
adByRef (0x4000)
adVector (0x1000)

Also I noticed duplicate key, one misstyped: adSchemaReferentialContraints
dunno if this is intentional (legacy stuff)

Ciao

...Jochen

"Jochen Riekhof" <[hidden email]> wrote in message
news:[hidden email]...
The pool will have been generated from the type-library by the type-library
analyzer. Those might have been missing from the particular type-library.
Also the duplicate name could be because of an error in an old version of
the type-library from which the pool was generated at one point, with this
having been corrected in a later version from which it was regenerated.

Regards

Blair

Hi Blair...

I see... is there a way to add the missing constants to the
ConstantsPoolDictionary? I could put it in the initialize of some class.

Ciao

...Jochen
"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...

Jochen,

> I see... is there a way to add the missing constants to the
> ConstantsPoolDictionary? I could put it in the initialize of some class.

I find it easier to put it in the preinstall script of one, or more, of
the packages that uses the constants.  That way you don't have to worry
about compilation failures when the package is loaded (and it's methods
compiled) before your class initialization method that defines the
constants is executed.

In the package's preinstall script you just put

ADODBConstants
        at: 'adByRef' put: 16r4000;
        at: 'adVector' put: 16r1000

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Hi Ian...

great, thank you, I will do it like that! Now I also learned that
PoolConstantsDictionaries are modifieable-they just ensure no different
replacement of values (one could however even do removeKey: and then at:
put: still to modify an existing constant).
I also saw that there is a changed flag, what is this used for? Does it make
sense to reset it after edit?

Ciao

...Jochen



"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...

Jochen,

> great, thank you, I will do it like that! Now I also learned that
> PoolConstantsDictionaries are modifieable-they just ensure no different
> replacement of values (one could however even do removeKey: and then at:
> put: still to modify an existing constant).

I would be a bit careful about modifying existing values in a PCD, it
would be quite easy to break code relying on the current values.  I
probably wouldn't try to correct an incorrect base image value in this
way, even as a temporary fix.

If you need a lookup dictionary where the values can be modified then
you should probably use a PoolDictionary.

> I also saw that there is a changed flag, what is this used for? Does it make
> sense to reset it after edit?

I wouldn't bother.  Treat changes to a PCD in the same way as changes
(additions or modifications) to a class in the base image - the change
flag is a useful reminder.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Ian Bartholomew schrieb:
> I would be a bit careful about modifying existing values in a PCD, it
> would be quite easy to break code relying on the current values.  I
> probably wouldn't try to correct an incorrect base image value in this
> way, even as a temporary fix.

Oh yes, sure, I just wanted to say that it is in theory possible :-).

> I wouldn't bother.  Treat changes to a PCD in the same way as changes
> (additions or modifications) to a class in the base image - the change
> flag is a useful reminder.

I see. Thanks again for your help Ian!

Ciao

...Jochen