- Dynamically Determining Attribute Numeric Equivalents
- Posted by Scott McPhillips [MVP] on March 29th, 2007
sas04.nospam@marktab.com wrote:
I don't have any idea what you mean by "inside" and "outside" Windows.
These things are constants defined in readily available .h files. If
they change that would break hundreds of thousands of old programs, both
inside and outside Microsoft: They will not change. Whatever you are
worried about is a non-problem.
--
Scott McPhillips [VC++ MVP]
- Posted by sas04.nospam@marktab.com on March 29th, 2007
Thanks
Reply to Sator Laser -- the variables are not constants available when
restricted to calling Windows DLLs (to my knowledge), and apparently
not to any respondent so far.
Reply to Scott McPhillips -- I am aware of the .H listings, but did
not know that they would not change, so your information is useful.
The terminology of "inside" and "outside" Windows refers to choosing
to use (say) a .NET programming language as opposed to other
proprietary programming environments that reside on the Windows
operating system.
- Posted by Scott Seligman [MSFT] on March 29th, 2007
sas04.nospam@marktab.com wrote:
But something like FILE_ATTRIBUTE_ARCHIVE is not a variable. It's a
constant. It's just a convenient way of writing out 0x00000020 so
other programmers have some clue what you mean. The complier switches
it out with the numeric value and if Microsoft decides to change
FILE_ATTRIBUTE_ARCHIVE to some other value in the future, all existing
applications will still use the old value till they're recompiled with
the new .h files.
Huh? They both load Windows DLLs and call into the functions in them.
--
Scott Seligman [MSFT]
This posting is provided AS IS with no warranties, and confers
no rights.
- Posted by sas04.nospam@marktab.com on March 29th, 2007
Reply to Scott Seligman
Thanks -- your elaboration on the nature of the compiler switch of
numeric values for coded constants provides a description of the
mechanism. Because of how this switch occurs, there is a confidence
that the translation between character and numeric equivalents will be
the same for the foreseeable future.
I believe this problem is solved. The answer is to use the numeric
(hex or decimal) constants to interpret numbers that a Windows DLL
might return to a programming language not in the .NET family. These
numeric values may be enumerated in a speciifc .H file. If I have an
issue in finding a specific enumerated constant, I will start another
post.