Beiträge von Runa

@Oscar

Ich glaube auch nicht, dass er da die Freigabe nimmt - sonst hättest du ja den Freigabenamen angegeben. Mit \\.\d:\ bekommste auch das Laufwerk D:\ - aber eben keine Freigabe.

AspirinJunkie:

Habe oben doch schon geschrieben, dass "\\.\" nicht geht. Wenn du "\\?\" verwendest, gibt er auch nur noch einen Fehler aus, dass er die Datei nicht findet.

@AspirinJunkie

Richtig, habe das Ganze in dem Codestück hier nicht richtig gemacht gehabt. Was solls - bin müde, sorry. Im Code den ich hatte war es aber richtig herum, da da aber noch viel Müll rumgeistert wollte ich nicht per C/P arbeiten ... egal wie glaubhaft das gerade für dich klingen mag.

Zu "Ansonsten": Nee, das zählt nur für bestimmte Dinge, zu dem Dateipfade nicht gelten. Mit deinem Ansatz findet er die Datei nicht mal, was in einem Error-Code #30 resultiert, statt dem oben beschriebenen #10.

_WinAPI_CreateFile() kommt problemlos zu dem Pfad...

UEZ: Bereits getestet. Das Problem besteht übrigens seit __HeapAlloc(). Die gibt den Fehlercode 10 zurück.

Edit: Verbessere: Du hattest recht - hatte mein Test-Return in der If ... -.-'

Edit2: $aRet[0] ergibt einen ganz krummen Wert - die Funktion erwartet 0 aber es kommt bei mir 3221225485 bei raus. Jetzt müsst ich rausfinden, was das eigentlich heißt...

Edit3: Zugriffsrechtsproblem ist übrigens "error: 30 extended: 0000052E"

WinAPI ist der Ansicht, dass der Ordner gar nicht existiert:

Global $sPath = '\\localhost\d\'


MsgBox(0, @extended, _WinAPI_FileExists($sPath))

Diesen Fehler gibt er aber bei sämtlichen UNC-Pfaden aus... ich habe da eine Theorie... moment. Gerade mal testen. mhm. Geht hier gerade nicht. Kann mal wer testen, ob der Zugriff auch von anderen Geräten auf diese Freigabe nicht funktioniert, WENN die Freigabe als Netzlaufwerk eingebunden wurde?

Ja, "nur das Intranet" ist ab und an doch schon recht heftig, selbst bei "nur 5MB" pro Nutzer pro Anmeldung. Und ja: Office ist größer - aber das wird auch nicht quer durch das Intranet gezogen.

So - damit kann ich was anfangen Mit deinem Script habe ich nämlich die selbe Fehlermeldung. Ich guck mal, ob ich was rausfinde

An der Funktion in der aktuellen Version liegt es definitiv nicht, da diese problemlos alle Daten liefert.

#include <Array.au3>
#include <WinAPIFiles.au3>
Local $aData = _WinAPI_EnumFiles("\\Webserver\htdocs\")
_ArrayDisplay($aData, '_WinAPI_EnumFiles')
Local $aData = _WinAPI_EnumFiles("\\Domaenencontroller\oeffentlich$\")
_ArrayDisplay($aData, '_WinAPI_EnumFiles')

Öffentliche Freigabe sowie versteckte Freigabe. Beide keinerlei Probleme.

Hier noch einmal die oben genannten und weitere eventuell relevante Fragen, deren Klärung im Raum stehen:

1. Was ist die Ausgabe, wenn du versuchst den Server - exakt so wie du ihn der Funktion übergibst - in die Kommandozeile eingibst?
2. Gibt es eventuell ein Rechteproblem? Nein, du sollst nicht raten, du sollst es noch einmal *explizit* prüfen. Hat der Nutzer, mit dem du aktuell angemeldet bist, Vollzugriff auf den Ordner?
3. Handelt es sich bei dem Verzeichnis um eines mit versteckter Freigabe, oder ist es eine öffentliche? Ist die versteckt, ist das "$" von elementarer Bedeutung.
4. Öffnest du den Pfad im Explorer, hast du da einen anderen Nutzer angegeben? Hier spielt die unterschiedliche Programmierung beider Funktionen eine elementare Rolle.
5. Welche Version von AutoIt verwendest du? Ich kann hier nur mit der aktuellsten testen. Wenn du eine ältere hast, konnte das Problem dort liegen.
6. Was ist der MD5-Hash deiner WinApiFiles.au3? Eventuell wurde hier was verändert was das Problem verursacht.
7. Welches Betriebssystem nutzt du - und damit auch das Script? Ich habe mit Windows 7x64 getestet.
8. Welches Betriebssystem nutzt das Ziel? Getestet auf Windows Server 2012 R2, Windows Server 2008 R2.
9. Hängt zwischen deinem Gerät und dem Zielgerät eventuell eine Firewall? Auch diese kann WinAPI-Befehle blockieren.

Es gibt geschätzt noch 90 andere Fragen, die man klären müsste, warum es offensichtlich im Netzwerk normalerweise problemlos funktioniert - bei dir aber eben nicht. Also wie wäre es, wenn wir einfach gemeinsam versuchen das Problem zu ergründen, statt dass du alles was ich sage von Anfang an in Frage stellst.

Ergänzung:

Du hast den Fehler "ERROR_BAD_ENVIRONMENT" mit der Spezifikation "STATUS_INVALID_PARAMETER". Das schreit eigentlich nach einer Sache: Du kommst nicht von a) nach b) wenn du nicht über den Explorer gehst- wie es FileListToArray beispielsweise macht. Das könnte 3 Hauptursachen haben:

1. Dir fehlen die Zugriffsrechte.
2. Da ist eine Firewall zwischen dir und dem Zielgerät.
3. Du greifst im Explorer mit einem anderen Nutzer als mit dir selbst auf den Ordner zu.

Kann das Problem nicht nachstellen... sowohl mit "normalen" Freigaben als auch mit verstecken Freigaben nicht das geringste Problem.

Was ist deine Ausgabe, wenn du "\\Server\d\" in die Kommandozeile wirfst? Hast du eventuell zu geringe Rechte auf das Verzeichnis? Ist es vielleicht eine versteckte Freigabe? Eventuell greifst du nicht mit dem Nutzer, mit dem du das Script ausführst auf das Verzeichnis zu? All das würde zu Problemen führen.

Das stimmt, chip. Aber klärt nicht wirklich sein Problem, dass er mit seiner Heransgehensweise auch bei anderen Installationsroutinen gehabt hätte, die keine silent-Installation unterstützen.

1. Rate ich zur Verwendung von ordentlichen Thread-Titeln. "Geht nicht" ist definitiv keiner davon. Denn die Funktion geht - man muss nur mal in die Hilfe gucken, um sofort zu sehen, welchen Fehler du gemacht hast.

2. Du solltest eher eine aktuelle Firefox-Version installieren. Der Button "&Weiter >" existiert seit etwa 5 Versionen nicht mehr im Firefox. Das sind mittlerweile maximal 4 Clicks für eine Installation:

1. Einstellungen
2. Keine Daten über die Installation an Mozilla senden
3. Kein Standardbrowser
4. Installieren

3. Zu deinem hier geschilderten Problem:

Du weißt AutoIt an, nach einem Fenster zu suchen, das a) Den Titel "Mozilla Firefox-Installation" besitzt und b) Den Text "&Weiter >" als Text beinhaltet - was schlichtweg nicht existiert. Das kannst du gerne mit Au3Info prüfen - es hat diesen Text nicht. Es beinhaltet nur ein Control, welches diesen Text hat. Die korrekte Syntax von

controlclick("Mozilla Firefox-Installation", "&Weiter >", "Button2")

Wäre demnach ControlClick("Mozilla Firefox-Installation", "", "Button2") oder in meinen Augen deutlich besser: ControlClick("Mozilla Firefox-Installation", "", "[CLASS:Button; INSTANCE:2]")

chesstiger :

