Ich möchte dabei aber sicher gehen, das nicht die Systempartition erwischt wird und brauche daher die Zahl aus der Datenträgerverwaltung der "nicht Systempartition".
Lies doch dich Ausgabe von diskpart mit StdOutRead (oder stream es in eine Datei und lies die aus)?
Mit RegEx solltest du auch schnell an das Ergebnis kommen.
Wenn ich an der Funktion die von dir beschriebenen "Script-Breaking Changes" durchführe, schiesse ich mir als Ersteller einer Programmiersprache permanent ins Knie!
Beispiel Funktion(), da könnte ich haufenweise Änderungen und "Script-Breaking Changes" dranhängen, ich könnte aber auch Funktion1(), Funktion2(), FunktionXX(), FunktionYY() uswusf erstellen, mit individuellen, "weiterentwickelten" Eigenschaften. Wer bin ich denn als Programmiersprachenersteller, einem "Programmierer" vorschreiben zu wollen, was er letztendlich zu tun und zu lassen hat?!Was mache ich denn als Programmierer, wenn der Programmiersprachenersteller GENAU DIE Funktion, deren Ergebnis ich GENAU SO haben wollte, einfach ändert?!
Nein, mir persönlich ging es darum, dass man einfach mit der Zeit dazu lernt und an einem Punkt ankommt wo man einige Sachen einfach ändern sollte, da man sie nicht vorausplanen konnte.
Und das nicht permanent mit jeder Version sondern auf einen Schlag und dann ist erstmal Ruhe, dann muss auch nicht permanent was geändert werden sondern nur einmal.
Abwärtskompatibilität ist natürlich immer eine feine Sache aber irgendwann vermengt sich das ganze und man muss sich halt fragen, ob es sich lohnt 40 Jahre alten Programmcode mitzuschleifen den man durch effizientere Implementationen ersetzen könnte. Auch wenn man die neue Implementation nehmen kann und die alte drinlässt, es bläht sich doch nur alles auf.
In AutoIt würde ich z.B. GUISetState ändern, weil mir das zu inkonsequent ist die Flags vor der GUI zu setzen (auch wenn AutoIt für eine GUI gedacht war) und das ist nur die Spitze des Eisberges.
Würde man immer Funktion1 Funktion2 Funktion3 nehmen, so macht man das ganze, meiner Meinung nach, nur schlimmer weil man nur Symptome bekämpft aber nicht das Problem.
Inwiefern man nun die ursprüngliche Funktion ändert oder neue hinzufügt ist sicherlich von Fall zu Fall unterschiedlich, ich denke da sind wir uns beide einig.
Aber, dass eine Sprache konsequent ihre Parameter benennen sollte (sowie ihre Reihenfolge) und die selben Typen in ähnlichen Funktionen erwartet sollte doch wohl auf der Hand liegen.
Das ist es was mir bei AutoIt solche Kopfschmerzen bereitet.
Dann können wir dir nicht weiterhelfen.
Nebenbei bemerkt, die Skripte-Sektion ist zum Vorstellen gedacht, nicht um Hilfestellung zu bekommen. Poste bitte beim nächsten Mal in Hilfe & Unterstützung.
Oscar movest du das hier bitte?
Ich meinte im Quellcode...
Aber so wird das ganze nichts werden, ich kann dir nicht ständig Infos aus der Nase ziehen, versuch doch mal den aktuellen Quellcode zu posten bevor das Fenster offen ist und nachdem es offen ist.
Den Quellcode musst du im IE aus dem DOM-Explorer auslesen! Rechtsklick > Quellcode anzeigen zeigt den ursprünglichen Code ohne jegliche JS-Aktion an!
Bis dahin kann ich dir wirklich weiterhelfen.
Sensible Daten kannst du ja zensieren (nicht streichen, zensieren!)
Liegt das Input in einem <iframe>?
Rechtsklick mal eins der Felder, welches du ausfüllen möchtest, und dann auf Element untersuchen und such die Id/Name raus und versuch es mal zu setzen.
Kannst du uns Zugang zu der Seite bereitstellen um zu testen um was es sich handelt?
Die Elemente sollten auch mit den Funktionen erreichbar sein, da es sich hier nur um Javascript handelt.
Ansonsten können wir dir da nicht wirklich weiterhelfen.
Generell empfiehlt es sich hier nicht _ArrayInsert zu verwenden sondern lieber einmal das Array zu resizen (du kannst ja vorher errechnen wie groß es wird) und dann es zu befüllen.
Die Erweiterung eines Arrays kostet immer Zeit die du dir einsparen kannst.
Weißt Du , warum bei einer For-Schleife der Ausdruck in der For-Schleife nicht aktualisiert wird, während bei einer While-Schleife der Ausdruck bei jedem Durchlauf aktualisiert wird?
So sind For-Schleifen nun mal in AutoIt implementiert worden. In C# wird die Bedingung bei jeder Schleifeniteration anfänglich überprüft in AutoIt nur einmal.
While-Schleifen evaluieren hingegen immer bei jeder Iteration, wäre das nicht möglich (ebenso wie bei Do-Until), dann wäre AutoIt eine totale Sprache die bei jeder Eingabe hält (wenn man mal von Ausführung anderer Skript absieht).
Array rückwärts - bei mir tritt ein kleiner Fehler auf. Bei Dir auch?
Das kann sein, ich habe mir ehrlich gesagt auch nicht viel Mühe gegeben da es hier ja nur um Proof-Of-Concept geht.
Wenn man da den Index und die Eingaben für _ArrayInsert anpasst kriegt man sicherlich, auch dadrunter ein "Test 440".
Hätte man _ArrayInsert vernünftig implementiert, hätte man sich auch _ArrayAdd komplett sparen können, als Sonderfall muss man halt _ArrayAdd statt _ArrayInsert verwenden.
Rückwärts durchlaufen funktioniert übrigens auch bei anderen Problemen.
Beispiel: Ich will ein Array durchgehen und jedes Element löschen welches eine bestimmte Voraussetzung erfüllt,
dann durchlaufe ich das Array von hinten nach vorne, da die Elementindizes nach vorne hin konsistent bleiben.
Lösche ich von vorne nach hinten, so verkleinert sich die Größe meines Arrays und ich gehe Out Of Bounds mit meinem For-Header.
Das ist ein sehr toller Trick den man sich auf jeden Fall merken sollte.
#include <Array.au3>
$Quell_Datei = @ScriptDir & "\Testdatei Regionen.au3"
Local $aFile = FileReadToArray ( $Quell_Datei )
Local $i = 0
While $i < UBound($aFile)
If StringLeft ( ($aFile[$i]) , 8 ) = '#Region ' Then
_ArrayInsert ( $aFile, $i + 1, "Test " & StringRight ( $aFile[$i] , StringLen ( $aFile[$i] ) -8 ) )
$i += 1
EndIf
$i += 1
WEnd
_ArrayDisplay ( $aFile , "Ergebnis" )#include <Array.au3>
$Quell_Datei = @ScriptDir & "\Testdatei Regionen.au3"
Local $aFile = FileReadToArray ( $Quell_Datei )
For $i = UBound($aFile) - 1 To 0 Step -1
If StringLeft ( ($aFile[$i]) , 8 ) = '#Region ' Then
_ArrayInsert ( $aFile, $i + 1, "Test " & StringRight ( $aFile[$i] , StringLen ( $aFile[$i] ) -8 ) )
EndIf
Next
_ArrayDisplay ( $aFile , "Ergebnis" )Aktualiser die Seite mal, ich hab meinen Post mehrfach editiert.
Das liegt daran, dass du anfänglich nur einmal die Größe des Arrays holst.
Anschließend fügst du immer mehr Elemente ein aber die ursprüngliche Grenze bleibt ja, deshalb läuft es auch nur bis 220 da du 440 Zeilen hast (und du immer einen Index überspringst, deshalb nur die Hälfte).
Also entweder eine While-Schleife nehmen oder du gehst das ganze von hinten durch, dann bleiben die Arrayindizes nämlich nach vornehin konsistent.
Und noch als kleiner Tipp nebenbei:
_ArrayInsert ( $aFile, $i + 1, "Test " & StringRight ( $aFile[$i] , StringLen ( $aFile[$i] ) -8 ) )
;oder
($aFile[$i])Bitte nicht so einen Code schreiben, wenn es vom Interpreter nicht ausdrücklich verlangt wird (ab und zu muss man ($aFile[$i]) nutzen), dann die überflüssigen Klammern weglassen und statt
StringRight und StringLen lieber StringTrimLeft nehmen, StringTrimLeft($aFile[$i], 8) erledigt dasselbe und ist wesentlich kürzer.
Du hast vergessen den Forschleifenzähler $i um eins zu erhöhen wenn du _ArrayInsert nutzt. Wenn du nämlich hinter dem aktuellen Element einfügst musst du das ja praktisch überspringen.
So klappts:
#include <Array.au3>
Local $aFile = [ _
'# 2 ', _
'a', _
'# 2 ', _
'b', _
'# 2 ', _
'c', _
'# 2 ', _
'd']
For $i = 0 To UBound($aFile) - 1 Step 1
If $i < UBound($aFile) -1 And StringLeft($aFile[$i], 3) = '# 2' Then
_ArrayInsert($aFile, $i + 1, '# 2a' )
$i += 1
EndIf
Next
_ArrayDisplay($aFile, '$aFile')
_ArrayToClip ( $aFile , @CRLF )Kannst du deinen Code besser formatiert hochladen? TimerInit gibt kein Handle zurück sondern einen internen Timestamp der nicht standardtisiert ist.
Die Hilfe warnt davor ihn für andere Zwecke zu "missbrauchen" da das zu Fehlern führen kann.
Und wieso kriegst du es nicht zum laufen?
Du kannst auch mit FileReadToArray es in ein Array lesen und das Array mit einer For-Schleife durchgehen und währenddessen mit StringInStr nach "HERGESTELLT" suchen.
Mein Skript parsed dir direkt in einem Befehl alle Zeilen heraus, so hast du es halt Schleife.
Brauchst du denn die Zeilennummer oder die IP-Adressen?
Reguläre Ausdrücke sind da wohl eher der way-to-go.
#include <Array.au3>
Local $sFile = FileRead("test.txt")
Local $aRegEx = StringRegExp($sFile, "(TCP (?:\d+\.\d+\.\d+\.\d+:\d+ ){2}HERGESTELLT)", 3)
_ArrayDisplay($aRegEx)oder wenn du die IP-Adressen direkt auslesen möchtest so (die liegen alle hintereinander):
#include <Array.au3>
Local $sFile = FileRead("test.txt")
Local $aRegEx = StringRegExp($sFile, "TCP (\d+\.\d+\.\d+\.\d+:\d+) (\d+\.\d+\.\d+\.\d+:\d+) HERGESTELLT", 3)
_ArrayDisplay($aRegEx)Genau das ist ja so eine Unsitte heutzutage, in meinen Augen würde ein intelligenter Programmierer
eine Programmiersprache so entwickeln, daß sie jederzeit erweiterbar wäre, aber auf keinen Fall etwas an
bestehenden Befehlen und deren Parametern durch Verschlimmbesserung geschieht, was heute aber laufend vorkommt.
Sowas ist einfach ein inakzeptabler Unsinn, bestehende Befehle kaputt zu verbessern, sodass alter Quellcode plötzlichnicht mehr fehlerfrei ausgeführt wird.
Wenn du das im englischen Forum loslässt dann wirst du mehrmals dafür gesteinigt werden, wir haben leider keinen Zugang zum Sourcecode.
Es gibt viele, wirklich viele Sachen die ich in AutoIt gerne ändern würde aber nicht kann.
Dein Frust wird hier natürlich verstanden, aber es wird sich dadurch nichts bessern.
Teilweise ist das auch verständlich, Script-Breaking Changes gehören einfach dazu, man kann nicht 20 Jahre in die Zukunft schauen und dafür vorprogrammieren.
An einem bestimmten Punkt befindet man sich einfach in einer Sackgasse und muss den bisherigen Zweig komplett wegschmeißen oder sich irgendeine wackelige Konstruktion zurechtfriemeln und wie du schon erwähntest offenbar nur letzteres.
Zu deinem Firefox Beispiel: Ich war schon bei FireFox 3 irritiert warum die 4 überhaupt rausgebracht hatten, der lief nämlich noch richtig toll und jetzt hauen sie jede Woche eine neue Version raus.
Chrome ist mittlerweile bei Version 69.... und es kann mir niemand erzählen, dass in der Zeit so viele Webtechnologien dazugekommen sind ein Major-Update durchzuführen, vielleicht interpretieren sie auch Versionsnummern einfach anders.
Aber ich schätze viele User hier haben die Konsequenzen eh schon gezogen, wenn man sich ansieht
was hier und im englischen Forum oder in Wambo's altem Forum so los war zwischen 2005 und 2012.Da war einiges los und es gab hervorragende Programmierer die sehr schöne Programme entwickelt und an alle
weitergegeben haben. Aber heute ist ja im Vergleich dazu schon beinahe Totalstillstand eingetreten.
Das ist aber nicht ausschließlich darauf zurückzuführen, Win32 Controls kommen allmählich ziemlich in die Jahre und für die neuen Controls gibt es glaube ich sowas wie AutoIt Window Info noch nicht.
AutoIt ist einfach nach Win7/8 nicht mehr so einsatzfähig wie (so wie es gedacht war!!) in 98/XP/7. Aber man kann nach wie vor tolle Programme basteln.
Dann wird dir auch auffallen, daß meine Variante das tut was sie tun soll und die von alpines macht einige Dinge eben nicht wie es gehört.
Das ist auch durchaus verständlich ich habe die 3.3.14.2 am laufen und das Skript wurde sonst wann compiled.
Bei jeder großen Versionänderung gibt es viele Script-Breaking Changes, es ist überhaupt ein Wunder, dass das Programm ansatzweise das macht, was es soll.
Ich möchte keine neuen Dialog Fenster erzeugen, sondern aus einem Programm entsprechende Werte auslesen.
:facepalm:
Wir haben absichtlich die GUI erzeugt um ein fremdes Fenster zu simulieren und von dort die Infos abzugreifen, das ist auch der Grund warum wir nicht direkt die GUI-Elemente ansprechen,
sondern sie uns über den Umweg mit ControlGetHandle und dem Identifier holen.
