Databaser i BPL'er ...

Kan du komme med lidt fejlbeskrivelse? Kører du med autocreate på formene (det er en dum praksis undtagen ved TDataModuler) eller opretter du efter behov?

Har du ikke en fejlmeddelse :-)

Har du dine db-bpl liggende samme sted som din exe, når du kører runtime package, så kan du der hvor du sætter dit hak, også lave en liste med det bpl som IKKE bliver linket med i din exe, og som derfor skal være tilstede sammen med din exe.

HEJ,

Svar til HRC:  NEJ, det gør jeg ikke.

Kommer ud med en ACCESS VIOLATION AT ADDRESS xxxxxxx IN MODULE TESTPACKP.exe Read of Address yyyyyyy.

*TestpackP er navnet på min exe-fil. *


Svar til MARTINBLIND:  Jeg går ind i PACKAGE-boksen ( File / new/ OPTHER / PACKAGE  - faneblad DESCRIPTION ) og krydser af ved RUNTIME and DESIGNTIME (har prøvet DESIGNTIME alene - ingen forskel) og EXPLICIT REBUILD er også 'hakket' ....

Resten af "hakkerne" rør jeg ikke.

KR

ØH--

Glemte at sige, at i OPTIONS  / Directories / Conditionals sætter jeg stierne til mit bibliotek. (eks: e:\delphi7\TEST\TESTPACK\  --  hvor alle kildekoder ligger . )

KR

øhhh.... hvis du ikke har klikket på compile with runtimepackedes så er bpl filer ikke aktuelle.

prøv at søg info omkring hvad man gør med db i en dll, en bpl er samme princip, og afhængig af hvilken db du bruger kan der være nogle ting, evt. skal du bruge sharemem :-)

Hej,

Det der undrer mig såre, er at NÆSTEN uanset hvilken anden VISUEL komponent jeg sætter ind på BPL-formen, så virker det. Har prøvet at sætte FIL-OPEN DIALOG og FIL-SAVE-DIALOG (som danner kode), men ikke direkte synlige "beviser" på formen. Jeg kompilerer med de eksisterene opsætninger i PACKAGE-boksen, og eksekverer herefter min testenbde EXE og de fungerer helt perfekt.

