![]() |
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.
|
Re: WNetOpenEnum "Falscher Parameter"
Nicht schlecht. Aber auch ein Problem. Wenn ich die Freigabe aufhebe, wenn man nicht verbunden ist geht es. Ist man aber verbunden und ich hebe die Freigabe auf, behauptet die Funktion trotzdem, dass die Freigabe da wäre. :gruebel:
|
Re: WNetOpenEnum "Falscher Parameter"
also wird auch wieder der Cache genutzt? ich kann es leider nicht unter realen Bedingungen Testen sondern im moment nur prüfen ob die Ressourcen von "server01" verfügbar sind wobei das Programm auch auf Server01 ausgeführt wird.
|
Re: WNetOpenEnum "Falscher Parameter"
Das Problem habe ich auch hier und an der Arbeit. Die wohhlen erst eine reale testumgebung aufsetzen, wenn das Projekt schon weiter vorangeschritten ist. :?
Verbinde ich mich ziwschen durch nicht geht es wie gewünscht. |
Re: WNetOpenEnum "Falscher Parameter"
du könntest eine VM nutzen. Oder wenn wirklich immer der Cache bemüht wird wäre dann wohl wirklich nur die Möglichkeit mit FindFirst zu prüfen. Und dabei natürlich hoffen das dort nix mit dem Cache zu tun hat.
Ich werd mal bischen mit VM rum probieren und eventuell erst morgen wieder schreiben (bzw. heute nach dem schlafen) |
Re: WNetOpenEnum "Falscher Parameter"
Eine VM :shock: mit 480 MB Speicher in der Maschine? :shock:
|
Re: WNetOpenEnum "Falscher Parameter"
also ich habs grad mit VM getestet und auch dort ist das von dir beschriebene Problem. Testet man auf eine frei gegebene Resource ("test1") wird True zurück gegeben. Wenn man diese Freigabe dann aufhebt wird jedoch weiterhin "True" zurück gegeben, selbst nach einem Programmneustart.
Ich hab die befürchtung das es wohl doch wieder darauf hinaus läuft per FindFirst das ganze zu versuchen da, dabei versucht wird zu verbinden um die Auflistung vom anderen System zu bekommen. |
Re: WNetOpenEnum "Falscher Parameter"
Was verursacht denn das für eine Netzwerlast mit FindFirst? das wäre auch wichtig für mich in diesem fall.
|
Re: WNetOpenEnum "Falscher Parameter"
Ist nur geraten, aber all zu hoch dürfte die Netzwerklast mit FindFirst nicht sein wenn du nicht gerade mit wildcards suchst, denn dann wäre ja maximal die struktur zu übertragen welche die eine gefundene Datei enthält.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:41 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