Beiträge von misterspeed

Also einen Fehler sehe ich definitiv:

Global $sOutFileName
For $i = $iStart To $iEnde
$oDocref.ArtLayers($iTextebene).TextItem.Contents = $sVortext & $i & $sNachtext
$sOutFileName = $sSpeicherpfad & "\" & $i & ".jpg"
$oDocref.SaveAs($sOutFileName, $oJpgSaveOptions, True)

$sSpeicherpfad ist nicht der Pfad, sondern beinhaltet lediglich die ControlID deines Labels, also eine Zahl. Du kannst hier entweder $rSpeicherpfad verwenden, oder aber du verwendest

guictrlread($sSpeicherpfad )

Falls das nicht die Ursache für den COM Fehler sein sollte würde ich anhand der Zeilennummer vermuten, dass diese Zeile falsche Werte beinhaltet:

$oDocref.ArtLayers($iTextebene).TextItem.Contents = $sVortext & $i & $sNachtext

Daher würde ich vor dieser Zeile etwas Debugging betreiben und mir die Variableninhalte ausgeben lassen:

consolewrite($iTextebene & " / " & $sVortext & " / " & $i & " / " & $sNachtext & @crlf)

Ahja jetzt beim schreiben fällt mir auf, dass hier sehr sicher ein Fehler steckt, denn du begehst den selben Fehler wie auch schon bei der Variable $sSpeicherpfad. Das Problem sollte also nach Korrektur dieser Variablen behoben sein.

EDIT:

Kleiner Nachtrag noch... Globale Variablen sollte man grundsätzlich am Scriptanfang und niemals innerhalb von Funktionen deklarieren, andernfalls kann das Script abstürzen wenn eine Funktion die Variable nutzen möchte bevor die deklarierende Funktion aufgerufen wurde. Nach Möglichkeit sollte man globale Variablen generell sparsam einsetzen. Soweit ich das sehe benötigst du die Variablen außerhalb deiner Start Funktion aber garnicht, sondern lediglich innerhalb der Funktion. Daher solltest du diese auch lokal deklarieren.

Zitat von water

Wenn es also für WinHTTP kein 64 bit Interface gibt (vermutlich eine DLL), dann funktioniert nur 32 bit.

Klar gibt es eine 64-bittige "winhttp.dll", er hatte ja auch bereits geschrieben, dass das Script unter Windows 7 in beiden Modi funktioniert. Man darf also mal vermuten, dass sich unter Windows 8 ebenfalls eine 32 und 64bit Variante der DLL in den Ordnern SysWOW64 bzw System32 befindet. Mein erster Schritt wäre mal der Vergleich der entsprechenden DLLs mit dennen aus der Windows 7 Umgebung. Sofern sich die DLLs seit Windows 7 verändert haben, wovon ich mal ausgehe, köntest du testweise auch mal die Nutzung der Windows 7 DLLs erzwingen. Sprich die "alten" DLLs mitliefern und die winhttp.au3 entsprechend modifizieren, damit deine mitgelieferten DLLs genutzt werden.

Nope X ist nicht irrelevant sondern Y, er sprach von einer horizontalen Scrollbar. Hier mal die Idee von Cheestiger realisiert, allerdings ohne Scrollbars, da ich keine Lust hatte mir die UDF die hier irgendwo noch schlummert rauszusuchen.

Meinen Code auch gesehen/getestet?

Kann so auch nicht funktionieren.

1. Code der nach deiner GUI Endlosschleife folgt wird nicht ausgeführt, das Script kommt niemals an diese Stelle im Script.
2. Deine Variablen sind somit nicht deklariert.
3. Selbst wenn du diese am Scriptanfang deklarieren würdest würden sie nur den Anfangswert der in den Inputfeldern steht beinhalten und nicht die ggf. später von Hand geänderten Werte.

Da du diese Variablen ohnehin nur lokal benötigst solltest du diese auch nur lokal innerhalb der Start() Funktion deklarieren.

Ein lauffähiges Script (auf die Autoit Syntax bezogen) würde z.B. so ausschaun:

Zitat von water

$extType und $qualaity kommt nirgends vor, daher weiss ich nicht, was da reinkommt.

"quality" wird am anfang deklariert und wurde von dir mit $iQuality benannt (Zeile 20 muss also berichtigt werden). "extType" wird allerdings wirklich nirgendwo im vbs script erwähnt. Dafür hast du in Zeile 25 einen fehler eingebaut "i" muss natürlich "$i" heißen.

Ich würde einfach inetread verwenden, dann gibts erst gakreine Datei die man verstecken müsste. Allerdings kannst du dann eben nicht die Standard ini Funktionen verwenden, sondern musst den empfangenen String mit den Stringfunktionen und/oder Arrayfunktionen parsen/aufbereiten.

; DeTokenise by myAut2Exe >The Open Source AutoIT/AutoHotKey script decompiler< 2.9 build(138)

Öhm ja.

Davon mal ab würde ich das Speicherproblem bei den unzähligen winhttp Aufrufen vermuten. Ich gehe davon aus, dass etliche Handles nicht geschlossen werden und sich der Speicherverbrauch dadurch mit der Zeit summiert, hab das aufgrund des Umfanges jetzt aber auch nur überflogen und könnte da falsch liegen. Testen kann mans ohne die unzähligen Includes die dein Decompiler unterschlagen hat und entsprechende Testzugangsdaten ja ohnehin nicht. Es fehlen im übrigen auch Funktionen z.B. XSKINBUTTON() welche in irgendeinerweise mit der Funktion _go() zusammenhängen dürfte. Wie dem auch sei, da du offensichtlich nicht der Autor des Scriptes bist und den originalen Quellcode nicht besitzt macht weiterer Support hier denke ich kaum Sinn.

Selbst extrem aufwendige Scripte verbrauchen normalerweise kaum RAM (weniger als 30MB). Ich würde vermuten, dass du enorme Datenmengen Zwischenspeicherst, z.B. durch Dateitransfers. Filerad liest z.B. die komplette Datei in den Speicher. Soll dein Chatbot also auch zur Übertragung größerer Dateien dienen empfiehlt es sich diese Byteweise in ein größentechnisch begrenztes Array einzulesen (Lese Cache), anstatt komplett. Beispiele dazu findest du wenn ich mich recht erinnere unter anderem in einer der crypt Funktionen.

Andere Ursachen könnten natürlich auch Schleifen sein, die in jedem Durchgang den Inhalt einer Variable oder eines Arrays permanent kopieren. Aber wie schon gesagt wurde ist es ohne Code unmöglich dir hier die Ursache zu nennen.

Funktioniert doch. Musste nur die Funktionsnamen anpassen. Am Anfang hab ich dann noch den passiv mode aktiviert und die Möglichkeit eines abweichenden Ports berücksichtigt. Was allerdings nicht funktioniert ist der Download eines ganzen Ordners. Man kann damit im Moment nur einzelne Dateien direkt im Stammverzeichnis herunterladen, mehr hatte der ursprüngliche Autor des "FTP Clients" wohl nicht beabsichtigt. Meiner Meinung nach unbrauchbar. Wozu gibt es Filezilla und co. ?

Ob die restlichen Funktionen so noch funktionieren habe ich nicht getestet. Das requireadmin am Scriptanfang dürfte im übrigen überflüssig sein. Ich sehe nichts im Script das Adminrechte benötigen würde.

Zitat von Fliwatt

Macht es doch nicht immer so kompliziert mit MySQL und CSV, mit einer ini geht es doch auch sehr gut.

Nun, dass eine SQL Datenbank in diesem Fall vermutlich übertrieben ist und vorallem einiges an Grundwissen zur SQL Syntax erfordert stimmt meiner Meinung nach. CSV Dateien sind hingegen je nach Datenstruktur wesentlich sinnvoller als ini Dateien, alleine schon deshalb weil Redundanz und somit Speicherplatz eingespart wird. Das kommt auch wieder der Geschwindigkeit zu gute. CSV Dateien kann man wunderbar in einem Rutsch in ein Array einlesen, was wiederum zahlreiche Festplattenzugriffe einspart. Sofern man den Umgang mit 2d Arrays und evtl anderen Array bezogenen Funktionen verstanden hat ist es auch nicht wirklich komplizierter als mit den ini Funktionen zu arbeiten.

Anmerkung zu deinem Beispielscript:

Es ist nicht notwendig die Anzahl der ini Sektionen in einer extra Sektion zu speichern. Stattdessen kann man auch IniReadSectionNames verwenden, welches in result[0] die Anzahl der gefundenen Sektionen zurückgibt.

Und warum willst du quasi unendlich viele ini Dateien dafür anlegen? Ich würde mal vermuten, dass es eine einzige ini genauso tun würde, oder alternativ eine CSV Datei viel besser geeignet wäre. Im moment ist mir aber unklar was du nun eigentlich speichern möchtest. Wofür steht K und D in deinem Beispiel? Sollen das Spielernamen sein? Spielrunden/Level?

Da du in deinem Beispiel jeweils nur einen Eintrag pro ini Sektion verwendest würde eine ini die so aufgebaut ist vielleicht mehr Sinn machen:

[Level K]
Tötungen=123
Tode=3
Assits=45
Ergebnis=44
Champion=44
[Level D]
Tötungen=454
Tode=46
...

