Because Sender = ComponentVar is just too conservative
Because Sender = ComponentVar is just too conservative
if TBitBtn(Sender).Name='bWoodPallet'
then tPack.CarrierType:=ctWood
else if TBitBtn(Sender).Name='bPlasticPallet'
then tPack.CarrierType:=ctPlastic
else if TBitBtn(Sender).Name='pVendorPlasticPallet'
then tPack.CarrierType:=ctVendorPlastic;
if TBitBtn(Sender).Name='bWoodPallet'
then tPack.CarrierType:=ctWood
else if TBitBtn(Sender).Name='bPlasticPallet'
then tPack.CarrierType:=ctPlastic
else if TBitBtn(Sender).Name='pVendorPlasticPallet'
then tPack.CarrierType:=ctVendorPlastic;
I'm not quite sure I understand what you mean, Lars.
ReplyDeletePersonnaly I would have made a TBitBTn descendant with a CarrierType property. But what do you mean by Sender=ComponentVar ?
Olivier SCHWAB I think he means "if Sender = bWoodPallet then..." :-)
ReplyDeleteIn the dialog, the button is a variable, so you can compare the sender param with the variable, instead of casting sender to get the variable name and compare it to a string literal.
ReplyDeleteComponent descendants are such a pain for migrations. I don't use packages if I can avoid it. Too many dependencies.
Personally, I'd prolly use the Tag value to hold the constant instead - but that's not entirely safe as well, as even constants can change.
OMG got it, itwas so big that I did not see it.
ReplyDeleteLol , nice piece of Goldberg machine !
Lars Fosdal I agree. I don't like to extend a visual control just to keep a single value. I wish they added a "CustomValue : variant" instead of the Tag property.
ReplyDeleteLars Fosdal in fact , actually I don't use packages in Delphi. I find them too difficult to manage when using source code control and versioning . But maybe I miss something with packages usage.
ReplyDeleteIMO, that's a bad approach, what if someone calls
ReplyDeleteBtnInstanceClick(NIL);
?
I see no sanity check (:
Simon Stuart Next you'll be demanding ease of maintenance, elegant code, full test coverage... ;)
ReplyDelete