Beiträge von Andy

Ich bin absolut bei AspirinJunkie .

Zitat von Velted

Der 32-bittige Hexwert 0xFFFFFFF2 entspricht aber dem Dezimalwert -14.

DAS ist schon der Fehler.....eine Hexadezimalzahl entspricht einer Zahl zur Basis 16. Und da ist absolut kein Platz für "negative" Zahlen.

Dass ein INT in 32Bit die negativen Zahlen mit einschließt, hat mit der Hexadezimaldarstellung nichts zu tun! Diese Definition ist ausschließlich relevant für die Darstellung von Dezimalzahlen. Und nur dann erfolgt auch die "Anpassung" an ein Vorzeichen!

0xFFFFFFF2 ist also IMMER 4294967282.

Und da diese dezimale Zahl als (signed) INT nicht im Wertebereich von −2.147.483.648 bis 2.147.483.647 DARSTELLBAR ist, wird per Definition (für die dezimale Darstellung von INT) ein "negativer" Wert von -14 "festgelegt".

Die Entsprechung einer hexadezimalen Zahl ist (in AutoIt s. DllStructCreate) PTR, HWND oder HANDLE. Und da kann man machen was man will, es wird NIE "negative" PTR, HWND oder HANDLE geben.

//EDIT

Zitat von AspirinJunkie

Die Aufgabe der Hex-Notation für Zahlen in AutoIt ist jedoch eine andere: Eingabe von Zahlenwerten im Hexadezimalsystem. Und an diesem Punkt ist der Datentyp, in welchem das mal kodiert werden noch völlig egal.

Daher ist es ein Abweichen vom zu erwartenden Verhalten und für mich daher klar ein Bug.

THIS!

Zitat von Mars

meine aktuelle Aufgabe

Erzähl!

Zitat von Mars

Gerade bei der Geometrieverarbeitung erwartet dich in AutoIt nur Trauer und Schmerz.

Zitat von Mars

Das ist auch das allergrößte Hindernis an einem Übersetzungsprogramm: Datenstrukturen.

hmmm, sehe ich nicht so. Datenstrukturen kannst du, wie in deinem Beispiel gezeigt, "irgendwie" immer hinbiegen.....ist genaugenommen ja nur Bytes im Speicher

Wie du auch geschrieben hattest, ist die Übersetzung von (flat) C recht einfach. Bin zwar nicht der Guru, habe mich aber in den letzten beiden Jahren intensiv mit OpenCL (natürlich aus AutoIt heraus^^) beschäftigt, und die Kernel dort sind simples C. Was für mich persönlich wirklich schön ist, denn ich kann mit einem Basic-Interpreter höchstperformanten Code schreiben, der automatisch mit der Anzahl der Cores auf CPU und GPU skaliert und sich Geschwindigkeitsmäßig hinter keiner anderen Programmiersprache verstecken muss. Von "lesbarem" Code ganz abgesehen, denn was in AutoIt "selbstverständlich" in einigen Zeilen abgehandelt wird, füllt bspw. in C++ etliche Seiten.

C++ ist dagegen die Evolutionsstufe von C nach 50 Jahren sog. "Weiterentwicklung" mehrerer zehntausend Programmierer. Da bleibt aus Sicht von AutoIt auch nicht mehr viel zu verstehen. Ich bin auch überzeugt dass 90% aller (guten) C++ - Programmierer nicht verstehen wie C++ intern abläuft. müssen die auch gar nicht, die müssen lediglich das System NUTZEN! Und da ist der "Vorsprung" von C++ uneinholbar gewaltig. Nicht etwa weil C++ so unglaublich toll ist, sondern weil es zwölfundneunzig Millionen Varianten gibt, aus 5 unterschiedlichsten Zeilen Quellcode identisch compilierten Code zu erzeugen. Je nach Wissen und Gusto des Entwicklers.

Manchmal stolpere ich auf Stack Overflow über Threads, wo ein Blinder dem anderen Blinden über die Straße hilft....letztendlich lesen tausende Leute diesen Thread, aber etwas effektiv LERNEN wird da keiner. Man versucht halt, mit etlichen Varianten von Code die eine nachgefragte unverstandene Codevariante zu erklären.....

Daher bin ich immer noch dafür, den C++-Code in einen Funktionsrahmen zu packen und als DLL zu kompilieren.

Zitat von Mars

