Jag använder Byval för parametrar. Ex: Tror denna artikel kan ge dig en bra överblick: http://www.windowsdevcenter.com/pub/a/oreilly/windows/ron/objects.html Från Vb skall du skicka ByVal precis som du har skrivit. Hej! >"Förbjuden åtgärd skylten" Om du har tillgång till Pascalkoden skriver jag gärna om den så att den funkar i XP. Dessvärre har jag inte källkoden. Det hade säkert underlättat det hela. Men jag tror inte man skall fästa så mycket uppmärksamhet vid just beep eftersom det inte är Pc:n som skall ljuda utan en kort dragare! Finns det inte pekare eller referenser i Pascal? Ja så kan det vara om det är lite äldre Pascal dialekt. Jo, det är exakt det ByRef gör, den skickar adressen, dvs vad en pekare skulle innehålla. mmm. men det är nått strul med att det skall skickas som "Null terminated string" Det är inte "C-konvention", det är ett lite väl starkt uttryck. Av allt som skrivits och sagts så är det så här ang Vb och DLL ! Nej, nej... Upplösningen av dramat! Tack för din "Feedback". Det är sånt här som är utveckling.Pascall DLL igen
Private Declare Function VBPedCombinedReaderRequest Lib "AurdllPre" Alias "CombinedReaderRequest" (ByVal KassaId As Long, ByVal Payment As Long, ByVal Beep As Long) As Integer
Någon sa at jag skulle använda Byref istället för de parametrar som lömnar svar tillbaka från DLL:en.
Kan någon ge mig ett råd, kanske tom förklara så jag begriper :)
/BoSv: Pascall DLL igen
Sv:Pascall DLL igen
Pascal vill ha sina arguement C konvension dvs ByVal.
Vad är det som blir Fel ?
Jag gillar inte ByVal Beep As Long ,Beep är ett reserverat ord
skulle kunna vara det som strular.
Om det är mening att det skall låta "Beep" och du kör XP
så är det där felet blir.XP tillåter inte access till Beepminnesarean funktionen.
Dvs den lokala lilla beep högtalaren i datorn.Sv: Pascall DLL igen
Jo, jag vet att beep är reserverat. Jag trodde inte at det gjorde någon skillnad i en deklaration (det gjorde det inte heller).
Mitt problem består av att DLL:en framkallar "Förbjuden åtgärd skylten". De som är upphovet till DLL:en kan inte ge någon förklaring till varför den beter sig så. ENligt uppgift finns den implementerad av andra
utan probem, f-n tro't :)
Det är alltid besvärligt med "utomstående" buggar, det räcker så bra med de egenproducerade. Dessutom
kan man ju i bästa fall göra något åt de egna.
Man skulle kanske börja odla Daddlar istället verkar mindre problemfyllt.Sv:Pascall DLL igen
Just detta får mig att tro att du kör XP NT eller 2000
Programmet funkar förmodligen på ME och därunder.
Dvs Dll:en anropar den minnesarea som har hand om Beep ljud
I XP osv är inte detta anrop tillåtet.
I Pascal koden kör man förmodligen Out( ) kommandot som inte funkar i XPSv: Pascall DLL igen
Skulle vara kul att execera Pascal,det var ett tag sedan.Sv:Pascall DLL igen
Programmakaren som jag har kontakt med hos leverantören kör 2000 så det är ju så att säga inom familjen. Hur som så avvaktar jag nu tills de har löst problemet. Man misstänker ju alltid att man själv gjort en groda men i detta fallet har jag friskrivit mig själv, så jag avvaktar. Äterkommer när en lösning har nåtts och jag har fått en förklaring till fenomenet.Sv: Pascall DLL igen
För om det finns det, så är det troligtvis så de gör för att förändra värden på de variablerna du skickar in.
I så fall är det väsentligt att du använder ByRef på just de variablerna.
Annars kommer programmet ta emot ett värde när det förväntar sig en pekare och då är det i princip garanterat att programmet kraschar.Sv:Pascall DLL igen
Men då kan aldrig Vb hitta den pekaren.Sv: Pascall DLL igen
Sv:Pascall DLL igen
Kommer inte ihåg alla detaljer.Men en sak är sann man skall i 99 % av fallen skicka
ByVal . Om du kollar alla API :er som finns så skall alla ha ByVal.Så kallad C konvension.Sv: Pascall DLL igen
Låt säga så här:
Om vi vill skicka ett tal som inte ska ändras så ska vi skicka det ByVal. Att skicka det så är inget konstigt.
Om talet vi skickar är 7, så kommer den mottagande funktionen ta emot just talet 7, oavsett om det är en C-funktion, en VB-funktion, eller en Pascal-funktion.
Det som sker är att kompilatorn eller interpretatorn gör en kopia av värdet ("7") och placerar det i "funktionens minne". Efter det finns ingen koppling mellan den ursprungliga variabeln och den i funktionen - när funktionen dör så dör funktionens upplaga av variabeln.
I fallet där vi istället vill kunna ändra talet så kan vi inte göra så här, utan då skickar vi det ByRef i VB-språk.
I VB märker vi ingen skillnad förutom att en ändring av variabeln inuti funktionen ger en ändring i variabeln utanför.
Men i praktiken så sker inte samma kopiering av värdet som vid ByVal, utan det går istället till så här:
1. Varibeln a ska skickas in i funktionen, a ligger på minnesadress 12345, men har värdet 7.
2. Kompilatorn eller interpretatorn skickar nu istället 12345 till funktionen. Så fort funktionen vill använda variabeln måste den titta på minnesadressen 12345, men det innebär också att variabeln kan ändras inuti funktionen.
I VB märker man som sagt inte det, men i C är skillnaden något i stil med:
void fun(int a)
resp. för ByRef
void fun(int *a)
Detta sker automatiskt under ytan i VB.
Anledningen till att man nästan alltid ska använda ByVal för WinAPI är att de flesta funktionerna är definierade som den första varianten där, men om Pascal-funktionen är gjord för att ta emot värden via pekare så är det ByRef som ska användas.Sv:Pascall DLL igen
Skriv ByVal . Man kan sen utveckla tex. Any.
ByRef skickar man adressen var informationen finns. Helt Ok i de flesta språk Men !
Vb är ett amatörspråk som försökt överbrygga alla dessa "klurigheter" med tex variabeln Variant.
Det är en styggelse !
Språken måste kompromissa för att kunna språka med varandra. Vb är ett sesam öppna dig
för programspråk som försöker anpassa sig.
Vill du gå vidare och utveckla dig kolla noga. Allt som har med C språket att göra är mitt råd.
Det är så djä.. jobbigt att skriva bra kod i assembler
C översätter till nästan perfekt assembler.
Tro mig har lagt >1000 timmar på assemblerSv: Pascall DLL igen
Valet mellan ByVal och ByRef är helt solklart när det gäller VB->DLL. Allt hänger på hur mottagaren har definierat sina argument. Använder de pekare så är det ByRef, är det inte pekare så är det ByVal.Sv:Pascall DLL igen
Det var så simpelt som att om en funktion hade sträng med i anropet och skulle lämna svar måste
strängen fyllas ut med space till erforderlig längd. Jag vet mycket väl att tex vissa API:er kräver det men
missade att dessa dll:er fordrade det också. Inget man kunde läsa i specarna.
Beträffande Byval så är det ok till den dll jag arbetar mot.Sv: Pascall DLL igen
Du löste ditt problem mha. "stickord" och ideer som kom fram längs tråden.
Tack Ha det