![]() |
WNetOpenEnum "Falscher Parameter"
Ich verscuhe so zu Prüfen, ob auf die Freigane zugegriffen werden kann:
Delphi-Quellcode:
Nur leider bekomme ich immer den Fehler "Falscher parameter", egal ob ich verbunden bin oder nicht. :gruebel:
procedure TConnection.CheckConnetion;
var NetResource : TNetResource; err : DWORD; Dummy : THandle; begin ZeroMemory(@NetResource, sizeof(TNetResource)); NetResource.dwType := RESOURCETYPE_DISK; NetResource.lpRemoteName := PChar(FUNCPath); err := WNetOpenEnum(RESOURCE_CONNECTED, RESOURCETYPE_DISK, RESOURCEUSAGE_CONNECTABLE, @NetResource, Dummy); if err <> NO_ERROR then begin FConnected := False; if Assigned(OnError) then FOnError(self, err, SysErrorMessage(err)); end; end; Ich habe schon im Forum gesucht, aber eigentlich unterscheidet sich mein Code nicht von dem hier in der DP. :? |
Re: WNetOpenEnum "Falscher Parameter"
Ich müsste das noch mal pushen, auch wenn noch keine 24 Stunden rum sind, aber ich bräuchte das morgen an der Arbeit. :oops:
Im PSDK steht: Zitat:
|
Re: WNetOpenEnum "Falscher Parameter"
hab den Fehler gefunden. Im MSDN steht folgendes:
Zitat:
|
Re: WNetOpenEnum "Falscher Parameter"
Ja aber wie teile ich ihm dann mit, welchen Netzwerkpfad er nehmen soll? Der steht doch in der Struktur drinne? :gruebel:
|
Re: WNetOpenEnum "Falscher Parameter"
du schreibst in deinem ersten post:
Zitat:
Solange es um den Typ Disk geht würde ich dir empfehlen einfach mit FindFirst zu versuchen darauf zu zugreifen. Damit die Anwendung nicht steht das ganze einfach in einem Thread ausführen und wenn dieser nicht nach einer festgelegten Zeit mit der Anweisung fertig ist weißt du das er ewig versucht die Ressource zu finden und diese somit wohl nicht vorhanden ist. |
Re: WNetOpenEnum "Falscher Parameter"
Hm, ob das aber die Lösung ist? :gruebel:
|
Re: WNetOpenEnum "Falscher Parameter"
die Ultimative Lösung ist das wohl nicht aber letzendlich kommt das ja aufs gleiche heraus.
Du dachtest vermutlich ja das die Funktion WNetOpenEnum versucht zu den Resorucen zu verbinden was aber nicht der Fall ist. Also kommt es ja fast aufs gleiche heraus wenn du es selbst versuchst. Du kannst das ganze natürlich auch ohne Thread machen aber dann kanns halt sein das deine Anwendung eine kleine Ewigkeit nix macht (so wie der explorer wenn man auf ein Netzlaufwerk zugreifen will wo er den host noch nicht gefunden hat). Wenn du eine bessere Lösung findest wäre ich dankbar wenn du diese postest da ich derzeit auch mit dieser "unschönen" Art auf die Existens einer Datei auf einem Netzlaufwerk teste. |
Re: WNetOpenEnum "Falscher Parameter"
hab mal bischen probiert und die Funktion "MultinetGetConnectionPerformance" kann man für diesen zweck missbrauchen.
So hab ich das umgesetzt:
Delphi-Quellcode:
function IsNetworkResAvailable(ARes: String): Boolean;
var LRes: TNetResource; LInfo: TNetConnectInfoStruct; begin ZeroMemory(@LRes, SizeOf(LRes)); LRes.lpLocalName := nil; LRes.lpRemoteName := PChar(ARes); LInfo.cbStructure := SizeOf(LInfo); result := MultinetGetConnectionPerformance(@LRes, @LInfo) = NOERROR; end; |
Re: WNetOpenEnum "Falscher Parameter"
Liste der Anhänge anzeigen (Anzahl: 1)
So, ich glaube, ich habe da was. Demo im Anhang. Wenn die Freigabe nicht existiert kommt eine Fehlermeldung im Memo. Existiert sie und man ist verbunden, dann kommt eine entsprechende Meldung, trennt man es dann kommt auch die Meldung, dass das Netzlaufwerk nicht gefunden wurde. Aber wenn man verbindet und dann im Explorer die Freigabe aufhebt, meint er immer noch, dass man auf das Netzlaufwerk zugreifen könne. Kann es sein, dass das irgendwo gecacht wird?
Ach so: Button1 = verbinden Button2 = trennen Button3 = prüfen Button4 = murks Code aus dem Internet. ;) |
Re: WNetOpenEnum "Falscher Parameter"
Ich hab auch die Befürchtung das da der Cache zur Anwendung kommt. Kannst ja aber mal mein zuletzt getestetes Beispiel testen ob das funktioniert.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz