PSPad4AutoIt3 (Editor IDE)

  • Danke

    Etwas sicherer sind .a3x gegenüber .au3-Dateien daher schon, zumindest liegen sie für den Durchschnittsuser nicht auf dem Präsentierteller und er kann nicht darin herumdoktern ;) .

    Das war das Ziel meiner Überlegungen. Bei meinen Arbeiten geht es grundsätzlich darum, mehr oder weniger von außen auf PSPad einzuwirken. Da war nun schon der ein oder andere recht mächtige Code dabei, den ich ich, sagen wir mal, den Script-Kiddies gerne vorenthalten würde. Möglicherweise würde das dann genügen.

    Ansich würde ich gerne alles offen legen, auch um seriöse Interessierte zu ermutigen, etwas zu erweitern oder zu verbessern.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Sinnvolle Anwendung wäre das Verbergen des Quell-Codes. Wie sieht es denn eigentlich aus mit decompilieren?

    Ich bin seit Jahren schon großer Fan von Open-Source und freier Software. Zwar weiß ich nicht genau wieso das bei dir eine sinnvolle Anwendung wäre den Quell-Code zu verstecken jedoch würde ich dir dringend davon abraten.

    Es genügt schon wenn du die Verhältnismäßigkeit berücksichtigst. Was ist so wertvoll an deiner Software, dass du sie absichern musst? Wenn jemand den Code lesen will, dann wird er ihn auch bekommen. Das ist einfach Zeitverschwendung, du hast besseres zu erledigen.

    .a3x im Kontext von False/Positives bei Virenscannern zu verwenden finde ich absolut in Ordnung. Du könntest auch eine Standard-Exe mitliefern (wie ein Multitool) welches bei verschiedenen Konsolenparametern bestimmte Aufgaben ausführt.

    Möchtest du das nicht, kannst du immer noch Skripte schreiben und sie über eine gewhitelistete kompilierte AutoIt-Exe starten (https://www.autoitscript.com/autoit3/docs/intro/running.htm /AutoIt3ExecuteScript) oder einfach über die installierte AutoIt-Exe (ist ja eine Voraussetzung von dir).

    Dem Argument von Musashi bezüglich herumdoktern kann ich ehrlich gesagt nicht ganz folgen, denn da wird nur jemand etwas ändern wollen, wenn er eine Funktion vermisst oder gab es bei SciTE4AutoIt Leute die reihenweise im Wrapper-Sourcecode rumgestochert haben?

    Außerdem geht dadurch der Komfort verloren auf die schnelle etwas anzupassen, denn es muss sonst recompiled und eingefügt werden, sowas finde ich persönlich immer nervig.

    //Edit:

    Da war nun schon der ein oder andere recht mächtige Code dabei, den ich ich, sagen wir mal, den Script-Kiddies gerne vorenthalten würde.

    Selbstgeschriebener Code oder UDFs von anderen Leuten? Credits musst du dafür ja, je nach Lizenz sowieso geben, aber ich glaube nicht, dass sich Script-Kiddies in deine Richtung verlaufen werden.

    Die verwenden SciTE und machen sich nicht die Mühe einen anderen Editor einzurichten.

    Wie gesagt: Das ist einfach Zeitverschwendung, du hast besseres zu erledigen --- häng dich an solchen banalen Sachen nicht auf.

  • Deinen Argumenten kann ich folgen. Wie geagt, ich würde am liebsten alles teilen und offenlegen. Wenn ich den Quell-Code wirklich verstecken wollte, würde ich in Delphi programmieren. Aber im Moment hat mich AutoIt in seinem Bann, was auch an der genialen Forengemeinschaft liegt! :) Meine Überlegung fußt darin, dass man etwas nicht zurücknehmen kann, was man mal veröffentlich hat.

    Wichtiges Argument ist der große Mehraufwand beim Ändern, Einfügen und neu Compilieren. Wie du dir denken kannst, ist der Aufwand so schon groß genug für mich.

    Mal sehen.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Schreib dir Hilfeskripte, oder benutz post-build Commands (falls du das noch nicht bereits getan hast!!), damit du das nicht per Hand immer kopieren und starten musst.

    Stehe gerade auf dem Schlauch, was meinst du damit?

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Stehe gerade auf dem Schlauch, was meinst du damit?

    Wenn du ein AutoIt-Skript für PSPad schreibst und es in PSPad testen möchtest, schreib dir ein Helperskript welches das Skript in den PSPad Ordner verschiebt, PSPad.exe startet und eventuell die Hotkeys für das Makro sendet.

    Damit sparst du dir viel Zeit, damit du das angepasste Skript nicht immer per Hand reinkopieren musst.

    post-build Commands sind Befehle die ausgeführt werden wenn ein Compilevorgang abgeschlossen ist. Angenommen ich schreibe grad ein Plugin für N++.

    In Visual Studio landet die .dll dann im Projektordner, muss aber erst in das Pluginordner von N++ verschoben werden. Das bei jedem Neucompilen hinzukopieren und den Editor zu starten raubt sehr viel Zeit.

    Deshalb habe ich ein post-build Command in Visual Studio gebastelt (hätte auch einfach ein Helperskript schreiben können welches mit F1 oder so aktiviert wird) welches die fertige DLL in das korrekt Verzeichnis kopiert und direkt den Editor startet damit ichs testen kann.

  • Wow, interessante Sachen!

    Im Moment hab ich es so gelöst, dass ich das jeweilige Script an Ort und Stelle in den PSPad Unterordner platziere und den Namen nicht ändere. Dann entwickele ich und mache immer wieder Backups in einen Ordner außerhalb von PSPad. Dort füge ich dem Script-Namen eine Laufnummer hinzu und stichwortartig die Änderungen.

    Insgesamt herrscht bei mir gerade ein heftiges Chaos, aber bei weitem nicht mehr so schlimm, wie es mal war. Deshalb brauche ich auch noch etwas Zeit, um die fertig gestellten Features zu veröffentlichen. Zum Glück gibt es keinen Abgabetermin u.ä. :D Bei mir kommt irgendwann ein Punkt, da muss ich aufräumen, und dann funktioniert das auch. Im Moment geht das aber nicht, denn bei mir ist es so, dass ich nichts mehr finde, wenn ich aufgeräumt habe. Bei all den Infos die in meinem Kopf rumschwirren, wäre das eine Katastrophe. Also, Eile mit Weile! :) (Jetzt wäre irgendsoein Buddha-Smilie passend.)

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Wahrscheinlich werden sich unsere Posts gleich überschneiden, aber was soll's :

    .a3x im Kontext von False/Positives bei Virenscannern zu verwenden finde ich absolut in Ordnung.

    Das war auch mein Hauptanliegen - alle anderen Optionen dienten lediglich der Information, weil

    Professor Bernd gefragt hat.

    Dem Argument von Musashi bezüglich herumdoktern kann ich ehrlich gesagt nicht ganz folgen, denn da wird nur jemand etwas ändern wollen, wenn er eine Funktion vermisst ...

    Das wäre der wünschenswerte Zustand.

    Wenn man aber z.B. kleinere Servicetools an Kunden schickt, dann finden sich immer irgendwelche Schlauberger die meinen, sie könnten auf eigene Faust alles 'verbessern'.

    Denen darf man anschließend erklären, dass die von ihnen verursachten Fehler ja ihre eigene Schuld sind usw. und das ist, allein vom Zeitaufwand her, extrem nervig. Da nützen auch keine Verbotsklauseln in den Lizenzbestimmungen - am Telefon hast Du sie trotzdem.

    Für das Projekt von Professor Bernd sind diese Aspekte natürlich weitgehend irrelevant.

    Den Rest sehe ich genau wie Du !

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • News

    Eine neue Version ist fast fertig. Veröffentlichung ist geplant für in etwa 2 Wochen.

    Die neue Version unterscheidet sich gewaltig von der vorherigen. Für die Kernfunktionalitäten "Run", "Syntax Check", "Compile" und "Compile Dialog" werden nicht mehr die PSPad eigenen Compiler-Funktionen benutzt, sondern Au3-Scripts. (Vielen Dank an BugFix für Ideen und code snippets!) Insbesondere mein "CompilerRunner" ist zu erwähnen, der, wie der Name schon ahnen lässt, die "Compiler" Funktionen steuert. Dazu wird eine neue "AutoIt3Wrapper.au3" (SciTE) benutzt, die von Jos van der Zande (Autor) auf meine Anfrage hin für PSPad und andere Editoren geöffnet und angepasst wurde. (Vielen Dank an Jos!) CompilerRunner fängt den Output auf, bearbeitet ihn und schickt ihn an das Log-Win von PSPad.

    Einer der größten Vorteile der Verlagerung der Compiler-Steuerung in Au3-Scripts ist die Trennung von PSPad. PSPad bleibt dadurch unabhängig und ist auch während des Compilier-Vorgangs frei bedienbar. Das war möglich durch die Unterstützung von Jan Fiala (Autor PSPad), der viele meiner Feature Requests in PSPad eingebaut hat. (Vielen Dank an Jan!) So kann ich nun das Highlighting für Fehlerzeilen im Editor-Bereich von PSPad per VBScript auslösen.

    Die Implementierung der Kernfunktionalitäten per Au3- und VB-Scripts war für mich eine recht gewaltige Aufgabe, die ich bis hierhin lösen konnte. Auch gibt es noch ein paar kleine Funktionen wie "Debug to ..." und das Einbinden des "Koda FormDesigner", sowie einige Bugfixes. Das alles war recht lehrreich für mich und ich hoffe, dass euch die neue Version gefallen wird. :)

    Feedback willkommen.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Veröffentlichung verschiebt sich.

    Zwei Wochen sind fast vorbei, die neue Version ist fertig. Die AutoIt Kernfunktionalitäten habe ich in meinem Improvement Kit "0.2.0" eingebaut und sie funktionieren bei mir tadellos. Auch gibt es eine weitere neue PSPad Developer Version, die wieder neue Funktionen für AutoIt enthält. (Vielen Dank an Jan Fiala!) Auch diese haben den Weg ins Improvement Kit gefunden. :)

    Musashi hat mir den Tipp gegeben, die Pfade zu AuotIt3 und SciTE4AutoIt3 aus der "festen Verdrahtung" zu befreien. (Vielen Dank an Musashi!) Die Pfade werden nun vom User erfragt und mithilfe der PSPad4AutoIt3.ini gehandhabt. Dadurch sind nun auch abweichende Pfade möglich, für User, die AutoIt und SciTE nicht im Standard-Pfad installiert haben.

    Dazu wurde eine VBScript-Lösung (!) zum Lesen/Schreiben von INI-Dateien implementiert und auch die Vorbedingungen für das Improvement Kit werden nun geprüft. Summa summarum ist es mittlerweile ein recht komplexes Projekt geworden. Deshalb werde ich eine Setup-Routine erstellen, um den Usern das Installieren zu erleichtern. Auch wenn ich von Installation spreche, PSPad4AutoIt3 bleibt natürlich portabel. :thumbup:

    Das schaffe ich natürlich nicht alles auf einmal, weshalb sich die Veröffentlichung wohl ins neuen Jahr verschiebt. Ich wünsche euch ein gesegnetes Wheinachtsfest und alles Gute fürs neue Jahr. :saint:

    Bernd.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Professor Bernd 30. Januar 2020 um 20:16

    Hat den Titel des Themas von „PSPad4AutoIt3 Projekt DE“ zu „PSPad4AutoIt3 Projekt“ geändert.
  • Nach monatelanger Arbeit ist es nun soweit, PSPad4AutoIt3 Version 1.0.0 beta ist fertig. :party:

    Ich nenne es gerne die "erste richtige" Version, da das Improvement Kit nun vieles autonom verarbeitet. Dadurch bleibt PSPad bedienbar, wenn ein au3-Script gestartet wird. Auch gibt es nun ein Setup, das die Einrichtung erleichtert. :thumbup:

    Die Kernfunktionalitäten "Run, Check Syntax, Compile und Comile Dialog" sind integriert und funktionieren sehr gut. Es gibt auch ein paar weitere Features, die man im Hauptmenü findet, Menüpunkt "Scripts" => "_AutoIt". Dazu gehören z. B. "Debug to Console", "Debug to MsgBox" und der "Koda FormDesigner" als Helper zum Erstellen von GUIs. In diesem Menü gibt es auch einen Punkt "_Tips and shortcuts". Nach eine Klick werden die AutoIt-relevanten Shortcuts angezeigt.

    Ich würde mich freuen, wenn ihr es euch anseht und hier eure Meinung schreibt. Viel Spaß! :)

    Sobald Gun-Food den Upload ermöglicht, kann der Download im Posting #1 gefunden werden.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Nach monatelanger Arbeit ist es nun soweit, PSPad4AutoIt3 Version 1.0.0 beta ist fertig. :party:

    Das wurde aber auch langsam Zeit :P:rock:.

    Sobald Gun-Food den Upload ermöglicht, ...

    Falls das nicht klappt, oder das Setup in zukünftigen Versionen deutlich größer wird, dann könnte man die Datei (auch binaries) in kleinere Segmente splitten und anschließend wieder zusammenfügen. Dafür gibt es verschiedene Verfahren, siehe z.B. :

    https://superuser.com/questions/1991…e-in-many-files

    Nachteil : Man müsste das Setup auf mehrere Beiträge verteilen (daher ist das auch nur eine Notfalloption).

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • ... könnte man die Datei (auch binaries) in kleinere Segmente splitten und anschließend wieder zusammenfügen.

    Diese Idee ist gut und ich habe sie auch schon ausprobiert. Ein Freund von mir hat sich zum Testen angeboten. Er ist als Normal-User einzuordnen. Leider hat sich gezeigt, dass er mit den Dateien nichts anfangen konnte, die als Endung .zip.001 hatten. Aber auch ein erfahrener User müsste zwingend eine entsprechende Zip/Rar Software installieren.

    Ich experimentiere derzeit mit Dropbox und anderen Filehostern. WordPress habe ich schon probiert, leider kein Upload von exe oder zip möglich. Auch eine Homepage für wenig Euro habe ich in Betracht gezogen, kann aber leider weder den Aufwand noch die Einschränkungen einschätzen.

    Für den Moment habe ich einen WebInstaller in Vorbereitung, der Dateien von Dropbox o. ä. nachläd. Das ist noch ein wenig mehr zusätzlicher Aufwand, und wer weiß, was die Antivirensoftwares dazu sagen. Ich habe Gun-Food und Raupi kontaktiert. Meine Hoffnung ist, dass einer der beiden den Upload ermöglicht. Wenn sich bis Mittwoch keiner meldet, versuche ich den WebInstaller hochzuladen.

    Das wurde aber auch langsam Zeit :P:rock: .

    Vielen Dank! Das motiviert zum weitermachen! :thumbup:

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Ich habe Gun-Food und Raupi kontaktiert. Meine Hoffnung ist, dass einer der beiden den Upload ermöglicht.

    Das wäre sicherlich eines der besten Verfahren !

    Er ist als Normal-User einzuordnen. Leider hat sich gezeigt, dass er mit den Dateien nichts anfangen konnte, die als Endung .zip.001 hatten. Aber auch ein erfahrener User müsste zwingend eine entsprechende Zip/Rar Software installieren.

    Das Splitten wäre, wie gesagt, nur eine Notfalloption, trotzdem ein paar Infos :

    Um die Segmente, also z.B. File.zip.001, File.zip.002 usw., zusammenzufügen, müsste nicht zwingend eine entsprechende Zip/Rar Software installiert werden.

    Dafür kann man den CMD-Befehl copy/b (hier als Batch) verwenden :

    C
    @echo off
    echo Wiederherstellen der Originaldatei aus den Segmenten :
    copy/b "File.zip.001" "File.zip"
    copy/b "File.zip" + "File.zip.002"
    copy/b "File.zip" + "File.zip.003"
    copy/b "File.zip" + "File.zip.004"
    echo.
    echo Wiederherstellen beendet

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Packs doch vorübergehend einfach auf ein Google Drive und poste den Freigabelink. Da hast du 15 GB Platz. :P

    Auch eine gute Idee. :thumbup:Ich bin noch in der Erkundungsphase über die Vor- und Nachteile. Da gibt es einige Punkte, die man erst mal rausfinden muss, z. B. ob die Datei nächste Woche noch da ist ... :whistling: Wird schon klappen!

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Splitten ... Um die Segmente, also z.B. File.zip.001, File.zip.002 usw., zusammenzufügen, müsste nicht zwingend eine entsprechende Zip/Rar Software installiert werden. Dafür kann man den CMD-Befehl copy/b (hier als Batch) verwenden :

    Das ist eine interessante Möglichkeit! Werde ich prüfen! :thumbup:

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Gun-Food Der Upload hat funktioniert, du bist der Beste! :thumbup:

    Nach monatelanger Arbeit ist es nun soweit, PSPad4AutoIt3 Version 1.0.0 beta ist fertig. :party:

    OK, es kann losgehen! Der Download in Posting #1 ist nun möglich, also lasst die Leitungen rauschen!

    Ich würde mich freuen, wenn ihr es euch anseht und eure Meinung schreibt. Viel Spaß! :)

    Bernd.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    Einmal editiert, zuletzt von Professor Bernd (17. Februar 2020 um 22:24)