DomNaarApps

Ge ziet niets over 't hoofd :-D Ge hebt helemaal gelijk! Is een 1-op-1-property, dus mag automatisch geconverteerd worden. In tegenstelling tot DwarsverdelingAantal, want daar is de property-naam verschillend (cq. AantalDwarsverdelingen in APPS).

Aangepast naar "Dwarsverdelingen te picken"

Als opmerking in de kantlijn (dus je moet niks aanpassen) : hier moeten we eigenlijk gebruik maken van het berekende HalffabItem en daarvan de (bewerkte) lengte opvragen. Nu staat er duplicate logica.
Maar ik geloof best, zonder het na te kijken, dat in deze klasse nog code staat die vertrekt van de ingegevenKenmerken i.p.v. halffabItem.

DwarsverdelingKleur zit volgens mij "impliciet" in de ConverteerGegenereerdeProperties()
hiervoor is geen "uitzondering nodig".
Tijdens de uitbreidingsfase en review lijkt het me handig om te zien dat beide properties zijn toegevoegd. Maar eenmaal in productie (en ondersteund door automatische testen) kan dit het standaard pad volgen.
Of zie ik iets over t hoofd?

Tekst correct?
Zonder kar --> geen vakken, right?

copy-paste typo (2x) :
#dim ... As MVX-kenmerken ??

copy-paste 2x zelfde

copy-paste 2x zelfde

Mijn eerste review-opmerking ging zijn : "In een AssertEquals-expressie zou geen $Select() mogen staan."
Dat topic wil ik eventueel nog met jou bespreken.

Door dit op te merken, viel m'n oog wel op een typo in bovenstaande lijn: RugBreedteX en in de $Select() staat BreedteM :-O

Bij voorkeur Z1 en Z2 verschillend kiezen.
idem voor X en Y

Uitsparing Breedte.M moet je verplaatsen naar Dubbele uitsparing.

Deze IF legt een onnodige dependency, en heeft geen meerwaarde binnen de converter.
Integendeel, bij uitbreiding voor LBX sifon of TBX sifon moet je hier iets toevoegen, terwijl de code binnen de IF toch "universeel" is.

Ook de MatKenmerken hebben property "NietMeeleveren", dus ik zou deze method wel laten oproepen, ook al is de impl dan enkel met de eerste en de laatste lijn : %New() en Quit.
Oftewel rechtstreeks in de method Converteer() , dan mag de commentaar hier volledig weg.

VH code conventions : VulAanMatKenmerken()

Als het object MatKenmerken één en dezelfde oref blijft (dus geen %Clone ofzo) dan is het niet nodig om de SetAt() te doen, want de pointer in de GekoppeldeKenmerken verwjist nog steeds naar hetzelfde object in memory.

Een kleine bedenking:
ik ben niet helemaal zeker of de method wel thuishoort in deze klasse, omdat die enkel geschikt is voor MatKenmerken.

Voorlopig is dit oké, en functioneel zeker geen probleem.
Ik wil niet verder uitweiden nu, over deze bedenking, dus enkel als review-opmerking, en om te vermijden dat we vanalles in deze klasse gaan steken dat niet voor alle IngegevenKenmerken van toepassing is.

Er is geen IF nodig, want :
if "true" or "false" --> altijd dus
:-P