Ich verstehs nachwievor nicht, was damit nun gemeint war, denn egal wie man die Variablen ausserhalb von Funktionen deklariert bleibt das Verhalten identisch. Sie werden immer als globale Variablen behandelt und sind durch Funktionen global veränderbar, ausser man deklariert sie erneut lokal innerhalb der Funktion myFuncDeclareLocal(), was sich wiederum nicht auf die globale Eigenschaft auswirkt, siehe erneuter Aufruf von myFunc(). Somit sehe ich nachwievor keinen Grund sie nicht ausdrücklich als Global zu deklarieren, da dies ohnehin im Hintergrund geschieht.

AutoIt v3 Script (neu).au3 - 4 error(s), 8 warning(s)
!>21:25:42 AU3Check ended. Press F4 to jump to next error.rc:2

Nächstesmal poste bitte ein Script, das auch lauffähig ist. Ich gehe daher einfachmal davon aus, dass Minx richtig liegt (Punkt 3).

minx

Was die Global/Local Sache angeht sehe ich ehrlich gesagt keinen Grund das als Local zu deklarieren. Schließlich handelt es sich um globale Variablen, wenn diese ausserhalb von Funktionen initialisiert oder deklariert werden, also warum nicht auch als solche kennzeichnen? Klar ist eine Deklaration nicht notwendig, aber wenn man sauber programmiert sollte man das schon tun. Da verstehe ich deine Kritik nicht ganz sorry. Wenn schon würde ich sie garnicht deklarieren, keine Ahnung wieso du sie als lokal deklarieren würdest und was dich an der globalen Deklaration stört.

Fileopen gibt dir nur ein Handle zur Datei und nicht den Dateiinhalt. Verwende fileread und übergib den gelesenen String dann an deine regexp Funktion.

Bevor man etwas sucht sollte man erstmal wissen was man sucht und es danach in Suchmaschinen freundliche Worte packen. Bei letzterem kann man dir hier ggf. helfen, aber das "was" wurde mir aus deinem Beitrag nicht wirklich klar. Autoit beinhaltet doch bereits eine FTP UDF, also was genau suchst du nun?

Ja das schon, aber der Fenstertext lautet sicher nicht "Adresse..." und wie die Klasse unter XP oder Vista lautet kann ich gerade nicht nachsehen.

Ja das kann durchaus sein, wie vorhin erwähnt gab es noch einen Fehler was den Fenstertitel anbelangt. Diese Variante sollte nun besser funktionieren, Vorraussetzung ist aber, dass du Windows 7 mit deutscher Sprache verwendest und dass die Explorer Fenster jeweils maximal 30 Sekunden brauchen um zu erscheinen. Direkt nach dem Windowsstart kann das je nach Rechner durchaus ein wenig dauern. sofern das bei dir ein Problem sein sollte kannst du den letzten Parameter $waitTime erhöhen. Bei anderen Windowsversionen müsste man vermutlich "CLASS:?????" entsprechend anpassen und auch der Fenstertext "Adresse...." muss ggf. geändert werden.

Global $taskbarH = 80

openFolder("C:",0,0,@DesktopWidth/2,@DesktopHeight-$taskbarH)
openFolder("D:",@DesktopWidth/2,0,@DesktopWidth/2,@DesktopHeight-$taskbarH)

Func openFolder($folder,$x,$y,$b,$h,$waitTime = 30)

If StringRight($folder,1)='\' Then $folder = StringTrimRight($folder,1)

ShellExecute($folder)

if WinWait("[CLASS:CabinetWClass]","Adresse: " & $folder,$waitTime) = 0 Then
MsgBox(0,"Fehler","Warten auf Fenster " & $folder & " gescheitert.")
Else
winMove("[CLASS:CabinetWClass]","Adresse: " & $folder,$x,$y,$b,$h)
;WinSetState("[CLASS:CabinetWClass]","Adresse: " & $folder,@SW_MINIMIZE)
EndIf
EndFunc

Joar Bugfix, war mir klar. Hatte das nur aus meinem Startup Script rauskopiert, da ist Flexibilität eher unwichtig. Was den Fenstertitel angeht passt auch was nicht ganz (hab das bei mir eigentlich mit fixen Fenstertiteln).

Sofern es so gadacht war:

Global $taskbarH = 80

openFolder("C:\",0,0,@DesktopWidth/2,@DesktopHeight-$taskbarH)
openFolder("D:\",@DesktopWidth/2,0,@DesktopWidth/2,@DesktopHeight-$taskbarH)

Func openFolder($folder,$x,$y,$b,$h,$waitTime = 30)
$dirName = StringSplit($folder,"\")
If $dirName[0] < 2 Then
$dirName = $folder
Else
$dirName = $dirName[$dirName[0]]
EndIf

ShellExecute($folder)

if WinWait($dirName,"",$waitTime) = 0 Then
MsgBox(0,"Fehler","Warten auf Fenster " & $dirName & " gescheitert.")
Else
winMove($dirName,"",$x,$y,$b,$h)
;WinSetState($dirName,"",@SW_MINIMIZE)
EndIf
EndFunc