unsigned DWORD

[EWeiss]

Zitat von Uwe Raabe:

Und wie ist gnAudioChannel deklariert?

Delphi-Quellcode:

HSTREAM = DWORD; // sample stream handle
gnAudioChannel: HSTREAM; (Cardinal)

Ich habe nichts davon hier irgendwas zu erzählen
Möchte nur das es funktioniert auch mit eingeschalteter Bereichsprüfung.
Das es nicht geht sieht man ja.

Bei diesen einfachen Beispielen kann man nichts falsch machen.
Kann aber auch nichts an den Ergebnis ändern das von Bass geliefert wird.

D2010..

gruss

[hoika]

Hallo,
Google ...

http://www.un4seen.com/forum/?topic=13417.0;wap2

[EWeiss]

Zitat von hoika:

Hallo,
Google ...

http://www.un4seen.com/forum/?topic=13417.0;wap2

Gut das würde mein Problem lösen.
Frage mich nur warum man dann noch weiter eine Unit Publiziert obwohl das Problem ja schon seit längeren bekannt ist.
Muss dann wohl alle DWords mit LongInt ersetzen. bzw.. nur die Rückgabe.

Hoffe mal das es hilft.

Das verstehe ich nicht ganz

Zitat:

I have tried also DW_ERROR with a c defined as Bass.dWord and it works.

Also wie das ersetzen? So belassen?
DW_ERROR = LongWord(-1);

if BytesValid = DW_ERROR then

gruss und Danke.

[jfheins]

Zitat von EWeiss:

Muss dann wohl alle DWords mit LongInt ersetzen. bzw.. nur die Rückgabe.

Hoffe mal das es hilft.

Zitat von EWeiss:

Aber nebenbei es nimmt kein ende.
Habe es nach LongInt geändert.

Nun bekomme ich hier einen ERangeError.

Vielleicht bin ich jetzt zu naiv, aber: Warum änderst du es in diese Richtung? Und nicht von int zu DWORD? Wenn die dll DWORD zurückgibt, dann muss man das erstmal hinnehmen, oder?

[EWeiss]

Zitat:

Wenn die dll DWORD zurückgibt, dann muss man das erstmal hinnehmen, oder?

Nö muss man nicht! (Und kann man auch nicht)

Man muss nur dafür sorge tragen das der Daten Typ vom Bereich her passt.
Oder warum denkst du das mit ein und der gleichen Funktion die von der DLL veröffentlicht wird
mehrere unterschiedliche Sprachen miteinander kommunizieren können.

Letztendlich zählt nur die Auswertung der Rückgabe.

bsp.
Nur weil ich unter Delphi einen PAnsiChar als Rückgabe einer Funktion erwarte ist die andere Sprache nicht
dazu gezwungen exakt diese Namensgebung auch zu verwenden.

Ausgabe: Library Delphi
Delphi

Code:

function BASSVIS_FindPlugins(Kind: TBASSVIS_KIND_T; PluginPath: PAnsiChar; Searchflags: DWORD; Delimiter:AnsiChar=','): PAnsiChar; stdcall;

VB6

Code:

Public Declare Function BASSVIS_FindPlugins Lib "bass_vis.dll" (ByVal Kind As BASSVISKIND, ByVal PluginPath As Any, ByVal Searchflags As Long, Optional(ByVal delemiter As Byte = 44) As Long

C++

Code:

char* BASSVISDEF(BASSVIS_FindPlugins)(BASSVIS_KIND_T Kind, char *PluginPath, DWORD Searchflags, char *Delemiter); DWORD BASSVISDEF(BASSVIS_GetModuleHandle)(BASSVIS_KIND_T Kind, char *Pluginfile);

CSharp

Code:

private static extern IntPtr BASSVIS_FindPlugins(BASSVISKind A_0, [In, MarshalAs(UnmanagedType.LPStr)] string A_1, BASSVISGetPlugin A_2, byte A_3);

So jetzt definiere du mir mal wer nun für den Daten Typ der Rückgabe zuständig ist.
Mein DLL und oder die jeweilige Programmiersprache.
Der Bereich des Daten Typ muss stimmen und da hatte ich nach dem Vorschlag nicht nachgesehen in dem Fall hätte ich ihn auch nicht geändert.

Und wenn er nicht passt muss man ihn passend machen!
Das obliegt aber der Sprache die meine DLL nutzen möchte, Nicht umgekehrt so wie du das denkst.

VB6

Code:

Dim flist   As String
Dim LngP    As Long

LngP = BASSVIS_FindPlugins( _
       BASSVISKIND_WINAMP, _
       PluginDir, _
       BASS_VIS_FIND_RECURSIVE)

flist = VBStrFromAnsiPtr(LngP)
alist = Split(flist, ",")

Code:

Public Function VBStrFromAnsiPtr(ByVal lpStr As Long) As String

Dim bStr() As Byte
Dim cChars As Long

    On Error Resume Next
        ' Get the number of characters in the buffer
        cChars = lstrlen(lpStr)
        If cChars Then
            ' Resize the byte array
            ReDim bStr(0 To cChars - 1) As Byte
            ' Grab the ANSI buffer
            Call CopyMemory(bStr(0), ByVal lpStr, cChars)
        End If
        ' Now convert to a VB Unicode string
        VBStrFromAnsiPtr = StrConv(bStr, vbUnicode)

End Function

So..
Und das es nicht funktioniert mit unsigned DWord und signed C++ bei eigeschalteter Bereichsprüfung
liegt am ende schlichtweg daran das der Compiler unter D2010 bei der Bereichsprüfung fehlerhaft ist.
Anders kann ich mir das nicht erklären.

Gäbe es jetzt einen Daten Typ in Delphi der im Bereich von -4294967295 bis 4294967295 läge würde ich ihn nehmen
dabei würde es für mich keine rolle spielen wie der Daten Typ benannt ist.


gruss

[himitsu]

C ist bezüglich Typisierung nunmal recht "lasch" und Delphi reagiert auf falsche Typen eben bissl allergisch.

Code:

int r=BASS_ChannelGetData(decoder, buffer, length);
if (r==-1) return 0; // error = no data

In C mag das gehen.
Delphi erkennt hier, dass R niemals -1 sein kann und wären beides Variablen, dann würde Delphi die beiden Typen so weit vergrößern, dass sie gemeinsam in den selben Wertebereich passen, also 64 Bit signed > Int64 bei LongInt und LongWord

In Deplhi kann man Typgrenzen nur durch harte explizite Casts umgehen.

Delphi-Quellcode:

const BassNoData = DWORD(-1);

if r = BassNoData then Result := 0; // error = no data

Man könnte es zwar auch als const BassNoData = $FFFFFF; deklarieren, aber dann würde es nicht mehr der Vorgabe entsprechen.

[EWeiss]

Dann also
DW_ERROR = LongWord(-1); zu
DW_ERROR = DWord(-1); oder verstehe ich da wieder was falsch.

Aber nebenbei es nimmt kein ende.
Habe es nach LongInt geändert.

Nun bekomme ich hier einen ERangeError.

function BASS_ChannelGetLevel(handle: DWORD): LongInt;

Delphi-Quellcode:

function TMainApp.SolvePeak(nValue, nTotal: LongInt): LongInt;
begin
  Result := 0;
  if nTotal <> 0 then
    Result := (nValue * 98) div nTotal;

end;

Delphi-Quellcode:

    nLevel := BassChannelGetLevel;

    nLpeak := SolvePeak(loword(nLevel), 128);
    nRpeak := SolvePeak(Hiword(nLevel), 128);

EDIT:
Nein kann kein LongInt verwenden da die Daten die von Bass_ChannelGetdata geliefert werden im Bereich höher sind als bei LongInt (-2147483648 to 2147483647)
Was für ein Schmarrn..
Da bleibt nichts anderes übrig als die Bereichsprüfung auszuschalten.
Oder eine neuere Version von Delphi zu verwenden (Nur dafür fehlt mir die Kohle zu teuer für Hobby Programmierer).

Danke an alle für die Diskussion.

gruss

[himitsu]

LongWord und DWORD ist das "Selbe".
Das Eine ist blos der Pascal-Name und das andere der C-Name.

Wie zu lesen ist, ist BASS absichtlich unsigned, also kann man da nicht es nicht einfach signed ändern.
Aber man kann integer explizit auf DWORD/LongWord casten.

Gut, man könnte zwar geziehtl versuchen einige Stellen auf Integer zu ändern, damit der Code delphi-typischer wird, aber dann muß man bei Upgrades aufpassen.


Alternativ kann man auch nur für bestimmte Units die Bereichsprüfung deaktivieren, so wie man es z.B. auch bei Verschlüsselungen/Hashs macht, welche implizit mit Überläufen "funktionieren", damit der Code einfacher bleibt.

Die Starter-Edition ist ja aktuell gratis. (wenn man auf ein bissl was bezüglich Features verzichten mag, siehe die vielen Threads dazu)

[EWeiss]

Zitat:

Gut, man könnte zwar geziehtl versuchen einige Stellen auf Integer zu ändern, damit der Code delphi-typischer wird, aber dann muß man bei Upgrades aufpassen.

JO das hatte ich letztens hab mir da mehr Kaputt optimiert als das es der Anwendung gut tat.
Hatte anschließend unerklärliche Speicherlecks und muste zurück zum letzten Build.

gruss

[jaenicke]

Du kannst aber auch gezielt die Bereichsprüfung nur in deiner Schnittstelle zu BASS deaktivieren (also in der Unit, in der du die Funktionen der DLL aufrufst), im Rest des Projekts aber aktiv lassen.

Dafür gibt es die Direktive {$RangeChecks Off} bzw. {$RangeChecks On} .