In het meest ideale geval zou je met modellen moeten werken. Modellen geven de inhoud van een userinterface aan. Als het model verandert, verandert de userinterface automatisch mee. Als er vanuit de userinterface acties plaatsvinden pas je het model aan en niet de userinterface.
Waarom is dit aan te raden? Event-afhandeling, applicatie logica en data worden zo gescheiden van de userinterface: Je kunt gerust een andere user-interface gebruiken voor hetzelfde model en events.
Hoe is dit concreet te vertalen in deze situatie?
Form1 heeft een bepaalde waarde nodig die aangepast kan worden. Deze waarde zit in een model. Liefst is dit gewoon een domein-object en geen String. Als er in de form op een bepaalde knop wordt gedrukt wordt er in de
gescheiden event afhandeling een nieuw model aangemaakt waarin alle mogelijke waarden zitten en een geselecteerde waarde: de huidige waarde in form1. form2 kan dit model gebruiken om eeb ComboBox te maken, maar dit mag ook een ander component zijn. Als form2 wordt gesloten wordt de huidig nieuwe geselecteerde waarde uit het model gehaald en in het model van form2 gezet

.
Helaas moedigen de .NET WinForms model gebaseerd werken absoluut niet aan

. Het is te hopen dat er spoedig een library komt on-top-of de WinForms die dit mogelijk maakt. Model gebaseerd werken is in simplistische gevallen nogal een overkill als de GUI library geen support voor model gebaseerd werken biedt. Als dit wel het geval is, kan het ook in eenvoudige situaties zelfs nog de meest handige keuze zijn

.
Als je de modellen weghaalt uit dit verhaal heb je een eenvoudigere oplossing die in dit geval wel goed bruikbaar is.