Results 1 to 13 of 13

Thread: d2007 units gebruiken in D7

  1. #1
    Senior Member
    Join Date
    Mar 2002
    Location
    Edam
    Posts
    426

    d2007 units gebruiken in D7

    hallo,

    misschien een rare vraag: kan je D2007 functionaliteit gebruiken in D7 of andersom?
    ... ik heb een grote D7 applicatie en daar moet een klein beetje extra bij dat alleen in D2007 beschikbaar is. Helemaal omzetten naar d2007 lijkt geen optie omdat sommige delen alleen nog als dcu beschikbaar zijn ...
    Wat is de makkelijkste manier om in D2007 gemaakte functionaliteit toe te voegen aan D7 of andersom?.. iemand een idee?

  2. #2
    Als je de source hebt, dan kun je die gewoon gebruiken, mits je natuurlijk alleen features gebruikt die ook in Delphi 7 beschikbaar zijn. Eventueel kun je die zelf schrijven, want er zijn vrij weinig taalfeatures toegevoegd tussen die twee versies. De verschillen beperken zich vooral tot de VCL. Delphi 7 code in Delphi 2007 gebruiken is haast nooit een probleem. In een enkel geval kom je misschien een depricated functie tegen, of zijn er dingen verplaatst naar andere units, maar niets onoverkomelijks.

    Dcu's gebruiken is geen optie. Die zijn volgens mij niet compatible. Ik zou er voor zorgen dat je zo snel mogelijk van die dcu's afkomt. In gevallen waar het echt geen optie is, zou je misschien een dll kunnen maken waar je bepaalde functionaliteit in stopt. Die kun je dan beschikbaar maken via export functies, of misschien zelfs als COM object.

    Maar dat lijkt me allemaal een hoop werk, terwijl het eigenlijke probleem is dat je geen source hebt. Als je dat probleem oplost is het migreren van Delphi 7 naar 2007 waarschijnlijk redelijk eenvoudig.
    1+1=b

  3. #3
    Quote Originally Posted by GolezTrol View Post
    Eventueel kun je die zelf schrijven, want er zijn vrij weinig taalfeatures toegevoegd tussen die twee versies.
    Operator overloading, class helpers, records met methods, nested classes, for-in loop, generics ook dacht ik.
    DeX 3 Delphi := The ease of VB with the power of C; Zoekt en gij zult vinden

  4. #4
    Al in 2007? Dacht dat het meeste daarvan pas in 2009 kwam?
    1+1=b

  5. #5
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Henkie View Post
    Operator overloading, class helpers, records met methods, nested classes, for-in loop, generics ook dacht ik.
    * inline en nog wat andere zeldener gebruikte modifiers dacht ik. (sealed, final?)
    * strict *
    * class const, var enz

    Niet op de lijstjes van Nick H. vziw:

    * modifiers voor units. (hele units deprecated flaggen. D2007 of D2009 voegt daar ook nog de mogelijkheid tot een msg aan toe)

    -------

    Goleztrol: generics is D2009 vziw, de rest van Henkies lijst is D2006+ vziw. D2007 heeft niet veel extensies tov D2006 want het compiled unit formaat bleef hetzelfde/compatible. (is meer een Vista update)
    Last edited by marcov; 11-Feb-10 at 11:38.

  6. #6
    Maar gelukkig is er zowat niemand die dat gebruikt, dus met een beetje geluk compileert het gewoon
    1+1=b

  7. #7
    Senior Member
    Join Date
    Mar 2002
    Location
    Edam
    Posts
    426
    ....het probleem is uiteindelijk niet zozeer de source. Die is er gewoon en op wat details na blijkt dat die probleemloos kan worden gebruikt in d2007.
    Het feit is meer dat er thirdparty vcl's zijn gebruikt waarvan alleen de dcu's aanwezig zijn en waarbij d2007 begint te vragen om het .pas file. (nb: opnieuw aanschaffen is geen optie).

    De functionaliteit die die thirdparty vcl gebruikt zit weer wel keurig verpakt in aparte units. Het hergebruik van een unit zou het probleem dus verhelpen...

    Afgaande op verschillende reacties lijkt het maken van een dll van een unit dé manier om deze, min of meer versie onafhankelijk, beschikbaar te maken . Resten slechts twee vragen:
    1. hoe maak je een dll van een unit en hoe gebruik je die ( daar is natuurlijk al heel veel over geschreven maar tips zijn welkom)
    2. "welke kant uit" is de beste oplossing... de in D7 gebruikte units zijn formless (of hoe je dat ook noemt) .. je stuurt er iets heen en er komt een antwoord terug .... maar er zijn meerdere units. De extra functionaliteit die alleen met d2007(+) beschikbaar is zit maar in een enkele unit (dus zou veel minder werk zijn) maar geeft een meer complex resultaat ... kan een dll zoiets als een class teruggeven of mogelijk zelfs een component?

  8. #8
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Voor cross-Delphiversie en cross-compiler/platform(*) doeleinden is alles wat niet met delphi meegeleverd wordt is source. Dus ook 3rd party componenten.

    Dus je hebt OF D2007 dcus nodig voor die componenten, OF de _complete_ source, zodat je ze zelf kan bouwen (en het is verstandig daar bij aankoop op te letten!)

    Als opnieuw aanschaffen geen optie is, heb je een absoluut gigantisch probleem.

    De D2007 code in een DLL stoppen is een mogelijkheid, maar riskant. De enige veilige manier is een totaal C compatible interface erover heen te leggen. Geen classes, geen strings geen dynamic arrays en de DLL freed geen geheugen dat de exe alloceert en andersom.

    Er zijn tussenvormen, maar dat is dansen op een koord. Je moet dan echt _heel_, _heel_ goed weten wat je doet. En de doendelijkheid hangt van de aard van de te importeren functionaliteit af.

    Misschien is het verstandig als je wat specificieerd wat je uit D2007 nodig hebt. (als het iets is uit het database framework, of iets anders dat "integreert" met de VCL, dan vergeet het maar).

    (*) denk dan aan Kylix, .NET maar ook FPC/Lazarus en de komende cross- support in D2011.

  9. #9
    Classes en components kun je niet zomaar teruggeven. Om dat te doen moet je gebruikmaken van packages. Dat zijn speciale dll's die wel objecten (en strings!) met elkaar kunnen delen. Maar dat werkt ook niet tussen verschillende Delphi versies. Bij het compileren bepaalt de compiler namelijk of een stuk code wel of niet meegecompileerd moet worden (omdat het aldanniet in een package beschikbaar is). Daarvoor moet je compiler dus wel beschikken over de code of de dcu, en daarbij heb je dus nog steeds hetzelfde probleem.

    Het eenvoudigst kun je je objecten voorzien van interfaces. Die kun je namelijk wél doorgeven. Je kunt er voor kiezen om een volledige COM dll te maken (dat is ook wel even wat werk), maar volgens mij is het ook mogelijk om export functies te maken die een bepaalde interface teruggeven.

    De stappen zijn in dat geval:
    - Maak een aparte unit voor deze interfaces, die heb je nodig in beide applicaties
    - Voorzie alle objecten die je wilt delen van interfaces, schrijf eventueel een wrapperobject dat de interface implementeert en de andere objecten aanroept
    - Schrijf één of meer functies die zo'n interface teruggeven
    - Exporteer deze functies in een dll.

    Misschien wil één van de (andere ) guru's hier nog even op schieten, want ik weet niet of er nog pitfalls zijn bij deze oplossing. Ik zou in ieder geval even een klein testje maken om te zien of het een oplossing is waar je je in kunt vinden.

    Afhankelijk van de omvang van je project zal het sowieso best even wat werk zijn.

    De beste tip blijft toch: Zorg dat je de source te pakken krijgt, want met die dcu's ga je vroeg of laat in de problemen komen.
    1+1=b

  10. #10
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Goleztrol:
    Packages zijn niet meer dan het splitsen van een programma in meerdere delen. Logisch gezien (op programma niveau) zit een BPL dichter bij statisch inlinken in de .EXE dan een DLL. Het feit dat het in een aparte file zit "helpt" weinig voor cross-versie redenen.

    Interfaces kan, maar waarschijnlijk alleen de COM compatible subset, en bij voorkeur over COM omdat af te dwingen.
    Zo gauw je delphi functionaliteit gaat gebruiken zit je weer met het probleem dat je twee runtimes, memmanagers, VMTs enz hebt. Ik ben echter geen sharemem expert (maar weet wel dat dit minder zaligmakend is dan veel mensen denken)

    Er zijn hacks mogelijk (als je b.v. weet in hoeverre het D7 en D2007 class model hetzelfde is), maar ik zou me daar zelf niet eens aan wagen, laat staan dat ik dat mensen die er geen ervaring mee hebben dat zou aanraden. Het zou wel zo ongeveer moeten werken, als je weet wat je doet, maar het vereist nogal wat kennis en debug ervaring om dit werkend te krijgen en houden.

  11. #11
    Senior Member
    Join Date
    Mar 2002
    Location
    Edam
    Posts
    426
    ... waar het om gaat is een tamelijk omvangrijke gis-applicatie gemaakt in d7. Daarin is als een van de laatste features de mogelijkheid aangebracht om de query resultaten niet alleen in standaard gis-kaarten weer te geven maar ook op tabblad met een google map. Werkt allemaal keurig: kleurige markers en polygonen met een ballontekstje alom....de resultaten zijn alleen wat de applicatie betreft "write only". Het toevoegen van de mogelijkheid om informatie van de googlemap te gebruiken in de applicatie (bv via het aanklikken van een marker de bijbehorende database informatie beschikbaar maken) zou de functionaliteit enorm vergroten. Dit blijkt in d2007 eigenlijk een fluitje van een cent maar het lukt niet goed in d7 (lees de van het web geplukte code voor active javascripting krijg ik niet werkend in d7)

  12. #12
    Quote Originally Posted by marcov View Post
    Goleztrol:
    Packages zijn niet meer dan het splitsen van een programma in meerdere delen. Logisch gezien (op programma niveau) zit een BPL dichter bij statisch inlinken in de .EXE dan een DLL. Het feit dat het in een aparte file zit "helpt" weinig voor cross-versie redenen.
    Dat weet ik en schreef ik ook. Het leek me daarom juist handig om te noemen. Beetje raar als wij zeggen dat je componenten niet in een dll kunt stoppen, en Willem zich na wat Googlen blind gaat staren op de mogelijkheden van packages

    Quote Originally Posted by marcov View Post
    Interfaces kan, maar waarschijnlijk alleen de COM compatible subset
    Dat is waar en heb ik verzuimd te vertellen. In Delphi kun je components, strings en meer in een interface stoppen, maar dat werkt niet in de oplossing die ik aandroeg. Je kunt inderdaad alleen de COM compatible dingen gebruiken, dus de simple types, BSTR voor strings, OleVariants en andere interfaces die hier ook aan voldoen.
    Misschien dat calling convention nog een rol speelt, maar ik geloof dat interfaces van zichzelf al stdcall zijn. Weet jij dat, marcov?
    1+1=b

  13. #13
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Nee. In headers worden alle interface declaratie methods apart met stdcall/safecall aangemerkt. Kijk maar in een activex unit oid.

    COM is overigensvaak ook safecall, nast stdcall (safecall=stdcall+ automatische support voor COM excepties). Dat vrijwel alle COM methodes een hresult terug geven heeft daar (exceptie support) ook mee te maken.

    En het COM interface gebeuren vereist dat je alles ook goed doet. Dus de BSTRs via COM compatible methodes alloceren (niet via de delphi mgr en dan in een bstr proppen) enz.

    Maar goed, ik heb hier al een half jaar een stapel COM boeken liggen die ik nog moet lezen om de fundamenten onder de knie te krijgen. Maar ja, tijd he. COM is niet relevant voor werk, dus is het hobby (FPC implementatie)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •