"Thomas Eg Jørgensen" <tejo03@kom.auc.dk> wrote in message
news:loA8c.638$E93.217@news.get2net.dk...
>
> > Pointerne, dvs PChar'erne peger jo på ingenting, og derfor kommer der en
> > accesviolation. Prøv at lade dem pege på et område i hukommelsen :
> >
> > getmem(sendbuf,255);
> > getmem(receivebuf,255);
> > res:=OpSndRcvCl(sendbuf, @receivebuf);
>
> Well, sendbuf fylder jeg op med:
> strpcopy(MinStreng, sendbuf);
> så den burde vel være ok?
OK - det så jeg ikke.
> Og Receivebuf sender jeg jo som @Receivebuf til funktionen så jeg gik
> sådanset ud fra at den importerede funktion ville ændre addressen på
> pointeren til at pege på de returnerede data. Derfor burde det ikke være
> nødvendigt at allokere plads til den, eller?
Det mener jeg som udgangspunkt man skal forvente. Det er f.eks gennemgående
i windows API'et, at man skal allokere plads i de variable som funktionerne
skal kopiere data over i - typisk skal man endda angive hvor meget plads der
er til rådighed. Det er ikke API'ets opgave at instantiere objekter, oprette
pointere etc.
> Jeg prøvede naturligvis alligevel, men der kommer stadig access
violation
>
> Den access violation opstår også i den importerede DLL-fil:
> "Access violation at address 100030F4 in module 'tpmteccomapi.dll'. Read
of
> address 00C78000."
> Har det nogen betydning?
Det er svært at vide. Jeg tænker på, om du har husket at tage forbehold for
kaldekonventionen __cdecl ? Den instruerer den kaldende kode om, i hvilken
rækkefølge parametrene overføres og hvis ansvar det er at rydde op. Jeg
påstår ikke det har nogen betydning lige i det tilofælde overhovedet, men
prøv alligevel med
function OpSndRcvCl(psndbuffer: pointer; rcvbuffer: pointer): longint;
external tpmteccomapi.dll'; cdecl;
????