Jegt ved ikke hvorfor specielt disse komponenter volder besvær.  Uden at lægge hovedet på blokken (dum ide, ja, man ku' næsten sige det var halsløs gerning !) mener jeg at kunne erindre at nogle dababasekomponenter er (mere eller mindre) camouflerede <D>-COM servere, men som sagt - jeg erindrer det ikke præcist. Kan du korrigere mig her ?

KR

hvikle db comp. bruger du og hvilken db ?

Hej,

Jeg bruger AbsDatabase (absolute Databe).

Men jeg har en klar fornemmelse at det ikke er der fejlen primært er. Jeg har prøvet at sætte EEN TDataSource (DB) på BPL-formen (KUN DEN ALENE), kompilere og køre MASTER-exe'n, som giver fejl (den tidligere nævnte). Jeg sætter ingen parametre på samme TDataSource overhovedet. Kompileringen synes at gå godt, men det er fra kaldet fra hovedhoved-rutinen i 'master-exen' fejlen opstår.

Ser sådan ud:

phm := LoadPackage(ExtractFilePath(ParamStr(0)) + 'TestPack1.bpl');
  if phm <> 0 then
      try
        @ExecFunct := GetProcAddress(phm,'Execute');
        if Assigned(ExecFunct) then
            begin
//            if ExecFunct('Tekst 1','Tekst 2','Tekst 3') = True then
              if ExecFunct(Tlist, 'Tekst 1','Tekst 2','Tekst 3') = True then
                  ShowMessage('True!')
              else
                  ShowMessage('False!');
            end
        else
          begin
              ShowMessage ('Execute routine not found!');
          end  {if assigned}
      finally
        UnloadPackage(phm);
      end                      {try / finally}
  else                        {if hpm<>0}
    ShowMessage ('Package not found');

og den fungerer.


Har søgt på nettet efter en forklaring på hvorfor det ikke virker, men har ikke fundet nogen endnu. Jeg ved der er noget med strenge (max. 256 tegn / som ved DLL'ere ) men det er ikke aktuelt her.

Men søger videre....

KR

der er også noget med nogle db'er, bla. havde BDE'en nogle ting man skulle.
Du kan prøve at søge efter en artikel fra delphi-magazine der handlene om at køre med packages som man loader manuelt som du gør, faktisk en ret interessant en af slagsen, mener det var nr. 30-40 stykker, et sommer nr så vit jeg husker, der var i hvertfald nogle "guldkorn" om bpl'er

Er du sikker på dit datamodul bliver oprettet (test med et ShowMessage(self.ClassName) i dens OnCreate)? Det er jo en slags skjult form. Enten skal den oprettes (og slettes) i main-formen eller den skal smides sammen mainformen i DPR-filen (men jeg har aldrig selv kørt med runtimepakker).

I øvrigt burde SharedMem ikke være nødvendig i runtimepakker. Er det ikke bl.a. derfor man lavede pakkerne som et alternativ til DLL?

HEJ HRC,

Jeg tror du er inde på noget i den rigtige retning.

I morges, inden jeg tog på job, prøvede jeg at lave følgende i BPL-formen:

(har ikke koden her (er på job), så den er baseret på min (dårlige !) hukommelse:

BEGIN
  ..
  TRY
    TESTForm.Create(...);
  ..

    DataSource := TDataSource.Create(..);


    DO SOMETHING... (fornuftigt !)
  ..
  FINALLY
   
    DataSource.Release;  // DataSource.Free;
   
    TESTFORM.Release;
  END;
END;


Exports
    Funktionsnavn;  (* SOM en DLL *)

BEGIN
END.

Kompilering gik igen OK, men kørsel fra kaldende MAIN-prgm giver samme ACCESS - fejl.

Checker senere i aften...


PS: Kører ikke med ShareMem.

KRistian

Nu er det pseudokode for ellers var der nok en syntaksfejl eller to...

Det giver fornuft for Mainformen kender ikke den objektinstans som din BPL-form har oprettet.
Jeg plejer at slette de globale variable som automatisk oprettes med formene (undtaget er dog mainformens) men her er det måske smart at bruge den på datamodulet, ligesom jeg har gjort det her i mit program (i DPR-filen):


Da den oprettes med application som ejer, stoler jeg på den frigives igen når programmet lukkes.

Det var martinlind der foreslog at bruge SharedMem.

Hej,

Tak for jeres svar.

Jeg skulle snakke med en "real-hardcore programmør" på jobbet i hovedkontoret i anden sammenhæng sent i går eftermiddag. Efter at have forklaret problemstillingen for ham (han er hard-C++-ore mand, ikke Delphi) lovede han, at han ville tænke lidt over det. 

Han ringede så her i formiddags, stillede nogle uddybende spøærgsmål (fy fa-bian (længe leve Pippi Langstrømpe..) - de var langhårede ) og tænkte så lidt igen.

Det bedste han kunne foreslå var at det hele laves som en COM /DCOM /MIdas (CDM) løsning, fordi du i en single- /fler-layered CDM løsning kan inkludere de moduler (ad hoc) som du (læs programmet) måtte have brug for. (altså en "slags DLL med mulighed for yderligere indlæsning af DLL'ere) ...

(AK ja på den gamle SPERRY-UNIVAC kunne vi i assembler programmering sætte en bit så kunne vi indexere indexeringen, som kunne indexere indexeringen ......  --->>  ) Men det er historie så det batter...

Så det klogeste jeg kan gøre nu er at hive lærebogen i COM/DCOM ned fra den støvede hylde, pudse læsebrillerne, starte kaffemaskinen med ÆGTE JAVA i realtime og blive MEEEEEEGEEET klogere.. Så det vil jeg.

KRistian

Lukker