| |
Fragen und Antworten zur vbarchiv.dllffGetVolumeInformation | | | Autor: Braun | Datum: 29.10.05 11:28 |
| Hallo Martoeng,
Mit dem API "GetVolumeInformation...." hatte ich die Seriennummer vom Laufwerk ermittelt. Als Longwert war es die Nummer 615701661.
Mit der ffGetVolumeInformation-Function hatte ich aber Seriennummer "24B2-DC9D"
als String erhalten?
Was ist nun richtig?
Gruß Braun | |
Re: ffGetVolumeInformation | | | Autor: Braun | Datum: 30.10.05 09:29 |
| Hallo Martoeng,
verstehe ich nicht ganz.
Umgewandelt (615701661=long) in was?
Wie komme ich auf den Stringwert "24B2-DC9D" ?
Gruß Braun | |
Re: ffGetVolumeInformation | | | Autor: Joerg | Datum: 04.11.05 09:23 |
| Hallo Braun
24B2-DC9D ist der hexadezimale Wert von 615701661
Das hat Martoeng in seinem Post gemeint.
In der Funktion ffGetVolumeInformation wird demnach der ermittelte Longwert gleich in den HEX-Wert umgewandelt.
________________________________________________________________
Joerg
Amicus certus in re incerta cernitur.
Marcus Tullius Cicero
| |
Re: ffGetVolumeInformation | | | Autor: Braun | Datum: 04.11.05 10:06 |
| Hallo Jorg,
leider steht in der Dokumentation nicht, dass man es umwandeln muss.
An den Buchstaben B,C,D hatte ich es mir schon gedacht, dass es sich um Hex-Werte
handelt. Der Trennstrich trennt somit den High-Byte von Low-Byte.
Allerdings ist dieser Trennstrich eher hinderlich beim wandeln.
Um eine Umrechnung durchführen zu können(siehe unten) , muss der Trennstrich herausgefiltert werden.
Man könnte doch die Ausgabe ohne Trennstrich durchführen.
Oder hat der Trennstrich noch einen anderen Sinn?
longDezimalWert = CLng ("&H" & "24B2-DC9D" )
Gruß Braun | |
Re: ffGetVolumeInformation | | | Autor: Braun | Datum: 04.11.05 12:42 |
| Hallo Jörg,
zur weiteren internen Verarbeitung des String's in Hex, ist es sicherlich besser einen Wert ohne Tennstriche od. wie du sagst Punkte zu erhalten. Um endgültig einen Wert
im Textfeld optimal abzulegen gibt es dann div. Möglichkeiten (Format(....) usw.).
In den Eigenschaften werden z.B. die Colorwerte in Hex auch nicht getrennt.
Kontrolliert habe ich es aber nicht, ob der Trennstrich tatsächlich High-Byte vom Low-Byte trennen soll od. ob er nur für bessere Lesbarkeit sorgen soll..
Wie gesagt, es ist nur von mir ein Vorschlag.
Gruß Braun | |
Re: ffGetVolumeInformation | | | Autor: Braun | Datum: 07.11.05 21:20 |
| | Frage: Wie willst Du denn bitte eine Seriennummer noch weiter verarbeiten!?
| Mal 2 nehmen!?
da gibt es schon einige Möglichkeiten.
und mit 'Mal 2 nehmen' oder ähliches liegst du da nicht so falsch.
Festplattenserien-Nummern werden oft verschlüsselt, versteckt abgefragt um ein Udate nur auf einem bestimmten Rechner zu erlauben. Dafür eignet sich besser ein Long-Wert als ein Hex-Wert. Oder?
Mal eine Gegenfrage. Wann und wozu braucht jemand eine Seriennumer in Hex? Aber wie gesagt, es war ja nur ein Vorschlag.
Sicherlich kann man leicht den Bindstrich entfernen und den Hex-Wert in Long umrechnen. Als DOS geschädigter mit damals 640 KB bzw 1024 KB Arbeitsspeicher versucht man auch heute noch keine Zeile zuviel zu programmieren.
Gruß Braun | |
Re: ffGetVolumeInformation | | | Autor: Braun | Datum: 07.11.05 22:40 |
| Nur mal so zur Info, wegen der Gleichheit.
Auch die Drive-Eigenschaft von FSO zeigt 'SerialNumber' nicht in Hex an?
API "GetVolumeInformation" auch nicht in Hex?
Ich kenne es eigentlich nicht in Hex... | |
Re: ffGetVolumeInformation | | | Autor: Braun | Datum: 13.11.05 22:04 |
| Ok, nun gibt es ja einige Möglichkeiten eine Seriennummer zu lesen.
Bislang waren die Resultate immer im Bereich vom Long-Wert.
Neulich hatte ich eine HD-Seriennummer in Long mit einem Minus vorweg gesehen.
Kann es sein, dass die Seriennummern mittlerweile größer sind als ein Long anzeigen kann? Wenn ja, wie verhält sich hier dann ffGetVolumeInformation?
Gruß Braun | |
Re: ffGetVolumeInformation | | | Autor: Braun | Datum: 15.11.05 15:39 |
| ist wirklich eigenartig.
Eigentlich sind es nur die neueren Rechner oder besser gesagt die ganz neuen Rechner die das aufweisen.
Wie weit ist bei dieser Funktion (ffGetVolumeInformation) max. die S/N gedacht?
Gruß Braun | |
| Sie sind nicht angemeldet! Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
Einloggen | Neu registrieren |
|
|
sevISDN 1.0
Überwachung aller eingehender Anrufe!
Die DLL erkennt alle über die CAPI-Schnittstelle eingehenden Anrufe und teilt Ihnen sogar mit, aus welchem Ortsbereich der Anruf stammt. Weitere Highlights: Online-Rufident, Erkennung der Anrufbehandlung u.v.m. Weitere InfosTipp des Monats Neu! sevDTA 3.0 Pro
SEPA mit Kontonummernprüfung
Erstellen von SEPA-Dateien mit integriertem BIC-Verzeichnis und Konto- nummern-Prüfverfahren, so dass ungültige Bankdaten bereits im Vorfeld ermittelt werden können. Weitere Infos
|
|
|
Copyright ©2000-2024 vb@rchiv Dieter Otter Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.
Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel
|
|