Hello Folks
En fråga som är lika gammal som Delphi och VB.

Hur får jag en Delphi DLL Funktion att returnera en sträng
som Visual Basic begriper. StdCall SafeCall AnsiString osv. ?

Delphi DLL :er är guld som komplemment till VB , men
just denna problematik har jag aldrig lyckas lösa.

undrar
Sven

Hej Sven,
En tänkbar lösning är att definiera en bytearray och returnera pekaren som du fångar som en sträng i VB. Sedan nullterminerar du strängen med:
string = left(string,instr(string,vbNullCharll))

Har ej testat denna variant men den borde fungera.

Förresten:
Varför vill du skriva Dll´r i Delphi för när VB kompilerar välskriven kod så mycket bättre, det är bara att optimera bort alla checkar som du inte påverkas av i Advanced Optimizations... menyn. Iofs har du inline assembler i Delphi men det är ju bara vissa prylar man kan skriva bättre än en kompilator.

Hej
>när VB kompilerar välskriven kod så mycket bättre, det är bara att optimera bort alla checkar som du inte påverkas av i Advanced Optimizations

Vem ?? har inbillat dig det ,att VB skulle kompilera bättre än
Delphi och C++. Framför allt stränghantering är Delphi vida
överlägsen VB . VB :s exe fil är ju fortfarande beroende
av en tolk/runtime dll, för att lösa sina uppgifter ,helsjukt.

För att platsa att kallas kompilerad så skall det bli StandAlone exe.
tycker
Sven
som fortfarande gillar VB för att det är så enkelt att få till det direkt.

Testa Dno Dynamics 8.0, ett smart verktyg för detta ;)

Hej
>Testa Dno Dynamics 8.0, ett smart verktyg för detta ;)

Kan du förklara närmare , bra för vad ? har du någon bra adress

undrar
Sven

VB använder sedan version 5 samma kompilator som VC++, de har iofs olika pre-processors men kompilatorn gör en stor del av optimerings jobbet... Jag förstår att du tycker att VB´s stränghantering är under all kritik (håller faktiskt med dig i visa fall) men om man jobbar med fixed length på strängarna så ökas VB´s stränghanteringsprestanda enormt, vissa grejer är dock väldigt dryga att jobba med. Att VB är beroende av en miljö för att utföra sina uppgifter är ett sant argument som inte går att bortse ifrån, VB´s runtime miljö är ju skriven för att tillhandahålla metoder och funktioner som används istället för att kompilera in dessa i programmet. Detta ger ju en viss overhead men samtidigt så ger detta också driftsäkerhet. Anta att vi skriver en rutin i VB som använder funktionen Split och den funktionen buggar ur eller blir uppdaterad med en effektivare kodsnutt så kommer programmet genast att dra nytta av denna uppdatering vid uppdatering av runtime-miljö. I standalone kompilatorer blir man ju tvungen att kompilera om mjukvaran och sedan distrubiera den till alla användare för varje uppdatering, hur man vill ha det är ju upp till var och en men om jag arbetar mot en kund så vill jag ju tillhandahålla uppdateringar på det sätt som operativsystemet är designat för.

VB har precis som du säger inte en chans mot C++ annat än i diciplinerna utvecklingshastighet, felhantering och debugmöjligheter.

Till sist vill jag bara säga att det här är INGEN kritik mot Delphi som trots allt är ett rätt så trevligt språk även om jag tycker att det kan vara väl knöligt att lösa vissa grejor i det.

Trevlig läsning kan för övrigt vara följande sida:
http://www.xbeat.net/vbspeed/

Hej
>http://www.xbeat.net/vbspeed/
Det var en trevlig sida ,den hamnade i Favoriter direkt
Fö håller jag med om det mesta i ditt inlägg ovan.

Ha det
Sven

Det bästa brukar väl vara att deklarera sina funktioner som windows api.
Altså skicka en buffer och storleken på denna och returnera eventuella fel. i delphi borde deklarationen se ut som nedan:
function GetString(buff: pChar; buffsize: Integer): integer; stdcall;

Fö håller jag inte med trasher ;-).



