Gibt es ein Event, wenn sich an den Laufwerken was ändert?

[bin_neu_hier]

Moin zusammen!

Mein Proggi liest gelegentlich ein paar Verzeichnisse ein und nennt dem User die vorhandenen Laufwerke. Zwischen dem Einlesen eines Verzeichnisses bzw. dem Erstellen einer Laufwerksliste und der Reaktion des Users bzw. dessen Entscheidung, was weiter passieren soll, mag einige Zeit vergehen. Zwischenzeitlich könnten andere Programme/Prozesse/ ... irgendwas verändern, beispielsweise wird ein USB-Laufwerk eingesteckt oder formatiert oder entfernt oder irgendwelche Dateien werden gelöscht, verschoben, ...

Die Frage ist: Gibt es ein oder mehrere Events, die von "anderswo" ausgelöst werden, auf die man mit einem "Refresh" der erzeugten Dateilisten oder Laufwerkslisten reagieren kann?

Dank an alle, die Ihre Zeit für mich opfern!

[mk-soft]

Nein,

Du must das Laufwerk/Ordner überwachen. Da hat schon mal jemand was geschrieben ...
Kann ich aber nicht auf Anhieb finden.

[marco2007]

Eventuell das hier?
viewtopic.php?p=314319

[dige]

Am besten ein FindFirstChangeNotification_() fürs komplette Laufwerk anmelden und dann entsprechend auf neu erstellte Objekte reagieren.

Hier hatte ich vor Urzeiten mal was gepostet: https://www.purebasic.fr/english/viewto ... er#p242874

[RSBasic]

Ja, die Events gibt es, aber nur mit WinAPI.

Wenn du ermitteln möchtest, ob ein Datenträger (z.B. eine externe Festplatte oder ein USB-Stick) angeschlossen wurde, dann kannst du mit folgendem WinAPI-Event abfragen:

Code: Alles auswählen

Procedure.s GetDevice(Bits)
  Protected i
  Protected Laufwerk.s
  
  For i = 'A' To 'Z'
    If Bits & 1 = 1
      Laufwerk.s = Chr(i)
    EndIf
    Bits = Bits >> 1
  Next
  
  ProcedureReturn Laufwerk
EndProcedure

Procedure WindowCallback(hWnd, uMsg, wParam, lParam) 
  Protected *DEV_BROADCAST_HDR.DEV_BROADCAST_HDR
  Protected *DEV_BROADCAST_VOLUME.DEV_BROADCAST_VOLUME
  
  Select uMsg
    Case #WM_DEVICECHANGE
      Select wParam
        Case #DBT_DEVICEARRIVAL
          *DEV_BROADCAST_HDR = lParam
          If *DEV_BROADCAST_HDR\dbch_devicetype = #DBT_DEVTYP_VOLUME
            *DEV_BROADCAST_VOLUME = *DEV_BROADCAST_HDR
            Debug "Angeschlossen:"
            Debug GetDevice(*DEV_BROADCAST_VOLUME\dbcv_unitmask) + ":\"
          EndIf
        Case #DBT_DEVICEREMOVECOMPLETE
           *DEV_BROADCAST_HDR = lParam
          If *DEV_BROADCAST_HDR\dbch_devicetype = #DBT_DEVTYP_VOLUME
            *DEV_BROADCAST_VOLUME = *DEV_BROADCAST_HDR
            Debug "Entfernt:"
            Debug GetDevice(*DEV_BROADCAST_VOLUME\dbcv_unitmask) + ":\"
          EndIf
      EndSelect
  EndSelect
  
  ProcedureReturn #PB_ProcessPureBasicEvents 
EndProcedure

Wenn du innerhalb eines Datenträgers oder Ordners auf Dateiänderung (Datei erstellt, geändert, entfernt, kopiert, verschoben) in Echtzeit abfragen möchtest: https://www.rsbasic.de/aktualisierung/w ... mitteln.pb

Ohne WinAPI ist das entweder nicht möglich oder nur sehr umständlich und performance-lastig, weil PureBasic keine nativen Events zum Abfragen der Laufwerke anbietet, sondern nur das Betriebssystem wie Windows.

[bin_neu_hier]

Hallo @ all!

Erstmal Euch allen vielen Dank für den Input. Das kratzt jetzt aber mal schön an meinen Limits, aber da muss ich jetzt durch ...

Habe bisher das Thema "Windowcallback" nach Möglichkeit umgangen - nachdem ein paar Versuche kläglich gescheitert sind, konnte ich die Flinte gar nicht weit genug ins Korn werfen. Aber da ich immer wieder auf Lösungen mittels Callback stoße, muss die Kröte "Callback lernen" irgendwann ja mal geschluckt werden.

Erste Verständnisfrage dazu: Ist ein Callback immer ein Einzelding, also braucht man für verschiedene Dinge jeweils einen separaten Callback oder kann ein Programm nur einen Callback enthalten, der entsprechend erweitert wird, um verschiedene Funktionalitäten zu erreichen?

Ich werde Euch brauchen ...

[dige]

Du kannst dir Callbacks als eine squentielle Aufgabenliste/2dos vorstellen, die Purebasic immer als erstes abarbeitet, wenn im Coding eine Eventabfrage initiert wird.

[TroaX]

Ein Callback (z. D. Rückruf) ist die Fähigkeit einer Funktion bzw. eines Programms, eine andere Funktion/Prozedur "zurückzurufen", dessen Implementierung zur Zeit der Implementierung der übergeordneten Funktion/Programms nicht bekannt ist. Beim übergeben einer Funktion wird dabei die Adresse (deswegen das @ vor dem Prozedurnamen - die Adresse kann man sich bei Callbacks jetzt wie eine Telefonnummer vorstellen) dieser Funktion übergeben, damit die zuerst aufgerufene Funktion weiß, wohin sie "zurückrufen" soll. Generell ist dessen Einsatz innerhalb eines Programms nicht limitiert.

Allerdings gilt es beim Einsatz von Callback einiges zu beachten. Zum einen gibt es Extension Callbacks, die dazu da sind, Funktionalität/Verhalten einer bestehenden Prozedur zu erweitern. Das wird zum Beispiel in Javascript sehr häufig verwendet. Dies geschieht auch gerne mit anonymen Funktionen. In PHP nutzt man es gerne bei regulären Ausdrücken, um komplexere Operationen mit Matches zu implementieren. Hier kann theoretisch bei jedem Aufruf ein neuer Callback übergeben werden, da diese bei Aufruf der Funktion direkt mit ausgeführt werden.

Zum anderen gibt es Queued Callbacks, die als Parameter für eine Funktion dienen, die aus den Adressen eine Warteschlange macht. Im Verlauf wird immer wieder diese Funktion mit Übergabe eines Callbacks aufgerufen und die Liste mit den Funktionsadressen gefüllt, während ein anderer Programmteil nach und nach diese Liste unabhängig von der Funktion abarbeitet.

Und zu guter letzt gibt es noch die Conditional Callbacks. Diese Callbacks werden an eine Funktion übergeben, die an Hand weiterer Parameter den Callback in eine Liste ablegt und dessen Aufruf dabei an eine Bedingung knüpft. Ist eine dieser Bedingungen beim Durchlauf der Liste erfüllt, wird diese Callbackfunktion aufgerufen und abgearbeitet. Hier ist zu beachten, das in der Regel für eine bestimmte Bedingung nur ein Callback gebunden werden kann und der letzte immer wieder den vorherigen überschreibt. Es sei denn man mischt Queued und Conditional Callbacks. Aber das macht nur in wirklich ganz speziellen Situationen Sinn.

Die Prozedur "BindEvent" arbeitet mit Conditional Callbacks.

Code: Alles auswählen

BindEvent(Event, @Callback() [, Window [, Objekt [, EventTyp]]])

Je mehr Parameter du angibst, um so spezifischer ist die Bedingung. Da aber beim Auftreten des Events natürlich das Programm genau wissen muss, was es tun soll, überschreibt ein erneutes Aufrufen mit einem anderen Callback, aber ansonsten identischen Parametern den alten Callback. Bei Auftreten eines Events wird also genau die Prozedur aufgerufen, die zuletzt für dieses Event übergeben wurde.

Und es wird Zeit dass das Sommerloch endlich mal endet. Ich habe zu viel Zeit, sowas zu schreiben

[dige]

Danke TroaX

[bin_neu_hier]

Hallo TroaX,
Hallo Dige,

herzlichen Dank für Euren Input. Das ist für mich ein Haufen Holz auf einmal! Gut dass es ein Sommerloch gibt, davon kann ich nur profitieren! Werde mich also an die Callback-Sache "ranwanzen" ...