Außerdem sind DllStructs in AutoIt deutlich langsamer als z.B. Arrays

Was vor einiger Zeit geändert wurde. "Früher" war das gleich schnell, ich hatte mal einen Übersetzer geschrieben, der Arraycode in DllStruct-Code umgewandelt hatte, damit ich aus Assembler darauf zugreifen konnte.

Zitat von Mars

Code der in C++ richtig schnell läuft muss komplett umstrukturiert werden um in AutoIt ebenfalls schnell zu laufen

Naja, mit Verlaub, ich lache

Zwei nested loops mit einer x-beliebigen Funktion drin und Autoit ist Faktor 100 bis 1000 langsamer. Simple 5 Zeilen Code werfen dich Geschwindigkeitsmäßig auf einen 8088 mit 4.77 Mhz aus 1982 zurück....

Daher schreibe ich mir mein Script in AutoIt, suche den "inner loop" (der Programmteil, der 99% der Laufzeit mit Berechnungen verbrennt) und wandle nur diesen "inner loop" mit einer anderen x-beliebigen kompilierenden Programmiersprache in eine DLL oder schreibe den, just for fun, in Assembler. Einfach weil´s Spass macht....

Aber mal ganz ehrlich, wer schreibt ernsthaft SOLCHE Anwendungen in AutoIt?! Hehe, irgendwann hat sich hier der Ausdruck "Brotlose Kunst" etabliert!

Zitat von Mars

dann kann der Compiler auch automatisch sse verwenden, dann mag er 4x32er Blöcke lieber).

Ja, am meisten beeindruckt mich sowieso der Compiler, völlig unabhängig von der Syntax der Programmiersprache. Mittlerweile "erkennt" der Compiler, was der unglaublich schlechte Programmierer mit hingerotztem Scheißcode erreichen will und baut den Code so um, dass das Compilat extrem performant ist. Aber wie gesagt, da kann der Programmierer nix dafür!!!

Ich hatte über einen Bekannten vor einiger Zeit mal Zugriff auf einen INTEL-Compiler (als Privatmann kaufst du dir anstatt der Vollversion lieber ein Auto!)

Den hatten wir absichtlich mit "miesem" Code gefüttert und ich war echt von den Socken was letztendlich an Assemblercode ausgespuckt wurde.

Der hatte unsere absichtlich gebastelte array of structs (AoS) selbstständig in eine SoA umgewandelt, die unaligned im Speicher abgelegten Daten dann SSE-konform aufgedröselt und alles zusammen in (für mich) "wundeschönen" SIMD SSE-Code umgewandelt. Gleichzeitig noch die Goodies einer INTEL-CPU berücksichtigt und daraufhin optimiert.....da wurde mir dann klar, dass der Skill desjenigen, der blöd auf den Monitor glotzt und auf der Tastatur rumhämmert, letztendlich zweitrangig ist! Jedenfalls fast...

Zitat von Mars

Das ist kein Code den ich für irgendwas sinnvolles verwenden würde

Nana...ist doch ein schönes Beispiel wie so etwas "richtig" gelöst werden könnte

Hehe, aber in letzter Zeit bist du AutoItscriptmäßig sowieso auf einem seltsamen "Trip"?!

Hi,

ich habe mir mal einige der Codedateien angeschaut, und gehe davon aus, dass du an einen Konverter nicht mal ansatzweise wirst denken können...

Zitat von PSblnkd

Eine händische Konvertierung ist sehr mühsam

...entweder du machst das trotzdem, oder, ein Ansatz den ich ins Auge fassen würde, du kompilierst die C++-Files in eine DLL, deren Funktionen du dann per AutoIt in (nativer) Geschwindigkeit per DllCall() auch ausführen kannst.

Wobei es dann Sinn macht, alle Sourcefiles in EINE C++-Datei zu kopieren (per AutoItscript ist das nicht das Problem) und daraus dann eine DLL zu kompilieren.

Hi,

dieses "Problem" der fehlenden "on error (goto)"-Funktion ist einer der großen "Krankheiten" von AutoIt!

Wenn der "Fehler" von einer COM-Funktion kommt, kannst du diesen im COM-error handler abfangen....cool, oder?

Bei schickimickistateoftheart-COM ist das errorhandling bei sog "Fehlern" möglich und auch gewollt (sic) und da wird auch seitens Entwicklern bis zum Erbrechen drauf hingewiesen, aber bei "Standard"-Fehlern bei 0815-Funktionen ist das so etwas von uncool, unnötig und gefälligst vom Programmierer mit unendlich langem Code (Abfrage ALLER möglichen Fehler per @error-code) abzufangen....wie ich schon sagte...KRANK!!

Warum bei einem BASIC-Interpreter von 1981 ein "on error" funktioniert ( und übrigens bei etlichen anderen bis heute gebräuchlichen und weit verbreiteten Programmiersprachen auch), aber bei einem "modernen" BASIC-Interpreter wie AutoIt nicht, musst du die Entwickler fragen....lass es, ich habe es gemacht...

Dir bleibt also nichts weiter übrig, als ALLE möglichen (!) Fehler per @error abzufangen und darauf zu reagieren, oder (wenn du COM verwendest), einen com-error-handler zu programmieren.

Hi,

Zitat von kilo

Nachtrag: Da ich viel in Excel und VBA Programmiere (wo das Zuweisen von "Variablen innerhalb einer Variablen" übrigens funktioniert) dachte ich, dass "XY-Problem" tatsächlich

für Achsen (z.B.: innerhalb einer Matrix oder eines Arrays) steht.

na dann...zeig doch einfach mal deine 8-10 Zeilen VBA-Code...und wenn es mehr sind....dann auch die!

Genau wie AspirinJunkie vermute ich nämlich auch, dass hier völlig F A L S C H E "Lösungsansätze" abgefragt werden.

@"helfende" Forianer

Es macht wenig Sinn, reflexartig auf die "Ich weiss was! - Taste" zu hämmern und Script-"Lösungen" zu posten wenn das Problem nicht oder nur unklar definiert ist! Der TE soll ein funktionierendes Snippet, IN EGAL WELCHER PROGRAMMIERSPRACHE posten und wir versuchen dann, diese Programmlogik in AutoIt umzusetzen! Ich bin nicht der ultimative Glaskugelleser, wer von euch da entsprechende Expertisen hat, soll mir diese zukommen lassen....Ich lerne gerne jeden Tag dazu!

Jemand "neues" der diesen Thread hier liest, verabschiedet sich mit Recht(!) sofort und sucht ein Forum, in dem einem auch geholfen wird!

Das ist jetzt der 35. Beitrag, ich bin echt gespannt, wann die erste mit den Beispieldaten (sic!) funktionierende "Lösung" gepostet wird...

Zitat von Jepp

eine vollständige Adress-Datenbank in 4.256 Byte und sogar mit Suchfunktion - was für ein wunderbares Programm!

Eigentlich wäre es doch ein schönes Autoit-Projekt, solche "Schätzchen" direkt (in bspw. der DOSBox) per "Doppelklick" aufrufbar zu machen. nicht erst DOSBox herunterladen und installieren, mit der autoexec.bat kämpfen, DOS-Programm installieren uswusf. sondern das alles automatisiert. Ein "Paket" erstellen, dass nach Doppelklick nach einigen Sekunden das DOS-Programm laufen lässt....

Für solche User wie bspw. Alina, die sich mit Emulatoren (zu Recht (!) ) nicht mehr herumschlagen wollen, sondern einfach "nur" das Programm anschauen wollen.

Jepp, was hat dich hierher verschlagen?

Also muss/soll man diese Funktion nicht implementieren?! Wäre sicher nicht der große Aufwand. Aber wenn das für dich unnötig ist, dann können wir es auch lassen^^

Ja genau, klick da mal drauf, also auf die grünen Vierecke, dann kannst du das zweite, dritte, vierte, bis zum x-ten zusätzlichen Symbol aktivieren, und beim 2. und 7. aktivierten Symbol kommt dann so etwas raus:

pasted-from-clipboard.png

Hast du dir mal das Bild oben in meinem Post angeschaut?

Mit den von mir markierten secondary Symbolen?! Und das dazu passende Ergebnis unten im Bild?

Offensichtlich nicht....

Zitat von mumpel

Doch, sind drin. $jabPic.SymbolVersionsX = 1 und $jabPic.SymbolVersionsY = 1

dann erstelle doch mal das Beispiel vom Bild von der Website aus Post#11 mit dem AutoItscript, geht das bei dir?

Zitat von mumpel

Welche meiner Testprojekte hast Du ausprobiert?

Deine jabcode.zip aus dem Startpost. Andere Dateien wurden bisher nicht gepostet.

Zitat

Welche meinst Du?

JAB Code

pasted-from-clipboard.png

Alina,

bitte diesen Müll löschen, bevor da noch jemand auf die Idee kommt, das zu testen und hier Diskussionen aufkommen, warum und wieso das nicht funktioniert.

mumpel ,

Excel stürzt bei mir ab, wenn ich das VBA-Script mehrfach aufrufe, d.h. anderen Text eingeben und den Button klicken führt zum Absturz.

Auch der (beim ersten mal) erstellte Code sieht anders aus als bei meinem AutoItscript.

Aber....mein Script erstellt den gleichen Barcode wie die die Website, folglich ist im VBA-Code irgendetwas faul?!

Kannst du das bitte verifizieren?

Auch die zusätzlich erstellbaren Symbole sind in meinem AutoItScript nicht integriert, wenn du das nicht selbst hinbekommst, bitte kurze Info!

Deine GUI ist unerheblich!

Wichtig ist erstmal, dass das von mir erstellte Script, welches ein Ergebnis erzeugt, auch bei dir läuft!

Also kopiere bitte das AutoItscript aus diesem Post in das Verzeichnis, in dem die jabwrapper.dll liegt. Günstigstenfalls nimmst du das Verzeichnis, von dem du das gezippte Beispiel aus dem Startpost verwendet hast!

Dann bitte die Ausgabe der Konsole posten.

Hmmm, bei mir schon...

Setze mal

#AutoIt3Wrapper_UseX64=n

vor dein Script, es wird eine 32Bit-Dll verwendet.

Das AutoItscript muss ins Verzeichnis der DLL

DEINVERZEICHNIS\jabcode\jabcodeWrapper\dlls32

#AutoIt3Wrapper_UseX64=n


if FileExists("test.png") Then
    $ret=filedelete("test.png")
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
endif


$dll=dllopen("jabwrapper.dll")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $dll = ' & $dll & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console


$jabPic=dllstructcreate("" & _
    "ptr InputString;" & _
    "ptr FileName;" & _
    "long ColorNumber;" & _
    "long SymbolNumber;" & _
    "long ModuleSize;" & _
    "long MasterSymbolWidth;" & _
    "long MasterSymbolHeight;" & _
    "long SymbolPositions;" & _
    "long SymbolPositionsNumber;" & _
    "long SymbolVersionsX;" & _
    "long SymbolVersionsY;" & _
    "long SymbolVersionsNumber;" & _
    "long SymbolEccLevels;" & _
    "long SymbolEccLevelsNumber;" & _
    "long ColorSpace")

    $jabpicptr=dllstructgetptr($jabPic)

    $InputString = "pipapoiodfshja9eihfihfaüeiohfaüehfioühfaseiohfiohefaseiohfsioühfioshefg"
    $inputstruct=dllstructcreate("char[1024]")
    $InputStringptr=dllstructgetptr($inputstruct)
    DllStructSetData($inputstruct,1,$InputString)
    $jabPic.InputString=$InputStringptr
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $jabPic.InputString = ' & $jabPic.InputString & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

    $FileName = @ScriptDir & "\test.png"
    $FileNamestruct=dllstructcreate("char[1024]")
    $FileNameptr=dllstructgetptr($FileNamestruct)
    DllStructSetData($FileNamestruct,1,$FileName)
    $jabPic.FileName=$FileNameptr
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $jabPic.FileName = ' & $jabPic.FileName & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

    $jabPic.ColorNumber = 8
    $jabPic.ModuleSize = 6
    $jabPic.SymbolVersionsX = 1
    $jabPic.SymbolVersionsY = 1
    $jabPic.SymbolEccLevelsNumber = 0

    $ret=dllcall($dll,"uint","writeToTmpFile","ptr",$jabpicptr)
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

    shellexecute("test.png")

/EDIT

In der Konsole müsste es so aussehen:

@@ Debug(7) : $ret = 1

>Error code: 0

@@ Debug(12) : $dll = 1

>Error code: 0

@@ Debug(39) : $jabPic.InputString = 0x00E73F80 //oder anderer pointer

>Error code: 0

@@ Debug(46) : $jabPic.FileName = 0x00E76360

>Error code: 0

@@ Debug(55) : $ret =

>Error code: 0

+>15:08:19 AutoIt3.exe ended.rc:0

+>15:08:19 AutoIt3Wrapper Finished.

Hi Rene,