Naja: Folgendes Szenario - Kunde zieht das Script beim Login. Die Leute fangen alle zwischen 8 und 8 Uhr 5 an. Es sind 180 Mitarbeiter. Da ist das nicht die Frage ob 1MB oder 5MB sondern ob fast ein GB durch das Netzwerk gezogen werden muss, oder ob es gerade mal knapp unter 200MB sind. Und 180 Leute sind noch die eher kleineren Kunden. Klar: Nur das Script alleine ist da noch recht "unproblematisch". Nehmen wir aber mal 4 oder 5 dieser Script-Größen (was nicht unüblich wäre, gerade wenn ThinClients im Betrieb sind) - dann reden wir von 1GB oder 5GB die in maximal 5 Minuten quer durch das Netz gezogen werden, dass so schon belastet wird. So viel hast du nicht mal, wenn alle YouTube aktiv haben.

autoBert:

Dennoch zerstört es ganze Scripte. Den "Tipp" habe ich schon bei Hilfe und Support bekommen.

Doch habe ich - und er hat von insgesamt 10 Scripts 7 nach seinem "werken" zerstört. Wenn er das bei dir nicht hat: Glückwunsch - nutze ihn.

Ich bleibe dabei von Haus aus nicht "the biggest possible method" zu verwenden, sondern die pragmatischste, die für den Nutzer keinerlei Nachteile hat. Eben sowas wie ein deaktiviertes Label als Rahmen hinter dem Input, um den Rahmen einfärben zu können, statt GDI+ auszupacken. (1MB alleine für deren Bibiliothek... zum Vergleich: Die WinAPI hat gerade mal 0.8 MB - mithalten kann dort nur ein kommerzielles Produkt (VK: >500€) von mir mit fast 1500 Zeilen Code und genau drei Includes - das hat ebenfalls 1MB Größe).

Wenn du weiter diskutieren willst, bitte einen Moderator, diese Unterhaltung in einen seperaten Thread im Offtopic-Bereich zu verschieben.

Guten Morgen - hätte doch ein Kaffee trinken sollen... alles gut - die 3 hatte ich auch bekommen...

Kopierte Version aus dem Spoiler gibt mir den Fehler nicht - allerdings behauptet sie steif und fest, vom 26.08.2015 bis zum 28.08.2015 wären bundesweite Feiertage... warum bin ich dann an die Arbeit gefahren?

BugFix :

Ich habe einfach oben deine Datei heruntergeladen - ich habe also weder kopiert noch gepastet.

Da fehlt wohl noch etwas error-handling:

Das bekomme ich, wenn ich die oben genannten Werte einsetze...

@Chessi Das hat aber wieder den Nachteil dass man die komplette GDI+ Library mitschleppen muss. Jeder Include wird vollständig mitgenommen. Und GDI+ ist nicht gerade Klrin und hat noch den einen oder anderen Include selbst…

#include <GUIConstants.au3>


$gui = GUICreate("", 300, 200)
GUISetBkColor (0xFFFFFF)
$Input_Border =GUICtrlCreateLabel("", 9, 9, 192, 22)
GUICtrlSetBkColor($Input_Border, 0x666666)
$Input = GUICtrlCreateInput("", 10,10,190, 20, -1, $WS_EX_TOOLWINDOW)
GUICtrlSetBkColor($Input, 0xDEDEDE)
$Button = GUICtrlCreateButton("Absenden", 9, 35, 100, 21)
GUISetState()




While 1
    $msg = GUIGetMsg()
    Switch $msg
        Case $GUI_EVENT_CLOSE
            Exit
		Case $Button
			If GUICtrlRead($Input) = "" Then
				GUICtrlSetBkColor($Input_Border, 0xFF0000)
				GUICtrlSetState($Input, $GUI_FOCUS)
			Else
				GUICtrlSetBkColor($Input_Border, 0x666666)
				GUICtrlSetState($Input, $GUI_FOCUS)
			EndIf
    EndSwitch
WEnd

Einfach und Pragmatisch. Alternativ lässt sich das Label auch - wie Kana geschrieben hat schlicht disablen. Warum also das Script unnötig mit der kompletten GDI+-Library aufblähen?

Das wäre gut. Kennst du ne Quelle wo ich das eventuell nachlesen könnte? Wäre mir eher unangenehm das bei diesem speziellen Kunden testen zu müssen.

Huhu, schon jemand Erfahrungen damit gemacht wie @DesktopDir damit umgeht wenn der Ordner umgeleitet wurde? Kommt AutoIt damit klar oder muss ich das selbst abfangen?

Grüsse
Bioshade