Beiträge von Marthog

Zitat von gem

Lohnt es sich sich schon eine DLL mit AutoIt aufzurufen um eine Array mit 10000 Werten zu füllen? (Ich meine von der Geschwindigkeit her).

Das kommt auf die Art, wie das Array gefüllt wird, an. Liest du z.B. von Dateien, dann lohnt sich das nicht, weil die Festplatte der Flaschenhals ist. Hast du aber eine komplizierte Formel mit vielen Schleifen, dann ist es besser, die Dll zu nehmen.

Ich glaube, mit FreeBasic kannst du DLLs erstellen.

Ach so. Darin sehe ich aber noch weniger Sinn. Wozu will man denn Sicherheitsmethoden anderer Prozesse aushebeln?

Dein Skript ist Schwachsinn.
1. Du setzt den Timer nicht neu. Beim Test der zweiten Funktion wird die Zeit für den ersten aufruf mitgezählt.
2. Du berechnest die Zeitdifferenz erst nach der ersten MessageBox. Die Zeit, bis man auf OK klickt wird also mitgezählt. Ich komme bei Testsmit einem korregierten Skript auf eine Zeit von 225 zu 145. Die StringSplit-methode ist also deutlich performanter.

EDIT: Zu spät.

Meinst du so?

for $i=0 to UBound($array1)-1
$array1[$i]&=", "&$array2[$i]

Ich sehe nicht so wirklich den Vorteil darin, Mutexe in AutoIt zu verwenden.

RegExp ist eine elegante Methode, aber nicht immer die Beste. Wenn man etwas mit einer anderen Funktion in der gleichen Anzahl von Schritten lösen kann, sollte man das auch tun, weil bei RegExp nicht auf den ersten Blick verständlich ist, was und warum es da gemacht wird. Desweiteren arbeiten andere Befehle oft schneller, weil da kein RegExp-parser laufen muss.

Bekommst du die als String, also z.B. aus einer Datei ausgelesen?

Func HexGet($hex, $index)
Return StringMid($hex, $index, 1)
EndFunc

Wenn du die Zahl als Integer hast, geht das aber nicht.

Zitat von CyRoX

Es kann/können ja eine oder mehrere Installationen automatisiert werden, ohne den (in dem Fall) nervigen Admin-Dialog. Vielleicht liege ich ja auch falsch.

Afaik kann ein Programm mit Admin-rechten andere Programme mit Admin-Rechten starten, ohne dabei den Dialog zu öffnen.

Zitat von funkey

Das geht auch viel einfacher:

[autoit]

Func _GetComputerName()
Local $iLen = 100
$aRet = DllCall("kernel32.dll", "int", "GetComputerName", "str", "", "int*", $iLen)
Return $aRet[1]
EndFunc

[/autoit] [autoit][/autoit] [autoit][/autoit]

Nein. AutoIt weiß nicht, wie groß der erzeugte Buffer beim ersten Parameter sein soll. Handelt es sich um einen zu langen Namen, wird über den Puffer hinausgeschrieben.

Zitat von volle

Wenn ihr das Projekt beginnt, fangt doch am besten mit einem einfachen Programm an wie zum Beispiel Hello World von AutoIt zu C++ zu konvertieren. Und dann immer schwierigere Codes bzw. längere. Aber erst mal muss ja ein Konverter zu Stande kommen.

Soweit bin ich doch bereits. Ich hab schon im dritten Post geschrieben, dass ich bereits

Func Test()
For $i=0 To 3
MsgBox(0, "", $i*2)
Next
EndFunc

konvertieren kann.

AutoItC

Es ist noch in pre-alpha. Verbesserungsvorschläge und Hinweise auf Fehler nützen noch nichts, da ich andauern weiterarbeite und auf einem anderen PC bereits Änderungen vorgenommen, diese aber noch nicht übertragen habe.

Ja, der AutoIt-Code wird nach C++ konvertiert. Der entstandene Code ist nicht besonders gut lesbar und für C++-Verhältnisse auch nicht schnell, für AutoIt schon. Solche Konvertierer gibt es auch für andere Sprachen, z.B. Python.

Zitat von UEZ

Zurück zu moritz1243: was ist der Sinn mit AutoIt C++ Code zu erstellen? (nicht negativ gemeint!)

C++-Code wird richtig kompiliert. Der Interpreter fällt weg und der Code kann schneller ausgeführt werden.

Könnte man damit auch. Man muss nur noch einige zusätzliche Sprachelemente einführen, um CallingConvention, Typ des Rückgabewertes und Typ der Parameter anzugeben.
Man könnte auch Programme für Linux schreiben, allerdings würden dann nur die mathematischen, string- und einige Datei-funktionen funktionieren.

Um sowas kümmere ich mich aber erst, wenn alles stabil läuft und (fast) alle Möglichkeiten des Original-AutoIts implementiert sind.

Funktionen und alles werden einfach mitübersetzt.
Nur die nativen Funktionen müssen noch extra geschrieben werden.

Ich hab mir schon überlegt, später noch eine Möglichkeit einzubauen, um neue Funktionen hinzuzufügen, die auf die gleiche Methode aufgerufen werden, wie die nativen, sodass man dabei z.B. Funktionen aus Dlls zu laden ohne den enormen Overhead durch DllCall.

Ich.
Hab mich schon vor einiger Zeit mal rangesetzt und bislang funktioniert es auch einigermaßen. Also if, while, do-while, for, Funktionen und so funktioniert schon ganz gut.

Das ganze System funktioniert so:
Es gibt eine Variablenklasse, die alle in AutoIt vorhandenen Typen annehmen kann.
Alle nativen Funktionen werden als C++-Funktionen geschrieben und immer haben alle Parameter sowie return-value diesen Typ.
Das Skript wird konvertiert, als Header werden nur die Funktionen+Variablenklasse eingesetzt, damit es keine Überschneidung mit den Namen gibt. Dann wird es kompiliert und mit den vorkompilierten Funktionen zu einem ganzen Programm gelinkt.

Übersichtlich ist der Code aber nicht. Aus

Func Test()
For $i=0 To 3
MsgBox(0, "", $i*2)
Next
EndFunc

wird

//Dieses ist das konvertierte AutoIt-Skript
#include "AutoIt.h"


namespace AU
{
	Variable test();




	void AUMain()
	{
		;
		test();
	}


	Variable test()
	{
		{
			Variable stop(Variable(3));
			Variable stepval(1);
			for (Variable $i = Variable(0); intern::AU_FOR_COMPARISON($i, stop, stepval); $i += stepval)
			{
				msgbox(Variable(0), Variable(L""), $i*Variable(2));
			}
		}

		return Variable();	// Always return anything
	}


}

Ich könnte den Quellcode veröffentlichen, sodass wir alle zusammen daran arbeiten können.
Leider habe ich kaum kommentiert und ohne Wissen, warum ich dies und jenes gemacht habe, ist es am Anfang schwer zu verstehen.

Auf was willst du denn prüfen? Davon hängt die Geschwindgkeit ab.
Am Besten, du stellt dein Script rein, das alles überprüft, und wir suchen für dich nach schnellern Möglichkeiten. 70*100 MB=7GB wird aber immer eine recht lange Zeit dauern.

Zitat von Alina

Ich mag kein Senf dazu geben und sage einfach so: HERZLICH WILLKOMMEN !!!

Sei doch nicht so egoistisch und teile deinen Senf.

Auf jeden Fall gibt es von mir auch ein senfiges Herzlich Willkommen!
[Blockierte Grafik: http://luirig.altervista.org/cpm/albums/bot-units24/brassica-nigra64888.jpg]

Gemäß des Quellcodes verwendet(e) AutoIt einen einfachen ungeordneten Suchbaum für die Variablen und sortiert sie nach Namen.
Sie sind im schlimmsten Fall alle als Kette angeordnet sortiert.

LUA verwendet ein komplett anderes System. Die Variablen werden als Listen (mit Erweiterung) abgespeichert. Die Suchzeit ist immer so, wie es bei AutoIt im schlimmsten Fall ist. Dafür gibt es in LUA Tabellen. Anstatt viele globalen Variablen, sollte man einige globale Tabellen erstellen und darin Variablen und Funktionen speichern.

Lokale Variablen werden in LUA übrigends ohne Name gespeichert, sind also nur Werte im Stack (http://lua-users.org/wiki/ScopeTutorial).

Ich finde es ungünstig, dass es nur die zwei Gültigkeitsbereiche gibt, da man manchmal Variablen nur zeitweise braucht, z.B. nur innerhalb einer Schleife, und dass man auch innerhalb von Funktionen oder neue globale Variablen erzeugen kann.
Letzteres ist eine zusätzliche Fehlerquelle, da es sein kann, dass Variablen unter bestimmten Bedingungen nicht existieren, unter anderen aber schon.

Beispiel:

Es ist vernünftig und wird meistens so gemacht, denn wenn man an einen String nur ein Zeichen anhängt, müsste sonst neuer Speicher alloziiert, der alle Zeichen kopiert, das Zeichen angehängt und dann der alte Speicher freigegeben werden. So verhindert man, dass die ganze Arbeit zu oft gemacht werden muss.
Irgendwo kann man noch Ausschnitte aus dem Programmcode älterer AutoIt-Versionen herunterladen (RegEx, DllCall, GUI-Funktionen wurden herausgenommen). Das hab ich mir mal kurz angeguckt und gesehen, dass AutoIt bei Strings immer auf 8 Byte aufrundet.