Zitat von mumpel

Aber ab jabPic.InputString komme ich nicht weiter (da muss man ja Type jabDTO und Dim jabPic As jabDTO umschreiben können).

ich habe das so gelöst:

$dll=dllopen("jabwrapper.dll")


$jabPic=dllstructcreate("" & _
    "ptr InputString;" & _
    "ptr FileName;" & _
    "long ColorNumber;" & _
    "long SymbolNumber;" & _
    "long ModuleSize;" & _
    "long MasterSymbolWidth;" & _
    "long MasterSymbolHeight;" & _
    "long SymbolPositions;" & _
    "long SymbolPositionsNumber;" & _
    "long SymbolVersionsX;" & _
    "long SymbolVersionsY;" & _
    "long SymbolVersionsNumber;" & _
    "long SymbolEccLevels;" & _
    "long SymbolEccLevelsNumber;" & _
    "long ColorSpace")

    $jabpicptr=dllstructgetptr($jabPic)

    $InputString = "blablub"
    $inputstruct=dllstructcreate("char[1024]")
    $InputStringptr=dllstructgetptr($inputstruct)
    DllStructSetData($inputstruct,1,$InputString)
    $jabPic.InputString=$InputStringptr
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $jabPic.InputString = ' & $jabPic.InputString & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

    $FileName = @ScriptDir & "\test.png"
    $FileNamestruct=dllstructcreate("char[1024]")
    $FileNameptr=dllstructgetptr($FileNamestruct)
    DllStructSetData($FileNamestruct,1,$FileName)
    $jabPic.FileName=$FileNameptr
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $jabPic.FileName = ' & $jabPic.FileName & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

    $jabPic.ColorNumber = 8
    $jabPic.ModuleSize = 6
    $jabPic.SymbolVersionsX = 1
    $jabPic.SymbolVersionsY = 1
    $jabPic.SymbolEccLevelsNumber = 0

    $ret=dllcall($dll,"str","writeToTmpFile","ptr",$jabpicptr)
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

    shellexecute("test.png")

Die GUI drumrumstricken musst du selbst!

Hi Alina,

das Programm ist eigentlich selbsterklärend und funktioniert einwandfrei. Mehr als die angegebenen "Menüpunkte" gibt es nicht.

Mit der Pagedown-Taste wird ein neuer "Datensatz" angelegt, in Anlehnung an die damals üblichen Karteikarten.

Als "Datenbank" wird eine Textdatei erstellt mit FIXEN Feldlängen!

Das ist (aus heutiger Sicht) insofern etwas verwunderlich, als das 1992, bei der Erstellung dieses Programms, um jedes Byte Speicherplatz gekämpft wurde!

Der Grund ist, dass die Feldlänge in der Eingabemaske beschränkt war! Die "Zeichen", incl. der Leerzeichen bis zum Ende des Eingabefeldes, wurden Zeichen für Zeichen in die Datei geschrieben...maximal 255 Zeichen passen in einen "Datensatz" (aka Zeile der Textdatei).

Jede Zeile in der Textdatei beschreibt einen "Datensatz".

Und wer meint, die einzelnen "Adressfelder" würden in Variablen geschrieben, der täuscht sich gewaltig!

Die einzelnen Zeichen wurden, und werden auch im Programm, direkt aus dem Bildschirmspeicher, also dem Userinterface, ausgelesen und in die Datei geschrieben.

pasted-from-clipboard.png

Man kann/darf dem Autor aber keinen Vorwurf machen, damals war das "State of the art"....ich weiß von was ich Rede, als ich "damals" anfing, in Programmen variable Feldlängen zu benutzen und zu fordern, und die Daten auf dem Datenträger zusammenzufassen und das auch noch in "professionellen" Umgebungen, da wurde ich massiv angegriffen.

Und heute?! Da MUSST du bei der Erstellung einer Datenbank (immer noch) FIXE (maximale) Feldlängen angeben...soviel zu "Fortschritt" in 50 Jahren Softwareentwicklung.

Wenn du willst, kannst du gerne ein Transferprogramm in AutoIt schreiben, um eine bestehende Adressdatenbank in das ADR-Format zu konvertieren und dann mit ADR zu benutzen

Ich habe mir mit einem Debugger/Disassembler den (Maschinen-)Code angeschaut, das ist (nicht verwunderlich) SEHR Oldschool^^. Ich bin mir sicher, dass das Programm mit einem Assembler geschrieben wurde.

