vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
NEU! sevCoolbar 3.0 - Professionelle Toolbars im modernen Design!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2025
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

Fortgeschrittene Programmierung
Re: vbex32.dll-vblockmemory 
Autor: unbekannt
Datum: 11.05.02 22:53

Hi Seb,

ich würde mich einem so empfindlichen Bereich nicht so nähern. Die Deklarationen sind durchaus korrekt - aber: VBEx32.DLL sagt: SICHERE DIR JEDEN SPEICHER! UND GIB IHN WIEDER FREI! - eine klare Präampel! Jedes Byte mußt Du so sicher aufbewahren, wie alles was Dir lieb und wert ist. Ansonsten bekommt VBEx Probleme mit Windows.

Ich erlaube mir als VBEx32.DLL - Entwickler mal Dein Beispiel durchzuproggen

Ob Du das mit einer Klasse machst, einer Form, einem Modul ist VBEx egal!

Das Allerwichtigste ist der Key - Eben die Struktur, die den geforderten Speicher repräsendiert. Diesen Key darfst Du niemals verlieren. Der Key steckt in der Struktur:

TYPE MemInfo 
  MemSize AS LONG
  MemPtr AS LONG
  MemLock AS LONG
END TYPE
Mit MemSize sagst Du Windows, wieviele Bytes Du benötigst. Hat es Windows geschafft Dir die Anzahl an Bytes im Arbeitsspeicher zu reservieren, erhälst Du in MemPtr die Addresse zu diesem Speicher. Ist der Wert 0, gibt es ein Problem. MemLock ist absolut nicht für den Progger, sondern eine Vereinbarung zwischen VBEx32.DLL und Windows! Es ist die Visitenkarte für den Speicher. Darum braucht sich der Progger nicht um die Werte in MemLock kümmern. MemPtr ist natürlich interessant mit den anderen Funktionen der VBEx32.DLL - Poke , Peek. Natürlich solltest Du den Offset zum Speicherbereich verwenden ._)).

Wenn die so angezapfte Speicherstelle Projektüberbreifend sein soll, so muss die Allocierung in einem Modul erfolgen. Klassen können keine Projektübergreifende UDT wie MemInfo verwalten!

Spielen wir doch mal das Prozedere durch, wobei 1kB Speicher zu reservieren ist. Dieser Speicher soll Projektübergreifend sichtbar sein und ggf. um weitere Speicherblöcke erweitert werden können.... Done

Klarer Fall für ein Modul!

Ich beginne ... in einem Modul.
Private Declare Sub GetMemory Lib "vbex32.dll" Alias _
        "VBLOCKMEMORY" (ptrMemInfo As MemInfo)
 
Public TYPE MemInfo 
      MemSize AS LONG
      MemPtr AS LONG
      MemLock AS LONG
END TYPE
 
Public myMemoryKeys() AS MemInfo 
 
Public Sub GetMemory(Byval nSize As Long)
     Dim newMemS As MemInfo
     Static n As Long
 
     newMemS.Size = nSize
     GetMemory newMemS
 
     If newMemS.MemPtr > 0 Then
           n = n + 1
           ReDim Preserve myMemoryKeys(n)
           myMemoryKeys(n) = newMemS
     End If
End Sub
So geht man mit VBEx32.DLL um


Cu
Lordchen
alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
vbex32.dll-vblockmemory39seb-software11.05.02 20:42
Re: vbex32.dll-vblockmemory276unbekannt11.05.02 22:53
Re: vbex32.dll-vblockmemory33SEB12.05.02 08:25
Hast Recht, kleiner Lapsus passiert 265unbekannt12.05.02 13:08
Re: Hast Recht, kleiner Lapsus passiert 28SEB13.05.02 05:41

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

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2025 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