Wie stelle ich sicher dass ich nichts von VCL verwende

[Viktorii]

Zitat von Luckie:

Hat dein Thread ein Fenster und eine Nachrichtenschleife?

Da bin ich jetzt etwas überfragt. Ich habe ein Fenster Handle...

Die Objekt Variable meines Notifyer ist in der DLL global definiert. Das Notifyer Objekt wird in einer "init" Funktion (welche immer als erstes aufgerufen werden muss wenn man andere Funktionen der DLL verwenden möchte) erstellt.

Das Notifyer Objekt reagiert auf die WM:

Delphi-Quellcode:

constructor TNotifyUSB.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FWindowHandle := AllocateHWnd(WndProc);
  USBNotifyRegister;
  ...
end;


function TNotifyUSB.USBNotifyRegister: Integer;
var
  dbi           : DEV_BROADCAST_DEVICEINTERFACE;
  Size          : Integer;
  r             : Pointer;
  ret           : Integer;

begin
  ret := DLL_CO_USB_NOTIFY_REGISTER_FAILED;

  Size := SizeOf(DEV_BROADCAST_DEVICEINTERFACE);
  ZeroMemory(@dbi, Size);
  dbi.dbcc_size := Size;
  dbi.dbcc_devicetype := DBT_DEVTYP_DEVICEINTERFACE;
  dbi.dbcc_reserved := 0;
  dbi.dbcc_classguid  := GUID_DEVINTERFACE_USB_DEVICE;
  dbi.dbcc_name := nil;

  r := RegisterDeviceNotification(FWindowHandle,
                                  @dbi,
                                  DEVICE_NOTIFY_WINDOW_HANDLE);
  if Assigned(r) then ret := 0;          // ??? Retwert anpassen

  Result := ret;
end;



procedure TNotifyUSB.WndProc(var Msg: TMessage);
begin
  if (Msg.Msg = WM_DEVICECHANGE) then
  begin
    try
      WMDeviceChange(Msg);
    except
      Application.HandleException(Self);
    end;
  end
  else
    Msg.Result := DefWindowProc(FWindowHandle, Msg.Msg, Msg.wParam, Msg.lParam);
end;

Ich mache nur die DLL. Es kann sein dass eine Funktion der DLL in einem Thread aufgerufen wird, muss aber nicht. Das weiß ich leider nicht.

[sirius]

1. So ein Windowhandle klappt. Aber wie gesagt, wenn es in einem eigenen Thread läuft brauchst du eine Messageschleife. Die kannst du allerdings nicht selber implementieren, sondern du musst dies dem Anwender deiner DLL mitteilen.

2. Schau dir mal die Methoden Dispatch und DefaultHandler an. Damit kannst du deine WindowProc-Funktion "schicker" aufbauen.

[Viktorii]

Muss da jetzt doch nochmal nachhaken:

Ist das Application.ProcessMessages hier wirklich sinnlos?

Delphi-Quellcode:

Sleeper := 0;
while Sleeper < 100 do
  begin
  Sleep(1);
  inc(Sleeper);
  Application.ProcessMessages;
end;

Also folgende Situation: Meine DLL Init Funktion wird im Main Thread aufgerufen. In dieser wird meine Notifyer Objekt erstellt, welcher ein Fenster(-handle) ist welches auf (USB-)WM wartet und bei den entsprechenden WM irgendwelche Aktionen ausführt. Damit gehört diese Fenster doch zum MainThread!?

Nehmen wir mal an, jetzt wird eine andere DLL-Funktion in einem anderen Thread aufgerufen, mein USB Gerät rebootet und ich muss warten, bis mein Notifyer erkennt dass es wieder da ist. Ich kehre also aus der Funktion vorerst nicht zurück. Damit müsste der MainThread solange lahmgelegt sein, oder? Also kann mein Notifyer nicht auf die WM reagieren, oder?

Um dies zu verhindern, also um dafür zu sorgen, dass die WM im Mainthread weiter abgearbeitet werden und mein Notifyer wieterhin funktioniert, müsste Application.ProcessMessages hier doch sogar notwendig sein, oder?

Oder habe ich das Prinzip falsch verstanden?

Nochmals vielen Dank für eure Hilfe und Geduld mit mir.

[jfheins]

Wenn du die DLL programmierst, umnd die Funktion nicht zurückkehren darf, bis das Ding am USB anschlus rebootet ist, ,dann kehrst duu nicht zurück und PUNKT

Wenn der entwickeler der anwendung, der deine dll benutzt dann aber möchte, dass seine anwendung nicht einfreirt, weil die dll-fkt nicht zurückkehrt, dann soll er das eben in einen thread packen

Wenn deine DLL-Funktionen blockieren, dann tun sie es eben. Es istt nicht die aufgabe der DLL dafür zu sorgen, dass die Anwendung flüssig läuft.

Just my 2 cents

[Viktorii]

Oh mann, da habe ich gerade aber nen gewaltigen gedanken fehler

Der abgespaltet Thread wird natürlich lahmgelegt und der MainTread sollte weiter laufen -> Notifyer funktioniert -> Application.ProcessMessages nicht notwending.


Wenn meine Funktion aber nicht in einem separten Thread aufgerufen wird, (was nicht muss aber sein kann, weiss es ja leider nicht), dann ist Application.ProcessMessages notwendig oder?

[jfheins]

Nein. Application.Processmessages ist im Grunde nie notwendig.

Es ist manchmal praktisch, wenn auch etwas unsauber, wenn man verhindern möchte dass die GUI einfriert.

Wenn du nett sein möchtest, kannst du dem Entwickler natürlich auch 2 Versionen anbieten: Eine blockierende, und eine die schaut, obs geht und dann entweder zurückliefert "dauert noch" oder eben den Wert.