pasted-from-clipboard.png

Dabei habe ich auch einen Hinweis/Tag/Unterschrift direkt am Anfang des Codes des Autors O. (Oliver) Zupan gefunden: Den String @<CLS+INV

Sagt dir das etwas?

Übrigens ist das Programm sehr "modular" aufgebaut, ich denke dass man es durchaus in eine "moderne" *.EXE konvertieren könnte.

Der (ggf. kommentierte) Sourcecode wäre da natürlich besser geeignet als die Ausgabe des Disassemblers...Die Frage stellt sich, wer sich diese Arbeit antuen will....

Da lädt man doch lieber die schicke, mit Maus bedienbare und "bunte", Gigabytes große Adress-Software mit "professioneller" Datenbank

ICH habe schon damals das Userinterface in BASIC geschrieben und nur die geschwindigkeitskritischen Programmteile in Assembler. Das mache ich heute, 40 Jahre später, noch genau so! Nur mit AutoIt und Assembler....der "guten alten Zeiten" wegen

Hi,

der (Unter)Ordner "AutoIt" steht ja bei dir auch nicht in der Registry.

Du könntest diesen Verweis natürlich händisch in die Registry schreiben, aber wer weiß, was bei der Installation noch alles schief gegangen ist, was du aktuell noch garnicht merkst...

Zitat von Alina

AutoIt neu installieren oderSciTe ???

Im Zweifelsfall: Beides

Btw. es kann auch zu Rechteproblemen im AutoItordner kommen, siehe Post oben.

Den gesamten Ordner und alle Unterordner musst du für das Lesen und Schreiben freigeben!

Hi Alina,

Zitat von Alina

Der Ordner in dem AutoIt v3 installiert ist, ist: autoit3 und nicht autoit v3

Der "Pfad" in der Registry "HKCU\Software\AutoIt v3\Autoit" hat nichts mit dem Dateipfad zu tun, in den du deine Anwendung installiert hast!

Zitat von Alina

Habe gestern Organize Includes installiert

Wie hast du das gemacht?

Vorgehen:

Dateien installieren von unserer Website :

pasted-from-clipboard.png

Erst AutoIt stabil, dann Scite, dann OrganizeIncludes.

Habe ich eben bei einem neu aufgesetzten Win10 gemacht, funktioniert einwandfrei!

Öffne mal in Scite im Reiter "Optionen" den "User option file", das sind die SCITEUser.properties

Darin sollte es einen Eintrag geben der so aussieht, wenn du alle AutoIt/Scite-Dateien in die vorgeschlagenen Verzeichnisse installiert hast:

# 36 OrganizeIncludes
command.36.*.au3="$(autoit3dir)\autoit3.exe" "$(SciteDefaultHome)\OrganizeIncludes\OI_1.0.0.50.au3" "$(FilePath)"
command.name.36.*.au3=OrganizeIncludes
command.save.before.36.*.au3=1
command.is.filter.36.*.au3=1
command.shortcut.36.*.au3=F2

Die Nummer "36" ist bei mir so, kann bei dir aber anders sein. Wichtig ist nur, dass diese Zuordnung zur Taste "F2" (siehe letzte Zeile), nicht doppelt vorkommt!

Dann schaust du im AutoIt-Verzeichnis:

pasted-from-clipboard.png

Sind dort alle Dateien?

Dann Registry "Registrierungseditor" öffnen, links in den "Pfad" HKCU\Software\AutoIt v3\Autoit navigieren. HKCU ist HKEY_CURRENT_USER!!!

Das sollte dann so aussehen:

Wenn sich Dateien oder Verzeichnisse NICHT in diesen Datei-Ordnern auf der Festplatte oder in der Registry befinden, dann solltest du AutoIt/Scite/OrganizeIncludes komplett in die vorgeschlagenen Verzeichnisse neu installieren!

Wenn das wieder nicht funktioniert, zeige bitte DEINE Screenshots von den Ordnern bzw. der Registry...

Hallo!

Zitat von Fastluso

ich bin 51 Jahre jung

hehe, gegenüber anderen Aktiven hier im Forum bist du wirklich "jung" . Viel Spass mit Autoit!

Aus welchem Grund willst du anfangen zu programmieren und warum gerade mit AutoIt, wo es doch soooo viele andere gerade aktuell "hippe" Programmiersprachen gibt?!