[VB6] [VB.NET] .NET Forms gebruiken om VB6 Forms te openen

[3raser]

Ik onderhoud een grote VB6 applicatie welke aanpassingen nodig heeft. Nu wil ik het liefst zoveel mogelijk van deze wijzigingen in VB.NET maken zodat ik mij langzaam aan kan focussen op het migreren van de volledige applicatie naar VB.NET. "Langzaam" moet hierbij zeer letterlijk worden genomen. Het is de bedoeling dat de applicatie mondjesmaat wordt gemigreerd waarbij de werking continu gegarandeerd blijft. Je kunt dit zien als stapsgewijs ieder form omzetten en werkend maken in een VB.NET COM Library die vervolgens weer in de bestaande VB6 code aangeroepen kan worden. Dit brengt echter de nodige problemen met zich mee en ik hoop dat iemand hier ervaring mee heeft en mij een duwtje in de goede richting kan geven.

Probleem: Vanuit een .NET Form lijkt het onmogelijk om een werkend VB6 Form te openen.
Ik heb een .NET COM Visible Library gemaakt waarin een form is verwerkt. Deze form heeft een knop die als doel heeft een bestaand VB6 form te openen. Omdat ik vanuit .NET niet rechtstreeks naar VB6 kan verwijzen heb ik een event aangemaakt die wordt getriggerd als er op de knop wordt gedrukt. In VB6 maak ik een event handler die reageert op het betreffende event en vervolgens het juiste VB6 form opent. Dit geeft wisselende resultaten afhankelijk van de threads in de .NET library.

Zelfde thread: Als ik de callback stuur vanuit de thread waarmee het .NET form is geopend dan krijg ik zowaar een VB6 form te zien. Daar is ook alles mee gezegd want het form werkt niet. Het venster reageert nergens op en de inhoud die ik via het Onload event van het form zelf toevoeg ontbreekt. Ook het drukken op knoppen werkt niet. Het lijkt er zogezegd op dat alle events in het VB6 form niet functioneren. De VB6 debugger geeft hierbij geen enkele fout aan.

Nieuwe thread (via Threading.Thread of een BackgroundWorker): Als ik de callback stuur vanuit een nieuwe thread die door het .NET form is gestart dan wordt de VB6 code uitgevoerd totdat deze bij het openen van het VB6 form uit komt. De VB6 debugger geeft de volgende foutmelding: Invalid procedure call or argument

Het vreemde hierin is ook dat in beide gevallen het openen van een Msgbox in VB6 wel weer werkt.

Na flink zoeken kwam ik uit op de Microsoft Interop Form Toolkit. Deze wordt al lang niet meer ondersteund maar is met wat omwegen werkend te krijgen in Visual Studio 2019. Deze kit maakt het mogelijk om .NET forms "compatible" te maken met VB6 zodat je de forms rechtstreeks vanuit VB6 kan openen. Ik heb dit getest en de toolkit doet wat het belooft. Echter, het probleem blijft bestaan. Events of callbacks vanuit het .NET form werken prima maar kunnen geen VB6 Forms aansturen.

Ik vermoed dat het iets te maken heeft met het werken in een andere thread. Dit lijk je ook te kunnen zien in de taakbalk omdat het .NET form een eigenlijk applicatie-plekje krijgt toegewezen ondanks dat het een Modal Form is. Vergelijk dit met een standaard VB6 Modal Form en je zal zien dat die nooit een eigenlijk taakbalk vermelding krijgen. Een andere aanwijzing is dat breakpoints in VB6 worden geraakt maar dat die de VB6 UI niet pauzeren. In VB.NET kun je ook de UI niet aansturen vanuit een andere thread dus misschien kun je het daar mee vergelijken. De vraag is dan hoe ik de VB6 UI thread kan invoken, als dat al kan.

Ik heb naar mijn idee alle StackOverflow en vbforums berichten al gelezen die hier iets mee te maken hebben. De meeste vragen gaan echter over de mogelijkheid om .NET forms te openen. Niet over de feedback van die forms richting de aanroepende VB6 applicatie. Ja, events en callbacks zijn mogelijk maar die kunnen geen VB6 Forms aansturen. En dat is nu net wat ik nodig heb. Er zijn echter heel veel topics met vergelijkbare keywords dus misschien heb ik de juiste zoekterm nog niet gevonden.

Mijn grote vraag is dus: Hoe kan ik vanuit een .NET Form een VB6 Form openen die ook daadwerkelijk functioneert?

[RobIII]

