Ted Lyngmo wrote:


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.


Yes, because RTTI doesn't work for enums that do not start with 0,
and/or are not sequential.

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

Ted Lyngmo wrote:


Yes, it can, and I already explained how - make the property use an
integer type so the user can assign whatever value they want, and then
create a custom property editor to allow the user to select from
pre-determined values at design-time.


I would stick with the enum approach for the ByteSize and Parity
properties, since their allowed values are limited. If the user wants
to assign a numeric value dynamically, let them do their own casting in
their own code to ap their calculated values to your enum values.


In this case, I would:

- create the property with an 'int' data type

- derive a class from TIntegerProperty, overriding the virtual
GetAttributes() method to include the paValueList flag in addition to
the default flags, and overriding the virtual GetValues() method to
provide the desired pre-defined values.

- register the editor class for the property using the
RegisterPropertyEditor() function in a design-time package (can't be
called in a runtime package, like RegisterComponents() can).

--
Remy Lebeau (TeamB)

Ted Lyngmo wrote:


Because it really is an 'unsigned char'. That is the actual data type
that uint8_t is an alias of.

--
Remy Lebeau (TeamB)