Ted Lyngmo wrote:
enum bsType { bs4=4, bs5, bs6, bs7, bs8 }; // starting at 4
That enum WILL NOT work for a **published** property.
An enum used for a **published** property **MUST** start at 0 and have
sequential values. RTTI used by the DFM streaming system is simply not
rich enough to handle enums that do not follow this convention. This
is documented behavior.
You will have to change the bsType enum accordingly, and then map it to
the correct values when passing it to the COM port API (you don't need
to do this for your paType enum, as it already follows the required
convention, since the API parity values are defined as 0-4, but I
wouldn't suggest relying on that behavior), eg:
enum bsType { bs4, bs5, bs6, bs7, bs8 };
enum paType { paNo, paOdd, paEven, paMark, paSpace };
...
bsType __fastcall GetByteSize() { return
static_cast<bsType>(FSetup.ByteSize-4); }
void __fastcall SetByteSize(bsType Value) { FSetup.ByteSize =
static_cast<BYTE>(Value) + 4; }
...
paType __fastcall GetParity() { return
static_cast<paType>(FSetup.Parity); }
void __fastcall SetParity(paType Value) { FSetup.Parity =
static_cast<BYTE>(Value); }
...
__property bsType ByteSize = { read=GetByteSize, write=SetByteSize,
default=bs8 };
__property paType Parity = { read=GetParity, write=SetParity,
default=paNo };
An enum used for a **non-published** property, on the other hand, can
use whatever values you want, in whatever order you want, since such
properties are not tied to RTTI.
In the Properties editor, the ByteSize has a drop down, but the
content is garbled.
Yes, because RTTI doesn't work for enums that do not start with 0,
and/or are not sequential.
If I make the enum zero based and tweak the setter and getter, it
works ok.
Yes, that is what you **MUST** do in this situation.
Besides, it is good design anyway to not leak platform-specific
details. The actual API values should be hidden inside your
component's implementation code, where they belong when your component
translates from its own values to API values and back.
I also have an enum with predefined values for BaudRate and that list
is very long and filled with gaps so I'd rather not have to do a
translation table for it.
I would not suggest using an enum for that property. The API's
BaudRate is much more flexible than its ByteSize and Parity. The
actual BaudRate can be any user-defined value that the COM device
supports, it is not limited to just the 14 values that the API
pre-defines. Unlike ByteSize and Parity, which are limited to just a
few values, so an enum makes more sense for them.
I would use a plain 'int' for the BaudRate property, and then for added
convenience, I would create a custom property editor to display a
drop-down list for the pre-defined values, but still allow the user to
type in any value they want.
--
Remy Lebeau (TeamB)
Connect with Us