Pfoe, ik denk dat je 't jezelf vooral moeilijk maakt. Waarom bouw je niet gewoon 'parallel' aan de VB6 versie de nieuwe .Net versie? Dan heb je alleen tijdens de ontwikkelperiode van de nieuwe applicatie dat je eventuele bugfixes / features 2 keer moet bouwen maar de tradeoff is dat je geen Frankenstein applicatie loopt te onderhouden die een mix is van prehistorische zaken en 'moderne' zaken.

Overigens - als ik zo vrij mag zijn nog een advies te geven: Als je toch gaat 'omscholen' naar VB.Net, probeer dan eens C#. Ik kom zelf uit een VB6 achtergrond en heb daarna VB.Net gedaan en toen vrij vlug doorgestoten naar C#. Als ik jou was zou ik proberen die VB.Net stap over te slaan; niet dat er iets mis is met VB.Net, maar er is nou eenmaal véél meer te vinden voor C#. Uiteindelijk is 't allemaal .Net natuurlijk; het enige verschil is de VB.Net vs C# syntax, maar ik denk dat je jezelf een plezier doet om die stap wel te maken. De leercurve voor C# is niet bijster hoog (en maar marginaal - if at all - hoger dan die voor VB.Net).

[ Voor 5% gewijzigd door RobIII op 09-06-2022 14:05 ]

[3raser]

@RobIII Bedankt voor je reactie. De reden waarom ik geen nieuwe applicatie kan maken is omdat het zwaar verweven is met functionaliteiten uit de bestaande applicatie. Ik zou dan grote delen van de bestaande VB6 applicatie eerst moeten herschrijven in .NET en dat is nu net het probleem. Als het herschrijven eenvoudig was dan had ik niet nagedacht over deze Franckenstein oplossing. Daarnaast denk ik dat het er voor de klant niet overzichtelijker op wordt als ze bepaalde taken moeten uitvoeren in een tweede applicatie. Dus als het op de manier kan zoals ik bedacht heb dan zou mij dat zeer goed uit komen. En tot nu toe kwam ik heel ver. Helaas liep ik tegen dit struikelblok aan.

Wat betreft omscholen, daar is het al te laat voor . Ik werk al jaren in VB.NET (voor andere applicaties). Ik kan mezelf ook een beetje redden in C# maar volledig overstappen is een brug te ver. Misschien dat een nieuw project in C# eens de moeite zou zijn om wat meer gewenning te kweken.

[RobIII]

3raser schreef op donderdag 9 juni 2022 @ 14:37:
Daarnaast denk ik dat het er voor de klant niet overzichtelijker op wordt als ze bepaalde taken moeten uitvoeren in een tweede applicatie.

Die kunnen toch gewoon de oude blijven gebruiken?

[3raser]

RobIII schreef op donderdag 9 juni 2022 @ 14:38:
[...]

Die kunnen toch gewoon de oude blijven gebruiken?

Ah, ik las je bericht verkeerd. Ik dacht dat je bedoelde dat ik de nieuwe functies in een nieuwe applicatie zou bouwen. Maar je bedoeld dat ik een complete rewrite maak terwijl de oude applicatie ook nog wordt onderhouden. Dat is echt geen doen. We praten hier waarschijnlijk over een meerjarenproject. En dat betekend dat ik fulltime met die rewrite bezig zou zijn. Dat is onmogelijk want daar hebben we de tijd niet voor. En er een FTE voor inzetten kan financieel gezien niet. Dit is een maatwerk applicatie en de klant heeft echt geen interesse om een rewrite te bekostigen.

[RobIII]

Dan lijkt 't me een gevalletje:



Ik denk persoonlijk dat je meer ellende op de hals haalt met 't onderhouden van de Frankenstein oplossing dan dat 't oplost. Maar goed, dat kan ik op afstand natuurlijk niet zien.

[3raser]

RobIII schreef op donderdag 9 juni 2022 @ 14:48:
Dan lijkt 't me een gevalletje:

[Afbeelding]

Ik denk persoonlijk dat je meer ellende op de hals haalt met 't onderhouden van de Frankenstein oplossing dan dat 't oplost. Maar goed, dat kan ik op afstand natuurlijk niet zien.

Cheap + Good is the way. En dat door met .NET libraries VB6 te gaan "upgraden". Dus daar ga ik me voor nu op focussen. Vandaar de vraag in de startpost.

Ik help mijzelf daar vooral mee door eindelijk wat in .NET te kunnen doen voor dit project. Ik wil niet voor eeuwig in VB6 blijven hangen. Daarnaast, als het echt gaat werken zoals ik het voor ogen heb valt het naar mijn idee nog wel mee met die Franckenstein oplossing.

[Daos]

Ik zou het andersom proberen. De oude vb6-schermen aan de praat zien te krijgen in een vb.net-project. Je hebt dan een nieuw project waar dan langzaamaan de oude meuk uit verdwijnt. Even snel zoeken geeft al een voorbeeld: https://www.codeproject.c...-form-in-NET-applications

Ook had microsoft vroeger een conversie-tooltje. Ik heb daar zelf geen ervaring mee, maar het lijkt mij zeker iets om te proberen. Als je die nog kan vinden. Misschien kan je ook alternatieven proberen. Toen ik zocht naar het ms-tooltje kwam ik deze concurrent tegen: https://www.mobilize.net/...mpanion-vs-upgrade-wizard

[Lethalis]

@3raser
Op mijn werk gebruiken we o.a. de Interop Forms toolkit:

http://froque.github.io/V...op%20Forms%20Toolkit.html

We hosten daarmee .NET modules in het oude VB6 project. We hebben daarnaast gelukkig ook een nieuw project gemaakt een jaar of 7 geleden, maar voor bestaande klanten wordt het VB6 project nog in leven gehouden (het ligt wel op de IC aan de zuurstof... het wordt gemaakt met een Windows 7 virtuele machine die heilig is, want op nieuwe machines lukt het niet meer om alles te installeren).

Sommige onderdelen, zoals koppelingen met externe partijen, zijn dus in .NET gemaakt en worden simpelweg vanuit VB6 geladen met de Interop Forms toolkit.

Voor de rest laat ik dit zoveel mogelijk aan een collega van mij over, dus vraag me niet teveel erover Oude meuk

[ Voor 10% gewijzigd door Lethalis op 09-06-2022 19:59 ]

[Lethalis]

RobIII schreef op donderdag 9 juni 2022 @ 14:04:
Overigens - als ik zo vrij mag zijn nog een advies te geven: Als je toch gaat 'omscholen' naar VB.Net, probeer dan eens C#.

Dit inderdaad.

Al is het alleen maar zodat je niet achteraf in het nieuwe project nog uit frustratie Option Strict gaat aanzetten en erachter komt dat het nieuwe project ook een drama is geworden (been there, done that).

[Lethalis]

3raser schreef op donderdag 9 juni 2022 @ 14:37:
Wat betreft omscholen, daar is het al te laat voor . Ik werk al jaren in VB.NET (voor andere applicaties). Ik kan mezelf ook een beetje redden in C# maar volledig overstappen is een brug te ver.

Tenzij je 60+ bent en dit werk alleen maar tot het pensioen wil volhouden, is het niet te laat.

[farlane]

Lethalis schreef op donderdag 9 juni 2022 @ 19:50:
[...]

Tenzij je 60+ bent en dit werk alleen maar tot het pensioen wil volhouden, is het niet te laat.

Met de pensioenleeftijden in Nederland heb je dan nog steeds ruim voldoende tijd en plezier met het keren van C# medunkt.

Niet dat ik me aangesproken voel.

[CodeCaster]

Men heeft het hier over schermen en forms, maar de designs heb je natuurlijk in no-time geconverteerd of opnieuw gemaakt volgens nieuwe standaarden. Of dat nou WinForms, WPF of MAUI is.

Wat de volledige omzetting hoogstwaarschijnlijk tegenhoudt, is hoe de rest van de applicatie in elkaar zit, op de typische Visual Basic-manier.

Staan de forms vol met data-componenten, met bijvoorbeeld hele lappen aan queries in SqlCommand-componenten? Bevatten click-events honderden regels code die alles en nog wat doen, andere forms aanroepen, data overal en nergens vandaan halen en dergelijke? Ja, dan wordt het lastiger om het over te gaan zetten naar iets moderns.

Inhoudelijk gok ik dat je problemen komen door het hebben van twee message loops in één applicatie. Maar maak even een minimale repro waarin je wat relevante code laat zien?

[ Voor 17% gewijzigd door CodeCaster op 11-06-2022 10:56 ]

[Lethalis]

farlane schreef op zaterdag 11 juni 2022 @ 10:42:
[...]

Met de pensioenleeftijden in Nederland heb je dan nog steeds ruim voldoende tijd en plezier met het keren van C# medunkt.

Niet dat ik me aangesproken voel.

Ik kan me voorstellen dat je na je 60ste niet zoveel zin meer hebt om iets nieuws te leren. Collega van mij gaat dit jaar met pensioen en die heeft na VB.Net nooit meer C# geleerd bijvoorbeeld.

Iedereen jonger dan 50 kan het iig wel.

[Lethalis]

CodeCaster schreef op zaterdag 11 juni 2022 @ 10:49:
Men heeft het hier over schermen en forms, maar de designs heb je natuurlijk in no-time geconverteerd of opnieuw gemaakt volgens nieuwe standaarden. Of dat nou WinForms, WPF of MAUI is.

