Beiträge von misterspeed

Zitat von SionS

Ja sry wenn es funzen würde er schreibt dan nix in die datei da steht dann das drinne was schon voher drinne stand

Mein script schreibt an den Dateianfgang das was du haben wolltest, nämlich einen Sektionsname [Account]. Ich hatte aber den Code nochmal editiert, weil ich zum testen die ini Deteien im scriptdir hatte. Probiers bitte nochmal.

So zum Beispiel?

#include <file.au3>
#include <array.au3>

Global $aINI
Global $sOrdner = FileSelectFolder("Ordner wählen", "")
Global $aFiles = _FileListToArray($sOrdner, "*.ini", 1)

For $i = 1 To $aFiles[0]
_FileReadToArray($sOrdner & "\" & $aFiles[$i],$aINI)
_ArrayInsert($aINI,1,"[Account]")
_FileWriteFromArray($sOrdner & "\" & $aFiles[$i],$aINI,1)
Next

Ein wirklicher Schutz ist es dennoch nicht.

Schwachstellen:

- Autoit Scripte können leicht dekompiliert werden, auch der Obfuskator bringt kaum zusätzlichen Schutz. Dadurch reicht ggf. schon das ändern eines einzigen Zeichens im dekompilierten Quellcode um deine Prüfung unwirksam zu machen.
- Du integrierst FTP Zugangs Daten ins Script? Dann achte darauf, dass diese wenigstens nur Leserechte besitzen.
- Internetverbindung und ein Webspace der wirklich immer erreichbar ist wird benötigt. Free Webspace ist da nicht unbedingt das Wahre.
- Du schreibst, dass nach einmaliger Verifizierung dauerhaft freigeschaltet wird, das bedeutet du speicherst das Prüfergebnis irgendwo (ini Datei / Registry ?) Ebenfalls angreifbar, je nachdem wie du das abgesichert hast.
- Du veröffentlichst eine komplette Keyliste auf deinem Server, besser wäre ein PHP Script, dass je nach übergebener HWID ein true oder false oder besser einen verschlüsselten code zurückgibt, das würde dann auch bedeuten, dass du keine FTP Daten mehr ins Script einbauen müsstest und eine lokale Dateiprüfung entfällt. Die Datei könnte ja auch manipuliert werden.

Das wirkliche Hauptproblem wird aber immer die Dekompilierbarkeit bleiben. Dagegen kannst du dich kaum schützen. Den ein oder anderen Weg gibt es um das deutlich zu erschweren, einfach mal ein wenig suchen. Die Frage ist aber auch immer ob sich der ganze Aufwand lohnt. Am besten verhinderst du von Anfang an, dass das Script in falsche Hände gelangt, dann brauchst du dir auch keine Gedanken machen.

Nächstes mal bitte folgende Dinge beachten:

- autoit Quellcode Tag verwenden -->
- sonstigen code der nicht autoit ist (Consolen Fehlermeldungen / xml Auszug) mit dem code Tag posten -->
- längere code Passagen zusätzlich in Spoiler packen -->
- Fremd includes wie die "_XMLDomWrapper.au3" entweder verlinken oder als Dateianhang posten

Nun zu deinem Fehler:

Zitat von Funktionsbeschreibung _XMLGetNodeCount

Parameter(s): $path xml tree path from root node (root/child/child..)

Demnach könnte diese Zeile falsch sein, hab es aber nicht getestet:

$iEntryCnt = _XMLGetNodeCount("/feed/entry", "", $NODE_ELEMENT) ; falsch?
$iEntryCnt = _XMLGetNodeCount("feed/entry", "", $NODE_ELEMENT) ; richtig?

Ahja nun hab ich den Fehler entdeckt. Es ist fast wie ich vermutet habe. Du lässt dein Script sich selbst aufrufen.

@AutoItExe ; Der komplette Pfad und Dateiname der AutoIt-Exe-Datei. Bei kompilierten Skripten der Pfad des laufenden Skriptes.

Bedeutet: shellexecute(deinescript.exe, "mit parameter client.au3")

Das was du aber eigentlich erreichen wolltest war ja den autoit interpreter mit parameter aufzurufen, nicht dein eigenes laufendes script.
In kompilierter Form darfst du das Makro so also nicht verwenden.

Ein Fehler dürfte es zum Beispiel immer geben wenn das Listview leer ist, was durchaus durch fehlerhafte regreads entstehen kann, kA wie du das Listview befüllst.
Was die Größe angeht... sie ist nicht angemessen, da sie entweder zu groß oder im schlimmsten Fall zu klein ist. Besser wäre es dieses _asBody Array genau wie $array anhand der benötigten Zeilen des Listviews zu dimensionieren.

Aso fast vergessen. Badly formated erscheint soweit ich mich erinnere, wenn man Arrays mit ungültigen Angaben deklarieren möchte, also zum Beispiel:

Global $aTest1[4][0] ; 0 ist ungültig, mindestgröße ist 1
$aTest1[1][0]="test"
MsgBox(0,"",$aTest1[1][0])

Es könnte also sein, dass diese beide Zeilen Fehler anstelle der Anzahl zurückliefern:

$iAnzCol = _GUICtrlListView_GetColumnCount($hLvw_Info)
$iAnzahl = _GUICtrlListView_GetItemCount($hLvw_Info)

Auf welche Zeile und auf welches Array bezieht sich die badly formated Meldung denn?

Was mir auffällt sind folgende Dinge:

Func _Listview_2_Array($s_Mode)
Local $array
;...
Local $msg, $array[$iAnzahl+1][$iAnzCol]

Wieso deklarierst du $array zweimal?

If $s_Mode = "Mail" Then
Dim $as_Body[99] ; 2D Array für Email Versand zu 1D Array konververtieren <--- hier ist vermutlich die Ursache
For $i = 1 to UBound($array) -1
$as_Body[$i] = $array[$i][0] & " - " & $array[$i][1]

Kann schonmal böse schief gehen, wie kannst du sicher sein, dass $array nich mehr als 99 Elemente hat? $as_body muss mindestens genauso groß sein wie $array

Func _Email_Status_Info($s_ToAddress) ; Emailversand der Log/Statusdatei
;...
Local $as_Body[99]; =
_Listview_2_Array("Mail")

Auch hier wieder nur 99 groß, davon ab liefert dir die Funktion _listview_2_array doch das Array bereits fertig zurück. Ein deklarieren dürfte da garnicht notwendig sein, wenn dann eher so:

Local $as_Body = _Listview_2_Array("Mail")

Natürlich solltest du bevor du damit weiterarbeitest auch prüfen ob du wie erwartet ein Array zurückbekommen hast.

Fehler liegt vermutlich in der Client.au3, ich sehe in dem was du bislang gepostet hast jedenfalls nichts was in einer Schleife zum shellexecute führt. Erklären kann ich mir das nur wenn die client.au3 identisch zu deinem ersten codeblock ist, denn dann ruft sich das script immer wieder selbst auf.

Anstelle der Tastenkombination solltest du im übrigen besser gleich von Anfang an die Funktionen zur Control Steuerung nutzen:

controlclick()
controlcommand()
; und noch einige andere die du in der Hilfe unter Window Management / Controls findest

Send ist nicht sehr zuverlässig. Beim Fenstertitel ist es oft besser sich auf einen Teil Titel zu beschränken, insbesondere dann wenn du vielleicht später neuere Versionen installieren willst müsste das ja sonst wieder angepasst werden. Diesbezüglich solltest ggf. auch noch die Option

AutoItSetOption ( "WinTitleMatchMode" [, param] )

ansehen.

Naja du brauchst doch eigentlich garkeine rekursive Dateisuche wenn ich dich recht verstehe. Das was ich bisher gesehen hatte sah danach aus, dass du überhaupt keine Dateien im speziellen kopieren sondern grundsätzlich ganze Ordner kopieren willst. Wenn das so ist verwende doch einfach Dircopy und lass das filelisttoarray gedöns ganz weg. Wenn es doch darauf ankommt die Ordner zu filtern wirst du wohl nicht um filelisttoarray (bzw eine rekursive Variante davon) herumkommen.

Ich benutze selbst eine modifizierte Fassung von Bugfixs IRC client.
Schau dir mal oben in der While Schleife das hier an:

Case 'PRIVMSG' ; Nachricht empfangen

Du musst dort nur etwas Hand anlegen und die Variable $text, welche alles enthält was im Channel geschrieben wird, mit stringinstr Auswerten um Signalwörter (auch als Trigger bekannt) erkennen zu können. Danach reagierst du dann einfach je nach Trigger Befehl mit _IRCsendmessage() um deine Antwort in den Channel zu schicken.

In deinem Beispiel ist aber rein garnix zusehen was mit GDI Plus zutun hätte. Es ist ja noch nichteinmal deine GUI oder sonstwas zusehen. Poste einfach dein lauffähiges, komplettes und ungekürztes Script, dann braucht auch niemand mehr raten woran das flackern wohl liegen mag.

1. Solltest du die Zeilen ersetzen und nicht ergänzen. Deine untere For Schleife muss raus, weil $i hier bereits von der äussersten Schleife verwendet wird.
2. Der Fehler entsteht, weil ein endif zum if statement in Zeile 17 fehlt

EDIT: Da hatte TheLuBu zeitweillig schon geantwortet...

Zitat von BugFix

Eventuell reicht es ja auch die explorer.exe neu zu starten - schon probiert?

Mal den Startpost gelesen und das zugehörige Script angesehen? *hust*

Es gibt ja auch spezielle GUI Styles und resize settings. Ohne sein Script ist es aber sinnfrei da näher darauf einzugehen. Die GUI grundsätzlich im Vollbild zu erstellen ist jedenfalls kaum eine Lösung, die Controls müssen ebenfalls dynamisch anhand der Fenstergröße positioniert und ggf in der Größe angepasst werden. Um sowas aus dem Weg zugehen kann man die GUI auch von anfang an auf eine weitverbreitete und kompatible Auflösung fest setzen. eine maximale Fenstergeröße von 800x600 sollte jedenfalls auf allen heute verbreiteten Monitoren noch darstellbar sein. Alles darüber kann problematisch werden, da sollte man dann über dynamisch anpassende GUI's nachdenken.

Versteh das Problem nicht, was ist an iniread denn auszusetzen? Das entspricht doch dem was du willst, du willst Variablen Werte aus einer externen Datei zuweisen oder etwa nicht?

test.ini Datei:

[myvars]
$var1=test
$var2=test2
$var3=test3

$inifile=@scriptdir & "\test.ini"
$var1=iniread($inifile,"myvars","$var1",-1)
$var2=iniread($inifile,"myvars","$var2",-1)
$var3=iniread($inifile,"myvars","$var3",-1)
msgbox(0,"myvars",$var1 & @crlf & $var2 & @crlf & $var3)

Sofern die Variablen Anzahl dynamisch sein soll musst du dich mit Arrays und den anderen ini Funktionen auseinandersetzen.

inireadsectionnames()
inireadsection()

Adlib ist nicht multithreading. Eine Adlib Funktion ist mehr oder weniger ein Funktionsaufruf innerhalb einer laufenden Funktion. Das bedeutet deine aktuelle Funktion wird kurz unterbrochen, die Adlibfunktion eingeschoben und dann gehts wieder mit dem weiter was gerade abgearbeitet wurde. In gewisser weisse läuft aber etwas paralell, nämlich die Zeitmessung um zu bestimmen wann die Adlibfunktion erneut eingeschoben werden soll. Der code selbst wird aber nich paralell ausgeführt. Daran ändern auch multiple adlib Funktionen nichts.

Um wirklich etwas paralell auszuführen benötigst du eine seperate exe Datei. Diese könnte zum Beispiel per controlcommand() oder vergleichbaren Fenster Funktionen deine Haupt GUI verändern. Ob das Sinn macht und besser funktioniert bezweifle ich aber.

Wirklich sinn macht das für mich zwar nicht, aber hier eine gefixte Version die das macht was du willst. Du kannst nicht einfach msgloop und oneventmode mischen, hatte ich dir aber bereits geschrieben, dass dein Script nicht in einer Funktion festhängen darf wenn du den OnEventMode verwendest. Ausserdem habe ich dir beim Dropdown / Checkbox erstellen mal einen kleinen random Faktor eingebaut damit du siehst dass bei jedem Dropdownklick die Controls neu erstellt werden, was wohl ein Problem sein dürfte...

Per Adlibregister kann man das zum Beispiel bewerkstelligen: