Beiträge von misterspeed

Zitat von Zattoo

doch es ist doch ein beispielscript dabei...?

Willst mich verarschen? Ich hab geschrieben ein Script in dem der Fehler noch auftritt. Was soll ich mit deinem oder viel mehr meinem mit zusätzlichn includes vollgeklatschten funktionierenden Script? Wie soll jemand deinen Fehler finden wenn du kein fehlerhaftes Script bereitstellst?

Zitat

4. Poste die Zeilen der Consolen Ausgabe der Füllfunktion.
5. Poste das komplette Script oder zumindestens eine lauffähige Version in der das Problem noch auftritt.

Zitat von Zattoo

4. fällt ja auch wegen 2 weg

Punkt 4 hat rein garnichts mit Punkt 2 und 3 zu tun. Du hast weiter oben die Funktion gepostet in der das Listview die Daten bekommt. Dort ist auch ein consolewrite(). Genau diese Daten will ich sehen, damit ein Fehler beim Dateninput ausgeschlossen werden kann:

Func _ReadFiles($SearchPath, $SearchString)
$FileList = _FileListToArray($SearchPath, "*", 1)
If Not @error Then
For $i = 1 To $FileList[0]
$ReadedFile = FileRead($SearchPath & $FileList[$i])
If StringInStr($ReadedFile, $SearchString) Then
ConsoleWrite($SearchString & "|" & $SearchPath & $FileList[$i] & @CRLF)
GUICtrlCreateListViewItem($SearchString & "|" & $SearchPath & $FileList[$i], $FileListView)
EndIf
Next
EndIf
EndFunc

Punkt 5 ist dann jedenfalls deine letzte Möglichkeit hier eine Lösung zufinden. Ansonsten such den Fehler selbst.

Letzter Versuch dir zu helfen:

1. Prüfe ob du die Variable des Listviews mehrfach verwendest und dir dadurch die control id überschreibst.
2. Sofern das Listview nicht global erstellt wird sondern in einer Funktion achte darauf dass die variable global deklariert ist oder an die Füllfunktion übergeben wird.
3. Wenn du die funktion in der das Listview erstellt wird mehrfach aufrufst hast du multiple listviews die sich überlappen... schlecht!
4. Poste die Zeilen der Consolen Ausgabe der Füllfunktion.
5. Poste das komplette Script oder zumindestens eine lauffähige Version in der das Problem noch auftritt.

Gewöhn dir mal an Testscripte in denen der Fehler reproduzierbar ist zu posten. Ich glaube keiner hier hat Lust jedesmal eine GUI zu basteln nur um dir zu helfen. Davon ab ist es natürlich möglich der Funktion variable Parameter mitzugeben. Ich nehme an dein Fehler entsteht bei der Erstellung des Listviews, vermutlich hast du keine oder eine abweichende Spaltenzahl vorgegeben.

#include <GUIConstantsEx.au3>
#include <GUIListBox.au3>
#include <WindowsConstants.au3>
#include <file.au3>
#Region ### START Koda GUI section ### Form=
$Form1 = GUICreate("Form1", 615, 438, 192, 124)
$List1 = GUICtrlCreateListView("Spalte1|Spalte2", 120, 88, 425, 253)

;GUICtrlCreateListViewItem("wert1|wert2",$List1)

$aDirContent=_FileListToArray(@ScriptDir)

For $i=1 to $aDirContent[0]
GUICtrlCreateListViewItem(@ScriptDir & "|" & $aDirContent[$i],$List1)
next

GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###

While 1
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit

EndSwitch
WEnd

Vielleicht auch ein 32/64 bit Problem? Keine Ahnung ob diese memory UDF da Probleme macht. Könnte mir aber gut vorstellen, dass es einen unterschied macht ob man die Speicherbereiche einer 32bit oder 64bit Anwendung ausliest.

Unter der Annahme, dass du alle RDP Dateien am selben Ort speicherst:

Naja ich würde nicht die Controlid zur Zuordnung verwenden, denn wenn du die GUI später mal erweiterst stimmen deine IDs nicht mehr und das Auslesen der ini würde ggf. falsche Felder befüllen.
Davon ab wäre ein manuelles Editieren der ini Datei dadurch auch nicht gut möglich.

Alternativ zu einer ini Datei ist vielleicht auch der Einsatz einer CSV Datei sinnvoll oder bequemer. Vielleicht kannst du ja etwas mehr vom Script posten, insbesondere die GUI. So kann man schlecht eine Aussage treffen wie man das am besten umsetzt.

Dann hilft wohl nur gescheites debugging. Ich gehe davon aus, dass die Funktionen _MemoryOpen() und _MemoryRead() durchaus über Errorcodes und Fehlerrückgabewerte verfügen, die man auswerten könnte, dazu eben mal einen Blick in die UDF werfen. Der erste Schritt wäre also dein Script so umzubauen, dass die Teilergebnisse nicht sofort weiterverarbeitet sondern erstmal zu Debugzwecken in Logdateien inklusive möglicher Fehlercodes ausgegeben werden. Auch verwendest du anscheinend die Ergebnisse von iniread im Funktionsaufruf. Um Fehler auszuschliessen sollte der INI Inhalt ebenfalls zuerst geprüft werden.

Und du bist dir sicher, dass das Autoit Script überhaupt gestartet wird? Bastel doch mal ein Testscript, das nur eine Datei @scriptdir anlegt und sich dann wieder beendet. Das Ergebnis kannste dann ja zumindestens per FTP prüfen.
Ohne vollen Serverzugang stelle ich mir jedenfalls den Betrieb eines eigenen TCP Servers problematisch vor, Zugang zur Windows Firewall haste so ja z.B. auch selbst keinen und musst dich auf die Aussagen des Hosters verlassen. Da der Hoster anscheinend ja auch andere Kunden mit diesem Server versorgt bezweifle ich auch, dass er dir irgendwelche weitergehenden Rechte auf der Maschine einräumen wird oder überhaupt mit der Ausführung von Fremdcode auf seinem Server einverstanden ist. Letztlich wäre das ja ein enormes Sicherheitsrisiko für den Hoster und die anderen Kunden auf dem Server.

Keine Ahnung wie das bei Game Servern so läuft... hast du vollen Remotedesktopzugang zum Server? Wenn ja verfügst du überhaupt über Administratorrechte? Läuft der Gameserver ansich über deinen eigenen Benutzeraccount des physikalischen Servers oder wird der auf einem von dir nicht direkt zugreifbaren Account ausgeführt? Ob die Memory UDF die du da verwendest in der Lage ist auch Speicherbereiche von Programmen auszulesen, die auf anderen Benutzeraccounts laufen weiß ich nicht, ggf. liegt ja auch da das Problem.

Keine Ahnung welches OS auf deinem Server läuft, aber Serverbetriebssysteme haben normalerweise die "Datenausführungsverhinderung" aktiviert. Könnte mir durchaus vorstellen, dass das bei Zugriffen auf Speicherbereiche anderer Anwendungen zu Problemen führen kann. Hatte jedenfalls selbst schon Anwendungen, die auf Windows 7 einwandfrei liefen, auf Windows 2008 R2 allerdings erst nach Ausnahme in der Datenausführungsverhinderung.

Oder so?

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

$parentForm = GUICreate("Mein Programm", 1000, 100, 200, 200)
$Form1 = GUICreate("Form1", 280, 300, 200, 350,$WS_SYSMENU,-1,$parentForm)
$Form2 = GUICreate("Form2", 380, 300, 515, 350,$WS_SYSMENU,-1,$parentForm)
$Form3 = GUICreate("Form3", 280, 300, 930, 350,$WS_SYSMENU,-1,$parentForm)
$Form4 = GUICreate("Form4", 1000, 200, 200, 700,$WS_SYSMENU,-1,$parentForm)

GUISetState(@SW_SHOW,$parentForm)
GUISetState(@SW_SHOW,$Form1)
GUISetState(@SW_SHOW,$Form2)
GUISetState(@SW_SHOW,$Form3)
GUISetState(@SW_SHOW,$Form4)

While 1
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit

EndSwitch
WEnd

Warum arbeitest du mit 11 offenen Fenstern? Wäre es nicht sinnvoller 1 Fenster mit 11 Tabs zu verwenden?

Interessant wäre außerdem wie du die Fenster erzeugst. Startest du jedesmal eine neue Verbindung mit Mozrepl? Wenn ja dürfte klar sein, warum maximal das letzte Fenster geschlossen werden kann. Hab aber ehrlich gesagt noch nie mit multiplen Fenstern und der ff.au3 gearbeitet, müsste ich mir auch erst ansehn wo es da zu Problemen kommen kann.

Wenn $i wirklich verändert werden soll, was afaik nur in dem einen Fall der so nicht funktioniert eintreten würde kann man das noch mithilfe von assign lösen:

#include<array.au3>

Dim $aArray[5] = [1,7,12,55,89]

;_arraydisplay($aArray)

$i = 1
ConsoleWrite($aArray[2] & @CRLF); sollte 12 ergeben
ConsoleWrite($aArray[1 + 1] & @CRLF); sollte 12 ergeben
ConsoleWrite($aArray[Assign("i", $i + 2)*$i] & @CRLF); $i sollte nun 3 sein, die abfrage also 55 ergeben
ConsoleWrite($aArray[$i + 1] & @CRLF); sollte 89 ergeben, da i mittlerweile 3 ist und nochmals mit 1 addiert wird, $i ist unverändert 3

Aber wirklich toll ist so ein code nicht, würde davon abraten sowas zu verwenden...

Wie von TheLuBu bereits richtig erkannt gehst du fahrlässig mit Funktionen um die normalerweise zwar Arrays zurückgeben, im Fehlerfall allerdings nicht. Prüft man die Ergebnisse der Funktion nicht und verwendet die Ergebnis Variable blind weiter, als ob sie ein Array wäre kann es zum beschriebenen Programmabsturz kommen. Deswegen prüft man grundsätzlich auf die in der Funktion definierten Fehlerrückgabewerte, insbesondere wenn das Ergebnis weiterverwendet werden soll. Reagieren kann man hier dann auf diversen Arten. Da du vermutlich wissen willst warum und wann eine Teilfunktion einen Fehler zurückgibt solltest du die Makros @error und je nach Funktion auch @extended nutzen, welche Debug Möglichkeiten bestehen kannst du den betreffenden Hilfeeinträgen entnehmen. Wichtig sind jedenfalls entpsrechende if Bedingungen oder Schleifenabbrüche damit es im Fehlerfall nicht zum Absturz kommt. Außerdem Wichtig wäre es die Fehler auszugeben und möglichst viele releavante Informationen zu speichern. In deinem Fall solltest du neben den Fehlercodes auch den aktuellen Schleifendurchgang und evtl vorhergegangene Variabelninhalte in eine Logdatei schreiben, damit du nachvollziehen kannst warum es zum Fehler kam.

Aus langeweile habe ich gestern mal wieder ein wenig mit Client Server Geschichten rumgespielt. Die Kommunikation zwischen Client und Server scheint soweit auch zu funktionieren, jedoch sollen nun auch größere Dateien (1GB) per TCP zwischen beiden übertragen werden.
Dabei gibt es zwei Probleme in meinem Script.

1. Die Dateigröße der übertragenen Datei weicht vom Original ab. Ich vermute das passiert, beim letzten eingelesenen Part der Datei, aber ich habe keine wirkliche Idee wie ich das beheben kann.

2. Der Transfer ist verdammt langsam, was für einen Transfer übers Internet zwar noch akzeptabel wäre, aber solange ich client und server auf dem selben Computer betreibe sollten doch eigentlich deutlich höhere Transferraten möglich sein. Ich erreiche mit den aktuellen Scripten lediglich 4-5 MB/s, verzehnfache ich die Größe der Dateiparts im Server und den zugehörigen Lesepuffer im Client, dann erreiche ich immerhin 11 mb/s, was im Vergleich zum normalen Kopieren weniger als ein zehntel der maximalen Geschwindigkeit ist. Ist die Größe der Parts jedoch zu hoch reagiert der Server nicht mehr richtig, weil er relativ lange mit dem Senden eines einzelnen Parts beschäftigt ist, das muss auf jedenfall vermieden werden. Auch sollen später langsame Clients (Internet) nicht ausgebremst werden, weil sie Möglicherweise mehrere Sekunden für einen Dateipart benötigen, bevor sie wieder andere Dinge wie GUI cmds abarbeiten können. Die Partgröße zu erhöhen fällt also schonmal weg um die Performance zu verbessern.

Vielleicht hat ja jemand von euch Ideen wie man die Performance erhöhen könnte und den Fehler bei der Übertragung behebt.

Anmerkungen zu den Scripten:

Der Server sollte per Scite ausgeführt werden um alle Debug Meldungen aus der Console lesen zu können.
Der Client sollte kompiliert werden.

Um einen Dateitransfer zu starten muss zuerst der Server, dann der Client gestartet werden, im client dann den connect Button nutzen und im Anschluss den getfile Button.
Vor dem ersten Testlauf muss im Server noch die globale Variable $testfile angepasst werden, hier sollte eine Datei mit mindestens 500 MB verwendet werden.

FILE TRANSFER Complete: 1485 MB	345s	4.3MB/s

Das macht man nicht mit controlsend und einer Tastenkombination. Um Menüpunkte eines Fensters anzusteuern verwendet man

WinMenuSelectItem

Davon ab ist es normal nicht notwendig den Datei Öffnen Dialog zu automatisieren. Die meisten Programme kann man auch einfach per run und Parameter starten um eine Datei zu öffnen.

Beispiel:

$filepath = "C:\test.txt"
run("notepad.exe " & '"' & $filepath & '"')

Sofern du zwischen maximiert und nicht maximiert switchen wolltest fällt mir da auf anhieb lediglich winmove ein, das sollte dir erlauben das Fenster auf eine beliebige Größe und Position zu bekommen.

winmove()

Keine Ahnung was du mit Restore down mode meinst, vielleicht würde ein Screenshot helfen, damit auch jeder weiß wovon du sprichst.

Es gibt jedenfalls @SW_RESTORE

Das geht so auch nicht. Schon alleine deswegen, weil die lokalen Pfade "C:\blah\" lauten. Auf dem FTP lauten die Pfade nachher aber "\blah\".
Trenn doch einfach Datenermittlung von produktiven Funktionen wie deinem FTP Upload. Hast du erstmal alle Daten in Arrays ist es viel einfachher diese in modifizierter Form für die FTP Kommandos zu nutzen.

Angenommen du hast meine vollständige Ordnerliste aus Beispiel 1

for $i=1 to ubound($aResult)-1
_FTP_DirCreate($FTPConnect, stringtrimleft($aResult[$i]),2))
;oder
_FTP_DirCreate($FTPConnect, stringreplace($aResult[$i]),"c:\testpfad\teil_des_pfades_der_weg_soll_und_nix_auf_dem_ftp_verloren_hat",""))
next

Also nochmal etwas Erklärung zu meinen Beiden Beispielen.

Im ersten Beispiel ermittle ich alle Ordner und deren Unterordner und deren Unterordner usw.
Das mache ich in dem ich zuerst die Ordner des Hauptordners ermittle. Nun gehe ich alle Ordner des Hauptordners durch und prüfe durch erneuten Aufruf der Funktion ob sich in diesem Ordner ebenfalls Ordner befinden, wenn ja werden diese Ordner erneut durch Aufrufe der Funktion geprüft. Sobald ein Ordner keine Ordner mehr enthält wird eine Ebene darüber der nächste Ordner auf Unterordner geprüft. Das geht solange, bis das Script wieder am Anfang angekommen ist, also im letzten Ordner des Hauptordners. Am Ende sind wir durch alle Ordner gegangen und haben uns diese in einem Array gespiechert.

Beispeilstruktur:

Hauptordner
 -Ordner1
   --Unterordner1a
   --Unterordner1b
 -Ordner2
   --Unterodner2a
 -Ordner3

Scriptablauf:

1. Liste Hauptordner erstellen
2. Liste Ordner1 erstellen -> Funktion wird neu mit gewünschtem Ordner1 aufgerufen
3. Liste Unterordner1a erstellen -> Funktion wird neu mit gewünschtem Unterordner1a aufgerufen
4. Unterordner1a enthält keine Ordner mehr, alo $aTemp=0 --> return
5. Liste Unterodner1b erstellen -> Funktion wird neu mit gewünschtem Unterordner1b aufgerufen
6. Unterordner1b enthält keine Ordner mehr, alo $aTemp=0 --> return
7. Liste Ordner2 erstellen -> Funktion wird neu mit gewünschtem Ordner2 aufgerufen
....

Das zweite Script macht nun folgendes:

Wir haben ein Array mit allen Ordnern aus der ersten Funktion von oben, nun gehen wir in der äusseren For Schleife alle Ordner durch. Für jeden Ordner erstellen wir eine Dateiliste und jede dieser Dateinamen (innere For Schleife) inklusive zugehörigem Ordnerpfad schreiben wir in das Ergebnis Array. Wenn einer der Ordner aus der äusseren Schleife keine Dateien enthält, dann überspringen wir diesen Ordner mit continueloop.

Scriptablauf:

1. Erster Ordner der Ordnerschleife ist dran
2. Dateiliste des ersten Ordners erstellen
3. innere Schleife, jede gefundene Datei aus dem ersten Ordner in ein Array speichern
4. Zweiter Ordner ist dran
...

Hoffe nun verstehst du in etwa was da passiert.