Lol de grootte van de applicatie speelt ook mee. Op mijn werk hebben we er meerdere jaren aan besteed om een nieuwe versie te maken. Ging om meer dan 150 schermen met tig controls (van VB6 naar .NET WinForms).

Overigens is die 3 jaar voor de hoofdfunctionaliteit, zodat het op de markt kan komen. Daarna komen nog vele jaren van verfijning, alsnog schermen erbij bouwen die lagere prio hadden etc.

De WinForms versie wordt nog steeds elke week aan gewerkt, 7 jaar later. In totaal wordt er dus al 10 jaar aan gewerkt.

Om nog maar niet over ons groothandelspakket te praten... daar zijn we al rustig 20 jaar mee bezig Maar dat was gelukkig meteen in .NET gemaakt.

Inmiddels ben ik met een prototype in Angular bezig voor het groothandelspakket. Als dat project serieuze vormen aan gaat nemen, zit ik tegen een gigantisch project aan te kijken. Dat gaan we dan ook zo maken dat het met dezelfde database werkt, zodat je het in eerste instantie naast het oude pakket kan draaien.

Anders is het überhaupt kansloos.

[farlane]

Lethalis schreef op zaterdag 11 juni 2022 @ 11:19:
Ik kan me voorstellen dat je na je 60ste niet zoveel zin meer hebt om iets nieuws te leren.

Ik niet eerlijk gezegd, leren blijft altijd fijn.

Collega van mij gaat dit jaar met pensioen en die heeft na VB.Net nooit meer C# geleerd bijvoorbeeld.

Jammer voor hem, hij had zichzelf er denk ik een groot plezier mee gedaan.

Iedereen jonger dan 50 kan het iig wel.

Regelrechte leeftijdsdicriminatie.


Ik zet het wat zwaar aan, maar deze op/instelling is dus een van de oorzaken dat mensen na hun 50e een stuk moeilijker werk kunnen vinden, ondanks de "krapte op de arbeidsmarkt".

[Lethalis]

farlane schreef op zondag 12 juni 2022 @ 09:49:
[...]
Jammer voor hem, hij had zichzelf er denk ik een groot plezier mee gedaan.

Hij had er vooral zijn jongere collega's een plezier mee gedaan. Hem boeit het echt niet meer

Regelrechte leeftijdsdicriminatie.

Het is gewoon een observatie. Niet iedereen is zo uiteraard, maar momenteel is de ratio 2/3 als ik om mij heen kijk.

Oftewel: 2 van de 3 vinden het best zo en blijven gewoon doen wat ze doen, zonder nieuwe ontwikkelingen te volgen. Sterker nog: ze installeren niet eens Windows 11 of Visual Studio 2022. Ze blijven gewoon met de oudere versies werken.

Ik zet het wat zwaar aan, maar deze op/instelling is dus een van de oorzaken dat mensen na hun 50e een stuk moeilijker werk kunnen vinden, ondanks de "krapte op de arbeidsmarkt".

Dat is ook zo. Overigens ook iets waar ik mij zorgen om maak. Ik ben iemand die in principe altijd de nieuwste ontwikkelingen volgt, maar ik merk zelfs op mijn 41ste al dat het lastiger wordt.

Deels door tijdgebrek, omdat je met een jong gezin vaak 's avonds doodmoe bent en in het weekend geen tijd hebt... maar deels ook omdat die hersencellen langzaam maar zeker afsterven Ik ben vergeetachtig geworden, moet meer moeite doen om iets nieuws te leren dan toen ik 25 was.

Praat ik dan met mijn oudere collega's die soms nog blij zijn dat ze het kantoor kunnen vinden dan schijnt dat normaal te zijn Gezamenlijke conclusie is wel dat we allemaal chronisch vermoeid zijn.

Maar goed... ik push mezelf nog wel om volop met Angular, Typescript en .NET 6 te werken. En zolang ik in het Microsoft ecosysteem zit, installeer ik ook de nieuwste shit... ongeacht wat ik ervan vind, ik moet toch bijblijven.

Dus waar ik meerdere tabs met Powershell open heb staan in Windows Terminal, zitten sommige collega's nog naar cmd.exe te staren (of erger nog, als ergens geen gui voor is dan willen ze het niet gebruiken... veel succes zulke mensen aan Angular te krijgen, die verwachten een "new component wizard" ofzoiets ipv dat ze een commando moeten intikken)

PS
Als iemand van mijn werk dit leest, sorry alvast

[ Voor 14% gewijzigd door Lethalis op 12-06-2022 11:12 ]