[Delphi8.NET]migratie programma's D4,5

[SilentStorm]

Ik ben bezig met het omzetten van een aantal programma's van delphi 4/5 naar delphi 8 voor .NET. De auteur van de originele programmatuur heeft bij het maken gekozen voor gemak: geen commentaar, documentatie en best wat geleende code (quickreport, trayicon, spinedits, etc). Ik maak al wat langere tijd aanpassingen aan het gehele programma, maar nu heeft de eigenaar besloten over te gaan naar delphi 8. Dit laatste om toekomstige aanpassingen wat te vergemakkelijken, een paar terugkerende bugs (met name met betrekking tot databasekoppelingen) te verhelpen en het ontwikkelproces ietwat te verduidelijken.

Het is allemaal wel te doen met "wat" tijd en moeite, maar ik loop een beetje tegen een paar heel simpele dingen aan, waar ik toch geen oplossing voor kan vinden. Waarschijnlijk kun kun je het volgende dan ook onder de 'simpele vragen' klassificeren. Ik hoop hier nog net dat beetje niveau onder te scheppen, dat het nog enig bestaansrecht heeft ;): Bij het compileren van welke unit dan ook, krijg ik de melding 'file not found: 'System.Drawing.dcuil'.

Het zou zosimpel moeten zijn een dergelijk bestand te includen in het searchpath of het via de uses clause aan te roepen dat ik de vraag bijna niet durf te stellen: Hoe kom ik van de fout af?

Een zoektocht op google op 'System.Drawing.dcuil' geeft een 3tal irrelevante pagina's; 'dcuil' een hoop meer, maar niemand lijkt een probleem vergelijkbaar met dat van mij te hebben. Misschien heb ik wat een verkeerde insteek?

Bij onze eigen search kwam ik op [rml][ Delphi] StrToInt() werkt niet?[/rml]. System.Drawing schijnt wel een bestand te zijn dat te 'usen' valt. Toch krijg ik weer hetzelfde probleem.

Op mijn harde schijf vond ik het bestand ook niet. Relevante andere bestanden (System.Drawing.dll bijvoorbeeld, zijn wel te vinden in 'C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\' en ik vind een 'System.Drawing.dcpil' in de \lib van delphi's installatie zelf. Het includen van voorgaande directories aan het searchpath maakt echter totaal niets uit.

Ik baal er zelf behoorlijk van dat zoiets schijnbaar simpels me nu al bijna een dag kost. Misschien kan iemand hier wat licht op de zaak schijnen, of een zinnig linkje posten?

[Creepy]

SilentStorm schreef op 09 augustus 2004 @ 16:05:
Ik ben bezig met het omzetten van een aantal programma's van delphi 4/5 naar delphi 8 voor .NET. De auteur van de originele programmatuur heeft bij het maken gekozen voor gemak: geen commentaar, documentatie en best wat geleende code (quickreport, trayicon, spinedits, etc). Ik maak al wat langere tijd aanpassingen aan het gehele programma, maar nu heeft de eigenaar besloten over te gaan naar delphi 8. Dit laatste om toekomstige aanpassingen wat te vergemakkelijken, een paar terugkerende bugs (met name met betrekking tot databasekoppelingen) te verhelpen en het ontwikkelproces ietwat te verduidelijken.

Bij Delphi 8 wordt Delphi 7 meegeleverd. Als je niet perse naar .NET over moet pak dan Delphi 7. Vanaf D4/5 is dat een stuk makkelijker migreren.
Dat je naar Delphi 8 over moet vanwege terugkerende bugs en het ontwikkelproces te verduidelijken is onzin. Het zijn onzin argumenten. Mochten het Delphi bugs zijn dan zijn die er waarschijnlijk in D6 en D7 wel uitgehaald. En als je Delphi 4 en 5 gewend bent dan is het makkelijker om te ontwikkelen in D7 dan in D8.

Voor de rest kan ik je helaas niet helpen.

[LordLarry]

Voeg System.Drawing aan je project via Add Reference.

Verder ben ik het wel met Creepy eens dat het geen sterke argumenten zijn om naar .Net over te gaan. Waarschijnlijk kost overgaan naar Delphi 7 je veel en veel minder tijd zodat je je op de echte verbeterpunten kan concenteren. .Net is wel het overwegen waard als je de conversie alvast wilt doen zodat je dat niet later in de toekomst nog eens wilt doen.

[SilentStorm]

Het idee om met delphi 7 te gaan werken is hier zeker een mogelijkheid. Ik heb het even met de eigenaar besproken en zoals het er nu uitziet gaan we met delphi 7 verder. Ik had uit de reclame van Borland begrepen dat eventuele delphi 7 code ook meteen met d8.NET uitvoerbaar moest zijn, mochten we het alsnog in .NET willen zetten (?).

Toch zou het fijn zijn (ook voor mensen die eventueel later over dit topic struikelen, om maar weer met een standaardopmerking te komen ) om nog een zinnige oplossing voor het bovenstaande te krijgen. Ik zal er zelf waarschijnlijk in de toekomst anders ook nog wel eens tegenaanlopen.

Add reference, doe ik nu

edit:
en dat was de oplossing

bedankt! Wat nog het stomste is, is dat ik ergens ook wel wist dat ik die assembly's ergens moet adden. Ik heb eerder al eens een .NET programma uitgerold bij iemand anders en dan is het ook noodzakelijk om die assemblies goed te zetten nja, heb het in ieder geval duidelijk nu

[ Voor 23% gewijzigd door SilentStorm op 09-08-2004 17:09 ]

[LordLarry]

Geen probleem.

Nee, Delphi 7 code is niet meer of minder makkelijk over te zetten naar Delphi.Net dan Delphi 4. In Delphi 7 kan je wel compiler warnings aanzetten die je waarschuwen voor code die niet te gebruiken is in .Net. Als je die allemaal oplost wordt het al weer makkelijker je programma om te zetten naar .Net. Het omzetten van je Delphi 4 code naar Delphi 7 is waarschijnlijk binnen een dag gepiept.

[semicolon]

Delphi 9 zal keuze bieden tussen .Net en de oudere, meer bekende Delphi talen.
Had dit gelezen in het .NET magazine die ik bij mijn Delphi 8 cd ontving, zal het stukje even opzoeken als ik het magazine nog vindt.

[alienfruit]

Nee, Delphi 9 bevat Delphi 9 .NET en Win32 en C#Builder in een. Overigens als je gebruik hebt gemaakt van alleen de std. componenten kun je nagenoeg 1-op-1 je Win32 programma overzetten naar VCL.NEt/.NET applicatie. Maar op het moment dat je 3rd party componenten gebruik dan wordt het een stuk lastiger.

[SilentStorm]

Even for the record, ik heb van het programma waar we de meeste problemen van verwachten alles intussen omgezet zonder al te veel problemen. Ik ben vandaag opgehouden tijdens het doorzetten van de databases naar interbase 7.1 (zou via gbak moeten volgens de manual) en verwacht eigenlijk nog weinig problemen. De meeste 3rd party componenten zijn vervangen door een nieuwere varianten. Behalve 3rd party software hoefde er sowieso maar een paar dingen aangepast te worden .