Och, ich wollte auch was total geistreiches schreiben, aber ich bin zu müde und habs vergessen! Frohe Ostern!
Beiträge von Professor Bernd
-
-
Für PSPad4AutoIt3 suche ich einen hübschen About-Dialog, in dem auch Credits angezeigt werden können. Künstlerische Fähigkeiten sind nicht meine Stärke, "abkäsen" ist nicht meine erste Wahl, wenn also jemand eine nette Idee hat, würde ich mich freuen.
-
Das Ergebnis dieser Umfrage beziehe ich in der kommenden Version von PSPad4AutoIt3 mit ein.
---------------------------------------------------
Vielen Dank für eure Stimmen!
Somit wird in der kommenden Veröffentlichung von PSPad4AutoIt3 der Shortcut für die Redo-Aktion ("Yiederherstellen") doppelt belegt, also mit Ctrl+Y und Shift+Ctrl+Z (z.B. für das US Keyboard Layout).
-
Vielleicht weil du nicht schreibst was dieses PSPad4AutoIt3 überhaupt sein soll und etwas das den Punkt "portabel" schon als Killerfeature bezeichnen muss nicht sonderlich anspornend ist selbst zu suchen was das sein soll.
Nochmals vielen Dank für deinen Hinweis! Voher hatten sich 0 gemeldet, doch nachdem ich das Eingangsposting und die Überschrift nach deinen Kriterien geändert habe sind es nun doppelt so viele!
-
Auch wenn es kein Trost für dich ist, aber vielleicht mal eine Überlegung warum das so sein könnte:
Ein Trost vielleicht nicht, aber nützliche Informationen!
Momentan stecke ich in Vorbereitungen fürs QM-Audit, da bin ich etwas knapp mit meiner Zeit für eine umfassende Prüfung. Wenn das durch ist, bin ich aber gern bereit mal zu testen.
Da freue ich mich drauf!
-
'Portable' zu sein ist, für sich allein genommen, natürlich kein Killerfeature. ... Es wird aber sicher User geben, die diesen Aspekt schätzen werden.
Bestimmt! Bei der letzten Version haben einige befürchtet, sie müssten ihr geliebtes altes AutoIt oder SciTE opfern, da es für PSPad4AutoIt3 Abhängigkeiten gab (siehe die noch aktuelle Version PSPad4AutoIt3 v1.2.0 beta - Update (2020-08-03).
Mit der nächsten Version gibt es diese Probleme nicht mehr, denn wie Lottich schrieb, ist es mir gelungen, "das Tool installationsfrei zum Laufen zu bekommen". Somit kann man das nächste PSPad4AutoIt3 einfach entpacken und loslegen, egal welche AutoIt-Version man benutzen möchte (ab 3.3.14.0). SciTE4AutoIt3 wird gar nicht mehr benötigt und kann problemlos parallel benutzt werden, egal welche Version.
-
er meint, dass er portabel nicht als killerfeature betrachtet. Ich übrigens auch nicht.
ABER: es ist für mich gut nachvollziehbar, dass du es so siehst. Du steckst dein ganzes Herzblut in dein Projekt und bist voller Enthusiasmus dabei. Freust dich natürlich extrem, dass es dir gelang das Tool installationsfrei zum Laufen zu bekommen. War vermutlich auch eine Heidenarbeit. Von daher ist es durchaus logisch, dass du es als Killerfeature ansiehst 🙂Herzlichen Dank für diese Info! Das ist genau das, was ich wissen wollte! Das hatte ich für die nächste Veröffentlichung geplant, als Killerfeature auf den Projekt-Seiten zu präsentieren. Eurer Info entsprechend werde ich das nun nicht mehr tun. Danke für eure Meinung!
Eigentlich war eine Veröffentlichung als Weihnachtsgeschenk 2020 gedacht und es war auch fertig. - Fast fertig! Wenn nicht alpines mich angestachelt hätte, auch diese "Kleinigkeit" einzubauen. - Bei der Entwicklung von Ideen, PSPad4AutoIt3 portabel zu machen, war er noch dabei. Sein Rat war schon lange unschätzbar wertvoll für mich! Aber leider hat er das Forum verlassen. Große Hilfe fand ich im EN Forum, um eine Kommunikation zwischen PSPad und AutoIt zu etablieren. Zwar gab es schon Möglichkeiten, aber keine die schnell genug war, um einen CallTip ohne Verzögerung anzuzeigen und zu aktualisieren.
Auch PSPad machte immer wieder Schwierigkeiten, da es sich zwar veränderte, aber nicht immer in meinem Sinne. PSPad ist Closed Source Software und NICHT von mir! Somit ist mein Einfluss so groß oder klein wie von jedem anderen User auch.
Nun wird es mindestens April, bis diese "Kleinigkeit" fertig ist, um PSPad4AutoIt3 portabel zu machen. Für den User ist das ... hmm, ja was? Eine Kleinigkeit? Eine Nebensächlichkeit? Eine Selbstverständlichkeit? Auf jeden Fall nicht das Gleiche, was es für mich ist. Wie du es gut erklärt hast, steckt viel Herzblut von mir darin und es war tatsächlich eine Heidenarbeit. Abgesehen vom CallTipViewer hat kein anderes Feature so viel Zeit und Arbeit gekostet!
SciTE hat eine wahre Vielfalt an Schnittstellen: SciTE Extension Interface, SciTE Director Interface, SciTE Lua Scripting Extension, ... und bietet sogar Editor-Events Damit kann man echt viel machen - zuviel für mich, als ich vor knapp 2 Jahren mit dieser Idee begann.
PSPad hat als Schnittstelle nur VBScript und bietet KEINE Editor-Events, was gegenüber den Fähigkeiten von SciTE fast popelig wirkt. Somit müssen alle Erweiterungen hauptsächlich von außen erfolgen. Wer sich also schonmal mit einem Closed Source Editor + VBScript + COM Objekte als AcitveX-DLLs + COM Objekte als IROT Einträge beschäftigt hat, und versucht hat, das alles zusammen mit AutoIt zu verbinden, der weiß, was für eine Heidenarbeit das war.
-
etwas das den Punkt "portabel" schon als Killerfeature bezeichnen muss nicht sonderlich anspornend ist selbst zu suchen was das sein soll.
Wie ist das denn zu verstehen? Wie kann "portabel" deinen Ansporn mindern?
-
Vielleicht weil du nicht schreibst was dieses PSPad4AutoIt3 überhaupt sein soll
Auch wenn eine Google-Suche in Sekunden diese Frage beantwortet hätte, hast du natürlich Recht, dass ich es potentiell Interessierten mit einem Klick auf PSPad4AutoIt3 ganz bequem machen kann. Das habe ich nun im ersten Thread geändert, einfach auf PSPad4AutoIt3 klicken. Danke für den Hinweis!
Wer viele Monate intensiv an (s)einem Projekt arbeitet, gerät nicht selten in einen Tunnel. Man geht davon aus, dass alle Welt das Projekt kennen muss bzw. nur darauf gewartet hat. Auf dieses Phänomen hat Professor Bernd aber kein Monopol, das kann jedem passieren und tut es häufig auch .
Da hast du ein wahres Wort gesprochen! Wie ich im ersten Post geschrieben habe, wird man immer wieder betriebsblind.
Man geht davon aus, dass alle Welt das Projekt kennen muss
Nicht nur das, sondern auch andersrum, dass die AutoIt-Welt mich automatisch mit PSPad4AutoIt3 verbindet. Seit etwa 1 Jahr habe ich das Gefühl, auch wenn ich hier im Forum ganz allgemeine Fragen gepostet habe, es grundsätzlich auf PSPad4AutoIt3 bezogen wurde, obwohl ich PSPad mit keinem Wort erwähnt habe. Da kann man schon irgendwie den Eindruck gewinnen, dass man mit dem Projekt verbunden wird und es "jeder" kennt. Dem ist natürlich nicht so, ... wie gesagt: Betriebsblind. Danke fürs Verständnis!
-
Über 60 Zugriffe auf diesen Thread und keine einzige Antwort!
Sorry, eigentlich dachte ich, im Bereich "Hilfe & Unterstützung" gäbe es Hilfe & Unterstützung! Und ehrlich, ich würde mich freuen über ein bisschen Hilfe & Unterstützung! Also hopp, PN schreiben und testen. Wer keine PN schreiben will, kann auch direkt hier posten!
Zum Testen muss man kein Profi sein, das kann jeder!
-
Wenn ich es richtig verstanden habe, war luaL_register eine exportierte Funktion aus dem in SciTE verankerten Lua, die es in der aktuellen Lua-Version aber nicht mehr gibt.
Lua 5.2 Reference Manual, 8.3 – Changes in the API
Function
luaL_register
is deprecated. UseluaL_setfuncs
so that your module does not create globals.Damit ist mein LUA-Latein am Ende. Leider weiß ich nicht, wie man das nutzt und ob Jos v.d.Z. dazu eine Fix einbauen kann. Aber meine Vermutung ist, dass das eher von Neil Hodgson gefixt werden kann, so wie er es wohl für Linux schon getan hat: #2058 Default build on Linux has dynamic libraries disabled und Bug [#2058]. On Linux, enable Lua to access dynamic libraries.
-
Ich hatte bisher noch keine Lust so tief in die Materie einzutauchen, dass ich mir SciTE selbst kompiliere - aber vielleicht ist das die einzige Lösung.
Da bin ich dabei, wenn du das umsetzen willst!
-
Es ist wieder soweit, eine neue Version von PSPad4AutoIt3 steht in den Startlöchern.
DE Forum: PSPad4AutoIt3 (Editor IDE), EN Forum PSPad4AutoIt3 (editor IDE)
Diesmal gibts wieder ein "Killer-Feature": PSPad4AutoIt3 wird voll portabel! PSPad ist somit unabhängig von AutoIt- und SciTE- Installationen des User. Natürlich benötigt man für "Run", "Compile", "Hilfe", usw. eine AutoIt Installation des Users, aber alle PSPad-eigenen Funktionen laufen auch ohne, sogar der CallTipViewer.
Das heißt auch, dass man PSPad4AutoIt3 einfach ausprobieren kann, ohne dass es ein vorhandenes SciTE beeinflusst. Alles läßt sich "rückstandslos" entfernen: Wenn man zum Ausprobieren die .au3 Datei-Endung mit PSPad verknüpft (über das Tool im AutoIt3-Menü!), kann man es mit dem selben Tool wieder rückgängig machen und SciTE ist wieder mit .au3 verknüpft (wenn es das vorher war).
Weil man selbst immer wieder betriebsblind wird, suche ich Tester, die PSPad4AutoIt3 auf Herz und Nieren testen, bevor es veröffentlicht wird. Ich würde mich über Zuschriften per PN (Konversation) freuen!
-
Vielen Dank fürs Weiterentwickeln und "Dran bleiben"! Dadurch hat man die Gewissheit, dass ISN lebendig ist.
-
Das Thema "luaL_register" ist schon etwas älter, hier und hier wurde z.B. darüber geredet. Soweit ich mich erinnern kann, fällt dadurch die Möglichkeit weg, DLLs einzubinden. Vorallem die shell.dll wurde von Usern schmerzlich vermisst. Deshalb hier vorerst die Fragen:
- Hat sich da etwas getan? Gibt es "luaL_register" wieder oder einen Ersatz?
- Hat jemand mit Neil Hodgson geredet? Was kam dabei raus?
- Falls nicht: Welche Funktionen werden von euch denn hauptsächlich benutzt/vermisst?
- Kann man vielleicht Ersatzfunktionen erstellen?
Ich habe einen möglichen Workaround gefunden, um das Aufblitzen des CMD-Fensters bei "os.execute" zu verhindern. Wieviel würde das denn nutzen, bezüglich des "luaL_register" Problems? Wenn es z.B. 1 von 4 Problemen wäre, könnte der Workaround Licht am Ende des Tunnels bedeuten. Wenn es z.B. 1 von 40 Problemen wäre, vergesst meinen Beitrag.
Ok, bitte steinigt mich nicht, ich habe vieles über SciTE und Lua wieder vergessen und auch die Zusammenhänge, um was es genau ging, aber ich meine es gut!
-
Bei mir wird ein AutoIt-Script bei einem Doppelklick nicht in den dafür konfigurierten Editor geladen, sondern ausgeführt... das solltest du berücksichtigen.
Da hast du recht und das ist schon berücksichtigt! Der User die volle Kontrolle: Nichts wird hinter seinem Rücken gemacht, sondern er kann einen Einstellungsdialog aufrufen und selbst entscheiden, was er will.
HKCU vs. HKLM - so habe ich das für mich gespeichert:
Key aus HKCU wird verwendet, falls vorhanden, falls nicht, wird der aus HKLM verwendet. Ist in HKCU und HKLM kein Key, wird der Default-Wert verwendet.
Das deckt sich mit meinen Recherchen. - AutoIt speichert in HKLM, mein Script speichert in HKCU. Das hat den Vorteil, dass wenn man in meinem Einstellungsdialog auf "Deregister" klickt, die von AutoIt gesetzten Einstellungen wieder in Kraft treten. War vorher als Doppelklick-Aktion "ausführen" eingestellt, ist es dann wieder so. War vorher "Open" oder "Edit" eingestellt, wird das wieder hergestellt.
Vielen Dank für die Info und für den Hinweis zu "Run" vs "Edit".
-
-
BugFix Darf ich dein Script "GetUnusedVars.au3" in PSPad4AutoIt3 benutzen und verteilen? Ich würde mich freuen!
Übrigens, wenn ich mich nicht vertan habe, müsste dein Script bei sich selbst auch eine ungenutze Variable zeigen: $error.
-
also, wenn ich dein Vorhaben richtig verstehe, willst du anscheinend ein AutoIt-Script schreiben, was auf jedem Rechner, egal mit welchen Rechten, ausgeführt werden kann und das dir immer die notwendigen Rechte geben soll, damit du in alle Registry-Schlüssel schreiben kannst.
Das hast du falsch verstanden. All deine Beiträge beinhalten Änderungen, zu denen man meiner Meinung nach Admin-Rechte benötigt, aber du hast geschrieben:
Also ich kann die Einträge problemlos ohne UAC-Meldung oder Admin-Rechte usw. in "HKLM\Software\Classes" schreiben.
Das geht auf jedem meiner vier Rechner und auch sofort bei einem absolut jungfräulichen Windows 10.
Das hat dann wohl nicht so ganz gestimmt, denn:
um die Schlüssel in die Registry zu schreiben, verwende ich nicht den "RegWrite"-Befehl von AutoIt.
Ich schreibe alle Schlüssel usw. in eine "reg"-Datei und importiere die Datei dann mit:
"Run(@WindowsDir & "\explorer.exe " & $_sRegistryFile)"
...
Für das Problem mit den Admin-Berechtigungen, gibt es z.B. das Programm "PowerRun" ...
Auch die beiden brauchen Admin-Rechte!
Also das geht wohl nicht, das würde ja einige Sicherheitsvorkehrungen von Windows unterlaufen.
Vielleicht bist du mit deinen Gedanken nicht ganz hierbei, aber genau das habe ich doch die ganze Zeit geschrieben.
Wie sieht denn dein AutoIt-Code aus, mit dem das geht? Bei mir gibts ohne Admin-Rechte Error.
Dass man OHNE Admin-Rechte in HKLM schreiben könnte, hast du geschrieben, nicht ich. Also sind wir jetzt wieder auf gleichem Stand, dass schreiben in HKLM ohne Admin-Rechte NICHT möglich ist?
-
Du tapezierst ja auch nicht, bevor du die Wände gemauert hast.
Hi hi, find ich gut!
Hier mal ein ganz minimalistisches Bsp. um mit ASO und GUI zu arbeiten:
Hey, ich denke, das geht in "meine" Richtung!