Lite andra tips:
There are a number of fundamental differences between VB and Delphi. VB always
expects stdcall calling convention for functions it imports from a DLL, for
example, Delphi uses whatever you tell it and the default register calling
convention is not compatible with anything used outside of Delphi and C++
builder. The default mode to pass parameters in VB is by reference, in Delphi
it is by value. So if you declare a parameter as PhoneNumber as Long in VB the
Delphi equivalent would be Var PhoneNumber: Integer. If you want by value
parameter passing in VB you have to ask for it by declaring the parameter as
ByVal Phonenumber As Long.

The following i posted some time ago may give you some more hints:
<quote>
on DLLs and VB/VBA

- use stdcall calling convention on all exported functions
- wrap the body of each exported function into a try except block and
pass error states back to the caller as return values, for example. Do
not let an exception escape the DLL or VB/VBA will die an ugly death.
- do not use Delphi-specific parameter types like String, real, open
arrays, dynamic arrays, objects, Boolean. Use API or OLE compatible types
only.
- remember that the default parameter passing mechanism in VB(A) is
by reference, in Delphi it is by value, but for many types (like records,
arrays) Delphi will in fact pass the parameter by reference and make
a local copy inside the called function!
A ByRef or unspecified (no ByVal) parameter usually translates to a
Var parameter in Delphi, a byVal parameter to a Delphi value parameter.
The exceptions are ByVal String -> Pchar and ByVal array -> pointer to
array element type or Var TSomeArrayType (but not open or dynamic array!).

VB Delphi
--------------------------------------------------------------------
Integer ShortInt
Long LongInt
Single Single
Double Double
Boolean WordBool
String Widestring VB uses UNICODE, its String type is
the API BSTR type used in OLE/COM.
A ByVal String parameter translates to
Delphi PChar!
Arrays OLE safearrays needs API use in Delphi
Byte Byte or Char depends on context, VB has no char type
Variant OLEVariant
user types packed records fixed-size string fields in user types may
translate to array of Widechar fields in
Delphi (not sure here).
</quote>

Hej
>function GetString(buff: pChar; buffsize: Integer): integer; stdcall;

Skitbra fo.....,Så har jag också tänkt.Bara en koll den returnerade
Integern vad skall den representera.
Allt Ok eller Error tror jag ,men är inte säker.

mvh
Sven

>Allt Ok eller Error tror jag ,men är inte säker.
Just det. Man kan ju även tänka sig att den returnerar olika felkoder beroende på vilket fel. Windows Api returnerar ju ofta 0 för fel och <> 0 för Ok(altså en boolean), och sedan får man använda GetLastError.

Vi har olika åsikter, det respekterar jag :-)

Men vi ska vara klara på en sak, om Delphi väljer att ta ALLT ByVal så får man mycket onödig overhead både minnesmässigt och prestandamässigt, speciellt om man skickar minnesintensiva saker som stora strängar (givetvis använder man ByVal i VB om man vill manipulera värdena som kommer in). Jämför själv genom att ta tima en rutin som tar emot många strängar byref jämfört med byval, ett 32-bitars tal går alltid fortare att skicka än en sträng med ett par tecken i. Problem uppstår ju också om man skriver minnesresidenta objekt, nu tror iofs jag inte att ni skriver ActiveX komponenter utan statiska dll'r (rätta mig om jag har fel), de har en förmåga att inte släppa på sitt reserverade minne om man inte tänker sig för vilket kan resultera i bestialiska minnesallokeringar om man har otur.

OBS!
Fortfarande ingen kritik mot Delphi!

Delphi använder by value som default altså om man inte talar om att man vill använda något annat det går även bra att använda var(by reference), constant, out.

Mig gör det inget om du kritiserar delphi.

Igen
Till Trash : Man tillverkar en DLL (Dynamic Link Library) för att den skall
lösa ett allmängiltigt återkommande problem snabbt och effektivt.

Om man gör detta i VB så måste DLL :en i sin tur använda sig av
en två tre DLL :er ,kass en DLL skall vara StandAlone.

Vill man komma åt portar så går detta inte i VB man är hänvisad
till DLL :er osv osv . Skriv inte DLL :er i VB

tycker
Sven

Hej

Jag vill också veta vad Dno Dynamics 8.0 kan göra för konster.


Mvh/Olof