Beiträge von Lottich

Hab deinen Fehler gefunden. Du hast RunWait falsch verwendet, indem du jeweils 1x  , "" zuviel verwendest. Oder korrekt ausgedrückt:
Dein WorkingDir hast du an der falschen Stelle platziert.

Ändere mal deinen Code von  RunWait(@ComSpec & ' /c ' & 'dir /n /os /4 /s > index_.txt' & '"', "", $sPath, @SW_HIDE)

nach  RunWait(@ComSpec & ' /c ' & 'dir /n /os /4 /s > index_.txt' & '"', $sPath, @SW_HIDE)

mit den anderen RunWaits natürlich sinngemäß genauso verfahren.

@bazii: Weisst du, was das beste ist an selbst erstellten Funktionen?

Du kannst ihnen Daten "mitgeben". Was bedeutet das? nehmen wir mal ein Beispiel aus deinem Code:

Func _indextxt()
	$sPath = GUICtrlRead($Input1)
	If Not FileExists($sPath) Then
		MsgBox(270400, "Kein Ordner-Pfad angegeben!", GUICtrlRead($Input1))
		Exit
	EndIf
	RunWait(@ComSpec & ' /c ' & 'dir /n /os /4 /s > index_.txt' & '"', "", @ScriptDir, @SW_HIDE)
	;Sleep(200)
	RunWait(@ComSpec & ' /c ' & 'cmd /U /C TYPE index_.txt > index.txt' & '"', "", @ScriptDir, @SW_HIDE)
	;Sleep(200)
	RunWait(@ComSpec & ' /c ' & 'del index_.txt' & '"', "", @ScriptDir, @SW_HIDE)
	;Sleep(200)
	FileMove(@ScriptDir & "\" & "index.txt", $sPath & "\" & "index.txt", 1 + 8)
	;Exit
EndFunc   ;==>_indextxt

Gleich in der 1. Zeile kannst du der Funktion Daten mitgeben, in 2 Varianten

• Variante 1: Func _indextxt($variable_die_ich_mitgeben_habe)

In diesem Fall MUSST du beim Aufruf der Funktion (bei dir ist es der Aufruf in der While Schleife mit: Case $Button2) der Funktion eine Variable mitgeben, da sonst die Funktion nicht funktioniert und das Script abschmiert

• Variante 2: Func _indextxt($variable_die_ich_mitgeben_habe = "irgend ein Text, zum Beispiel eine Pfadangabe ^^")

Hierbei musst du nicht unbedingt was beim Funktionsaufruf mitgeben, KANNST es aber. Gibst du nichts mit, wird automatisch "irgend ein Text, zum Beispiel eine Pfadangabe ^^" benutzt. Gibst du doch etwas mit, wird "irgend ein Text, zum Beispiel eine Pfadangabe ^^" mit dem von dir mitgegebenen Daten ausgetauscht.

Warum ist das nun so eine tolle Sache?? Ganz einfach. Weil es dir das Programmieren ungemein erleichtern wird!!!!
Diese mitgegebenen Daten kannst du als eine Art Platzhalter in deiner Funktion verwenden. so würde aus deiner Funktion zum Beispiel sowas werden

Func _indextxt($Variable_die_ich_mitgegeben_habe = @ScriptDir)
	RunWait(@ComSpec & ' /c ' & 'dir /n /os /4 /s > index_.txt' & '"', "", $Variable_die_ich_mitgegeben_habe, @SW_HIDE)
	;Sleep(200)
	RunWait(@ComSpec & ' /c ' & 'cmd /U /C TYPE index_.txt > index.txt' & '"', "", $Variable_die_ich_mitgegeben_habe, @SW_HIDE)
	;Sleep(200)
	RunWait(@ComSpec & ' /c ' & 'del index_.txt' & '"', "", $Variable_die_ich_mitgegeben_habe, @SW_HIDE) ; Watum eigentlich diese Zeile?? wird da nicht die erstellte IndexDatei wieder gelöscht??? Wenn du die Datei vorher löschen willst, solltest du diesen Befehl am Funktionsanfang verwenden. Sonst löschst du die Datei immer wieder gleich nach dem Erstellen und zwar so schnell, dass du davon nicht mal irgendwas mitkriegst ^^
	;Sleep(200)
;~	FileMove(@ScriptDir & "\" & "index.txt", $sPath & "\" & "index.txt", 1 + 8) ; diese Zeile sollte nicht mehr nötig sein...
	;Exit
EndFunc   ;==>_indextxt

Wie du siehst, hab ich hier in den RunWait Zeilen das Macro @ScriptDir gegen $Variable_die_ich_mitgegeben_habe ausgetauscht. Aktuell würde sich aber noch immer nichts am Funktionsverhalten ändern, weil die mitgegebe Variable dem ScriptDir Macro entspricht.
Also geben wir der Funktion die gewollten Daten mit, damit sich das WorkingDir (Arbeitsordner) mit. Das geschieht nun in deiner While Schleife. Da wo du geschrieben hast: Case $Button2

While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $Button2
;~ 			StartAnim()
;~			_indextxt($Variable_die_ich_mitgeben_will) ; <--- so musst du dir das vorstellen
			_indextxt(GUICtrlRead($Input1))
			Sleep(200)
;~ 			StopAnim()
WEnd

jetzt wird, wenn Button2 geklickt wird, automatisch das Control "ausgelesen" indem der Pfad ausgewählt wurde und in der Funktion weiter verarbeitet.

Und BÄÄÄÄÄÄNGGGG, ist dein WorkingDir Problem, worauf dich @Kanashius bereits hingewiesen hat, erledigt.

Edit kurz vorm Absenden: OMG, wie blind bin ich denn?
eigentlich brauchst du ja nur das @ScriptDir gegen $sPath austauschen, steht ja in Zeile 2 der Funktion, aber du verwendest es nicht wie du willst
Tausche einfach in den RunWait Zeilen das @ScriptDir gegen $sPath aus. Das sollte schon helfen.
Jetzt hab ich aber schon so viel geschrieben, da weigere ich mich jetzt, das alles wieder zu löschen

Ich denke auch, dass dies eine wirklich gute Idee ist, die irgendwie umgesetzt werden sollte. Das würde viele Vorteile mit sich bringen. Und auch wie @BugFix bereits sagte, wird der Lernprozess
nochmals gesteigert, weil garantiert mehr im Kopf hängen bleibt, als würde man versuchen alleine zu lernen.

Also ich bin mir 100%ig sicher, dass mich das in meinen AutoIt Kenntnissen weiter bringen würde!

Andy, ich kann es nicht glauben, dass ICH dir diesmal helfen kann.
DAS werd ich mir irgendwo vermerken

Öffne die Eigenschaften der Dateien. Da kannst du dann ein Häkchen bei "zulassen" setzen.
Das Wars dann schon

Have a nice day.

MfG Lo..

Diese Macros (bezogen auf Pfad bezogene Macros) sind keine Allheilmittel. Sie dienen ausschließlich zur Unterstützung. Einfach ein Macro wie zB: @DesktopDir
wird in den meissten Fällen nicht ausreichen. Es hilft aber dabei die Pfadangabe zu vereinfachen.

Amgenommen, du willst etwas auf den Desktop deines Programmbenutzers platzieren, mit Unter- und Unterordner. Vermutlich wirst du aber diesen Pfad nicht kennen, weil dir höchst
Wahrscheinlich der Benutzername nicht bekannt ist.

@DesktopDir erspart dir dann "die Mühe", den korrekten Pfad zu ermitteln.
Aber dann ist man ja noch immer nicht im gewünschten Zielordner angelangt. Also verbindet man das Macro mit dem Rest des Pfades. Beispiel:

Local $Zielpfad, $Rest_vom_Pfad, $zuvor_erstelltes_InputControl


$Rest_vom_Pfad = "\Unterordner1\Unterordner2\"
$Zielpfad = @DesktopDir & $Rest_vom_Pfad


;oder mit ausgelesenem Control aus dem GUI... Bsp: im InputControl steht "Textdatei"
$Zielpfad = @DesktopDir & $Rest_vom_Pfad & GuiCtrlRead($zuvor_erstelltes_InputControl) & ".txt"     ; ".txt" ist die Dateiendung, damit es auch eine Textdatei wird


; Heraus käme dann als Zielpfad z.B.
; C:\User\PopelHeino der Dritte\Desktop\Unterordner1\Unterordner2\Textdatei.txt

Du siehst also, dass Macros alleine hier nicht weiter geholfen hätten.

Zitat von bazii

Für was steht 1+8?

Das sind die FLAGs, die angeben, wie genau sich der Befehl oder besser: die Funktion verhalten soll. Sind für ziemlich jede Funktion verschieden. bei FileMove() geben sie an dass:
1 --> eine bereits existierende Datei ÜBERSCHRIEBEN werden soll 
8 --> die Dateistruktur erstellt werden soll, FALLS diese noch nicht existiert 

Die beiden Flags könnte man auch zusammen addieren und gleich von vornherein eine 9 schreiben. Die vordefinierten Funktionen erkennen das und "wissen", was sie tun sollen.

Zu dem ComSpec Gedöns kann ich dir leider nichts sagen, hab das noch nie gebraucht und somit NULL Kenntniss.

Hey Tweaky

wenn es dir nur ums Ausführen von Regedit geht, dann kannst du das per Ausführen am einfachsten realisieren (ich denke aber, dass du das bereits weisst ). Nur wie bekommt man "Ausführen" zu sehen??

bei mir (winX pro x64):
navigiere nach AppData -> Roaming -> Microsoft -> Startmenü -> Programme -> Windowssystem

Dort befindet sich ein "Ausführen" Link. Diesen hab ich dann einfach in die Taskleiste gezogen und angebunden.

Vielleicht solltest du mal "Dieser PC" anstelle von "Computer" versuchen. zumindest wird ja "Dieser PC" nun verwendet. Vielleicht hilfts?!

MfG Lo..

Edit: Jetzt weiss ich was du mit "Computer" meinst. da klappt das natürlich nicht mit "Dieser PC"!

3 Fehler, die mir sofort ins Auge springen: Zeilen 2, 5, 28

Das hat dir @BugFix bereits gezeigt, in einem anderen Thread:
Case Problem

Schau dir mal die Zeilen 12 bis 30 genauer an.

Hallo Christian

Grundsätzlich ist dein Vorhaben durchaus mit AutoIt realisierbar. Allerdings nur für Windows Systeme und leider nicht für Tablets.
Soweit mir bekannt ist, arbeiten diese ausschliesslich mit ARM-Prozessoren. Damit kann AutoIt allerdings nichts anfangen.

MfG Lottich

Das mit den Desktop Rechten kannst du doch ganz leicht bei dir selber testen. Einfach neue Benutzer anlegen, die verschiedene Rechte besitzen. Kannst diese ja dann später wieder löschen.

Hallo fred,

du kannst Batch in keiner Weise mit AutoIt vergleichen. Das geht schon bei der Syntax los. (Die Art und Weise, wie der Code geschrieben werden muss)
Deine Batch For Schleife wird, wenn du diese 1:1 in AutoIt übernimmst, NIEMALS funktionieren.
Auch dein Run(@Comspec blabla ... wird nie funktionieren, weil die Syntax einfach falsch ist.

Öffne einfach mal den Scite Editor und drück dann F1. Da öffnet sich die integrierte Hilfe Datei. Da sind sehr viele Beispiele die du dir ansehen kannst, um die Syntax "besser kennen zu lernen".
In AutoIt werden zb einzelne Funktionsparameter immer mit einem Komma getrennt, nie mit einem Leerzeichen, wie es in Batch üblich ist.

In der Hilfe kannst du auch nach dem Befehl Run suchen und dir die/das Beispiel dazu anschauen. Da findest du auch For-Schleifen...

MfG Lo..

Ich persönlich wünschte mir, dass Lösung 1 in Kraft tritt. Andernfalls würde ich zu Lösung 3 tendieren. Sorry GunFood, aber das ist nunmal meine Meinung.
Das ist vorerst mein Senf zu diesem Thema.

Danke @Oscar. An dieses Control dachte ich gar nicht...
Gibt aber noch mehr Inputs. Wäre schon nicht schlecht, wenn ich diese UDF nutzen könnte.
Aber wenn keiner diese mehr rumliegen hat, muss ichs selber prüfen, was allerdings ziemlich unsauber werden wird.

Hey @chesstiger

hast du diese UDF noch bei dir rumliegen? ich hätte Verwendung dafür. In einigen Inputs will ich dass nur Uhrzeiten eingetragen werden können.
Keider haut das ja mit den Downloads nicht wirklich hin...

MfG Lo..

Hi Andy,

letztendlich hab ich das auch mit ConsoleWrite() erledigt. Schliesslich hat es beim Script von Oscar ja auch funktioniert.
Jetzt allerdings ist mir aufgefallen, dass ich dem Programm noch etwas hinzu fügen sollte. Nämlich wie lang meine Ma bei dem Kunden gebraucht hat. Sieht nicht nur im Fahrtenbuch besser aus,
sondern ist auch für die geplante Rechnungsschreiberei unerlässlich! Dazu muss ich etliche Funktionen umschreiben. Ne ganze Menge an Arbeit, die da noch auf mich zu kommen wird.

Und ich weiss schon jetzt, an welcher Stelle ich wieder Unterstützung von euch brauchen werde: Daten aus dem GUI auf Papier bringen...
Das werd ich brauchen um das Fahrtenbuch sowie die Rechnungen auszudrucken. Aber so weit bin ich noch nicht. Wird dann auch ein neuer Thread werden.

Also bis demnächst

MfG Lo..

Gut zu wissen.
Es ist nicht geplant, dass Useraktionen stattfinden können, während die auswertende Funktion läuft.
Sie befüllt lediglich einige Labels mit Daten, danach ist sie durch. Ich hab das _ArrayDisplay() lediglich benutzen wollen um zu sehen, welche Daten ich nun tatsächlich zurück bekomme.
Als Kontrolle, so zu sagen.

danke, dachte mir bereits, dass es an GUIRegisterMsg() liegen muss.
Hab nicht gewusst, dass _ArrayDisplay() auch auf ein Event wartet.

Vielen Dank nochmals!!!

Beide Varianten funktionieren prima. Hab mich aber für Oscars Variante entschieden, weil dort kein extra Button geklickt werden muss.
Damit ich mit den ermittelten Daten (Jahr|Monat|Tag) aus WM_Notify() weiter arbeiten kann, habe ich die Daten innerhalb WM_Notify() an eine andere Funktion übergeben.
Funktioniert prima.

Jetzt hab ich dazu nur noch eine kleine Frage. Wenn ich nun in der anderen Funktion, an der ich die Daten übergeben habe, ODER an der Stelle in WM_Notify(), wo ich die Daten übergebe,
ein _ArrayDisplay() anwenden will, hängt sich das Script auf. (Ich kann aber mit den Arrays weiter arbeiten, indem ich die Arrays direkt anspreche. Dann bricht es nicht ab.)

Warum ist das so?

Ich muss mich dafür entschuldigen, dass ich mich ungenügend ausgedrückt habe! Dafür ärgere ich mich sehr über mich selbst.
Beim Verfassen des Threads habe ich nicht weit genug voraus gedacht und nur 1 von 2 Probleme erwähnt. Bis zum 2. Problem bin ich allerdings selbst noch nicht gekommen...

Mittlerweile kann ich durch die Hilfe von @Oscar und @Kanashius nun auch die Tage im TreeView sehen.
Leider reicht das noch nicht aus. In der While-Schleife, die das GUI (wieso will ich immer DIE GUI schreiben?!) "am Leben hällt", benötige ich die Handles der TreeViewItems,
damit ich bei Klick auf diese die Werte benutzen kann um weiter arbeiten zu können.

Ich weiss, dass sich das nicht gehört und gar nicht gerne gesehen wird. Ich fühl mich grad wie ein "Nimm mir mal ganz schnell den Arm aus der Sonne Typ".
Könnt ihr mir sagen, wie:
- ich es anstellen muss, dass ich die erstellten TVItems in die While-Schleife eintragen muss?
(das sollte ich dann selber hinbekommen: - ich bei Klick auf ein TVItem den Text des gewählten items und den Text des zugehörigen Parents bekomme?)

Vielen Dank euch beiden! Ich konnte beide Varianten ohne Probleme in mein eigentliches Script erfolgreich übertragen.
Manchmal sieht man halt nur noch Zahlen und Buchstaben anstatt Code...