Board index » cppbuilder » Re: A problem with enumeration in property

Re: A problem with enumeration in property


2005-01-22 03:45:18 AM
cppbuilder0
Remy Lebeau (TeamB) wrote:
Quote
"David Erbas-White" < XXXX@XXXXX.COM >wrote in message
news:41f12990$ XXXX@XXXXX.COM ...


>I'll add that one of the reasons (IMHO) that Borland doesn't
>bother with this is because it appears that enums aren't present
>in Delphi. I immediately checked some of my other third-party
>components, and the values for various states within these
>components all have manually enumerated variables. This
>obviously 'solves' the problem, but eliminates the use of the enum
>keyword for the C++ side.


I disagree. Delphi does have a notion of enums, and there are enums in the
native VCL (TFontStyle, TBorderIcon, etc) that are declared using the 'enum'
keyword in the C++ header files for the VCL.

Let me rephrase that. I looked through several of my TurboPower
libraries, and MOST (not all) of the enumerations that are performed are
done manually. My assumption (and only an assumption) is that they did
it that way because of either compatibility issues, or because it wasn't
supported as well in Delphi.
I'll take a look at the TFontStyle item, because I'd like to see how
Borland handled them (i.e., are they int- or byte-wide). If they didn't
do anything 'special', then how does the linker determine what size they
are? If the VCL library has them as byte-wide, for example, then what
happens if I check the 'treat enums as ints' box? Conversely, if they
set them up as int-wide', what happens when I don't check the box?
That's really the crux of the issue here...
David Erbas-White
 
 

Re:Re: A problem with enumeration in property

Remy Lebeau (TeamB) wrote:
Quote


I disagree. Delphi does have a notion of enums, and there are enums in the
native VCL (TFontStyle, TBorderIcon, etc) that are declared using the 'enum'
keyword in the C++ header files for the VCL.


Upon further investigation, the examples you have given of enumerations
(TFontStyle, TBorderIcon, etc.) are all items that are used only within
'sets'. The definition for sets is that you can only have byte-wide
values (i.e., 0-255). Therefore, the 'set' definition overrides
whatever width may have been set for the stated enumerations, so the
problem doesn't exist.
If you have other examples of enumerations that are used directly in the
VCL that could assist with a better understanding of how to solve this
problem, I'd appreciate it (i.e., to find out how different libraries
could be used when the size of the enumeration is set differently in the
compile options).
David Erbas-White
 

Re:Re: A problem with enumeration in property

"David Erbas-White" < XXXX@XXXXX.COM >wrote in message
Quote
If you have other examples of enumerations that are used directly
in the VCL that could assist with a better understanding of how
to solve this problem, I'd appreciate it (i.e., to find out how
different libraries could be used when the size of the enumeration
is set differently in the compile options).
TCustomForm::WindowState uses an enum, TWindowState, as its property value.
No Set is involved.
Gambit
 

{smallsort}

Re:Re: A problem with enumeration in property

Remy Lebeau (TeamB) wrote:
Quote

TCustomForm::WindowState uses an enum, TWindowState, as its property value.
No Set is involved.


Gambit


Thanks much! I'll look into how they handle it.
David Erbas-White
 

Re:Re: A problem with enumeration in property

Remy Lebeau (TeamB) wrote:
Quote
"David Erbas-White" < XXXX@XXXXX.COM >wrote in message
news:41f16185$ XXXX@XXXXX.COM ...


>If you have other examples of enumerations that are used directly
>in the VCL that could assist with a better understanding of how
>to solve this problem, I'd appreciate it (i.e., to find out how
>different libraries could be used when the size of the enumeration
>is set differently in the compile options).


TCustomForm::WindowState uses an enum, TWindowState, as its property value.
No Set is involved.


Gambit


OK, I've reviewed the source code of the VCL, and here's what I see:
WindowState definitely is an enum, and doing some 'tests' on accessing
it and single-stepping through the CPU window shows that it is treated
as an 'int', even though it only has a few possible values.
Further inspection is a bit 'scary', though.
Bearing in mind that my Delphi is a bit rusty, inspection of the
relevant source files seems to indicate that MINENUM is set to 4
(although I could be mistaken). This is why the code (as inspected in
the CPU window) operates on a 4-byte value. However, the header file
for C++ indicates that the 'treat enum as int' is turned off with a
#pragma option, so this may not be true.
If it is true, then the VCL seems to treat it as an 'int', but the
header file says it is not. This is actually not (really) a problem,
because if the value is only treated as a byte value when it is returned
to a calling routine, that's okay. In other words, the 3-bytes at the
top of the register will be zeroed, but that's okay, because we don't
use them. It's only when we are expecting 4 bytes back, and only the
lowest byte is changed, that we have a problem.
It 'appears' at this point, that (in general) enumerations in the VCL
are treated as an int, but when used as part of a 'set' they are forced
to a single-byte value. When not used as part of a 'set', the fact that
they are an int becomes pretty irrelevant to the calling routine, so it
doesn't matter if the 'treat enums as ints' box is checked or not.
The only problem occurs in two cases: where a third party library does
NOT have the 'treat enums as ints' box checked, or when (in a
multi-module project) one module has it checked and the other doesn't.
In the latter case, I agree that it is the programmers
'problem/responsibility', but it generates a major conflict that 'ought'
(in my mind) be caught by the linker.
I do need to go back and check both my own code, and my use of third
party libraries, to see if they follow these rules. Part of the problem
(in my OWN code) is that some of the raw routines are from pre-C++ days
(C-only), and have a fair number of enumerations used in them. I need
to make absolutely sure that the third-party libraries are set for this
as well.
Thanks to all for your help.
David Erbas-White