Beiträge von Professor Bernd

Danke fürs Ändern.

Zitat von Tweaky

Diese Funktion hat Musashi bereits für sich reserviert

Ja, ja, der Musashi

Wenn du dich darauf beziehst, dass der Funktionsname nicht als Literal übergeben werden muss, das habe ich nicht gewust und nicht gemeint. Ich meinte das Deutsch von

"Der Name der benutzerdefinierten oder Aufruf als Literalstring."

Ich würde nicht sagen, dass es in der englsichen Hilfe falsch beschrieben, sondern eher einfach gehalten ist. Der Hauptzweck der "Call"-Funktion dürfte wohl sein, eine Funktion aufzurufen, indem man den Funktionsnamen als String Literal übergeben kann. Denn wie man eine Funktion normalerweise aufruft, sollte klar sein.

Für mich ist das OK, wenn ihr das alles in die Beschreibung reinbringt, Hauptsache es nicht anhören tun, Yoda gesprochen hat.

Funktion Call

Parameter

Vorschlag:

Tweaky _WinAPI_MessageBoxCheck

Zitat von Professor Bernd

Edit: Tweaky Kannst du mir die entsprechende Hilfe- (wie heißt das?) Vorlage schicken oder verlinken? Dann versuche ich mich gleich an der Übersetzung.

Ok, habe es gerade unter Win 7 x32 getestet, und es ist dort das Gleiche wie unter Win 10: Zwar gibt es einen "LowRegistry" Schlüssel, aber auch dort wird er nicht verwendet. Somit sieht es tatsächlich nach einem Fehler aus. Wo er herkommt und ob MS das falsch publiziert hat kann ich nicht sagen. Was ich sagen kann ist, bei allen Tests, sowohl von dir als auch von mir wird der Registry-Pfad OHNE LowRegistry verwendet!

Auf jeden Fall sollte man auch den "richtigen" Pfad in der Hilfe zeigen .Entscheidet ihr, was zu tun ist.

Edit: Nachtrag nur zur Information. Der Schlüssel LowRegistry war auch bei einer jungfräulichen Win 7 x32 Registry vorhanden, der Schlüssel DontShowMeThisDialogAgain war NICHT vorhanden und wurde erst angelegt, nachdem ich das Häkchen in der MsgBox gesetzt hatte.

Zitat von water

Jetzt fehlt mir etwas der Plan: Ist das ein Dokumentationsfehler bei Microsoft? Oder hat LowRegistry sonst noch eine Bedeutung?

Den Schlüssel "LowRegistry" gibt es definitiv, jedoch bei anderen Anwendungen (ich glaube beim IE oder so), aber halt nicht in dem Pfad, der in der AutoIt Hilfe steht.

Auf der MS Seite zu SHMessageBoxCheckW steht als Datum 12/05/2018, das ist nicht sehr alt. Somit hätte ich eine recht hohe Zuverlässigkeit der Angaben angenommen.Der Beitrag steht unter ".../windows/win32/api/...". War unter deinen Testsystemen ein x32 Windows? Vielleicht ist es unter x32 anders. Vielleicht habe ich irgendwo eine virtuelle Maschine mit x32 Win.

Zitat von water

Ich bin mir noch nicht mal sicher, ob es tatsächlich ein Fehler in der Hilfe ist.

Ich habe es unter Bugs gepostet, in Abstimmung mit Tweaky, der in etwa meinte "ist egal wo du postest, landet alles bei mir!" Und so ist es übersichtlicher, als wenn es überall verstreut liegt.

Zum Thema: Wenn der Pfad z.B. unter Win 7 und 8.x so stimmt wie angegeben (NICHT getestet!), ist es eher als Ergänzung zu sehen, dass unter Win 10 der andere Pfad zutrifft. Dabei wäre zu klären, ob es in einer x32 Version von Win 10 auch so ist.

Na dann ist es ja gut, dass water das mitgekriegt hat. water Genügt der Beitrag hier, oder soll ich noch einen schreiben in "Fehler in der ENGLISCHEN Hilfe bitte hier melden"?

Edit: Tweaky Kannst du mir die entsprechende Hilfe- (wie heißt das?) Vorlage schicken oder verlinken? Dann versuche ich mich gleich an der Übersetzung.

Zitat

Funktion _WinAPI_MessageBoxCheck

Bemerkungen

This function records the message boxes that the user has chosen to suppress under the following registry key.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\LowRegistry\DontShowMeThisDialogAgain

Der Pfad ist bei mir unter Win 10 x64:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\DontShowMeThisDialogAgain

Unofficial version for testers only.

Inoffizielle Version nur für Tester.

Nach diesen guten Erklärungen und interessanten Informationen muss ich mich wirklich beherschen, mich nicht gleich ganz draufzustürzen. Die Vorfreude ist groß!

Dabei habe ich in den letzten Tagen mein PSPad-Projekt ein wenig vernachlässigt und es ruft nach mir. Deshalb kümmere ich mich erstmal darum, bevor ich mich ganz in SciTE verliere.

In den letzten Tagen habe ich mich auch viel über das Problem "Prozedureinsprungpunkt "luaL_register" wurde ... nicht gefunden" informiert. Das sollte man wohl angehen, denn wer weiß, wie lange der Workaround mit einer alten SciTE.exe funktioniert. Schon in alten Threads haben Jos v.d.Z., Melba23, und andere gerne betont, dass es nicht ratsam ist, alte und neue Versionen von Dateien zu mischen, die zu SciTE4AutoIt3 gehören.

Ich hätte gut Lust, bei Neil Hodgson anzufragen, aber erst will ich meine aktuelle Arbeit weiter führen, bevor ich mich in was anderes stürze. Zudem habt ihr vielleicht einen besseren Draht und vorallem mehr Hintergrundwissen. Aus Threads wie z.B. "#2058 Default build on Linux has dynamic libraries disabled" lese ich, dass das Problem vorallem in Zusammenhang mit Linux gemeldet und mit "Status: closed-fixed" abgehakt wurden. Vielleicht nutzt es was, wenn man da mal wieder nachhakt.

Danke!

Edit: BugFix  Bitnugger

1. Wie heißen denn Lua-Dateien, in die man Funktionen schreibt, die dann in anderen Lua-Dateien mit "requiere" eingebunden werden, z.B. die Datei OHKfuncs.lua? Nennt man sie Module, Bibliotheken, oder ...? Und kann man die Lua-Dateien, die nicht zu diese Gruppen gehören alle "Scripts" nennen, oder gibt es weitere Unterscheidungen?

Bis zu deiner Antwort nenne ich allgemeine Lua-Dateien "Scripts" und die Lua-Dateien, die man mit "require" einbindet nenne ich "Bibliotheken".

2. Können Funktionen in anderen Lua-Scripts mit "requiere" benutzt werden, die in der eingebundenen Bibliothek mit "local" deklariert wurden? In der OHKfuncs.lua deklarierst du OHK = {} ohne "local" davor, somit also global. Da meine Lua-/SciTE-Kenntnisse derzeit wohl eher bescheiden sind, will ich mich da nicht auf Tests verlassen, da ich nicht weiß, warum etwas mal funktioniert und mal nicht.

Edit 2:

3. Was ist der Unterschied zwischen requiere "MyModule", LoadLuaFile("MyModule.lua") und LoadUserLuaFile('MyModule.lua')?

Tables habe ich so verstanden: Arrays mit Wertepaaren (key/value). Erinnert ein wenig an WSH Dictonaries.

Zitat von BugFix

Daraus resultiert auch, dass Lua extrem davon profitiert, wenn Funktionen/Variablen explizit lokal deklariert werden.

Meinst du damit, es ist besser ein Table lokal zu deklarieren? Z.B. in "MeinModul.lua" local MyMod = {}?

Cool! Damit weiß ich jetzt auch, wo man solche Infos findet.

Wofür ist denn "OHK = {}" am Anfang er OHKfuncs.lua? In anderen Scripts habe ich z.B. "F = {}" gesehen.

Dein Link hat ein bisschen http... zuviel.

Danke für die Infos.

Wie kann man Shift+F1 und Alt+F1 benutzen, um andere Lua Hilfen aufzurufen? (Ctrl+F1 ist von der SciTE4AutoIt3 Hilfe belegt.)

Mit eurer Hilfe habe ich den Tipp von BugFix ins Laufen gebracht, um mit F1 die lokale Lua Hilfe aufzurufen. Manche Sachen findet man dort, manche nicht. Deshalb würde ich gerne andere Quellen zusätzlich einbinden, z.B. Garry's Mod Wiki (online!) und mit Shift+F1 aufrufen. (Möglichst OHNE einen der wenigen Tool-Menu Shortcuts 35 - 49 zu opfern!)

Aufruf: https://wiki.facepunch.com/gmod/Suchbegriff

Beispiel: https://wiki.facepunch.com/gmod/table.foreach

Zitat von Bitnugger

Wäre ich gehässig, würde ich jetzt einfach nein sagen... doch du hast unverdienterweise unverschämtes Glück.

Hast du deine Schuhe und Strümpfe ausgezogen?

Zitat von Bitnugger

Zu 1.) os.execute() lässt das Windows CMD Fenster nur kurz aufblitzen und versteckt es dann wieder - es wird nicht geschlossen und läuft im Hintergrund weiter, bis SciTE beendet wird.

Das kommt darauf an, ob du den neuen Schalter "create.hidden.console" gesetzt hast. Wenn gesetzt (=1), blitzt das CMD Fenster 1x bei SciTE Start auf und läuft dann im Hintergrund, bis SciTE beendet wird. Wenn nicht gesetzt, wird mit jedem os.execute das CMD Fenster gezeigt. Wenn du "start" im Aufruf benutzt, blitzt das CMD Fenster bei jedem Aufruf auf, ohne "start" läut das CMD Fenster bis das damit gestartete Programm beendet ist.

Zitat von Bitnugger

Keine schlechte Idee... sollte aber gut überlegt sein... denn andere Scripte gehen evtl. davon aus, das diese Properties auf Default stehen.

Das sehe ich auch so. Beim Aufrufen der Lua Hilfe ist es einerseits angenehm, das Caret z.B. in "package.cpath" zu setzen und F1 zu drücken - dann öffnet sich die Lua Hilfe automatisch an der richtigen Stelle. Andererseits ist es aber auch nicht immer gewollt, wenn man z.B. im Text "Lua.User.Scripts.Path" auf "Path" doppelklickt und dann alle 4 Wörter markiert werden. Auch an deinem Argument, dass andere Scripts davon betroffen werden, ist was dran. - Aber das ist wohl mit allem so, dass es 2 Seiten gibt.

Viel wichtiger wäre, Informationen z.B. zu "table.foreach" zu finden, ohne zusätzlich noch Google und anderes bemühen zu müssen.

Zitat von Bitnugger

Einfügen muss man was, aber wie in aller Welt kommst du dabei auf SciTEUser.properties?

Geraten?

Zitat von Bitnugger

Das funktioniert allerdings nur bis SciTE-Version 3.7.5.0, denn in den neueren ist der Einsprungpunkt luaL_register nicht mehr enthalten, weil veraltet.

Das betrifft nur DLLs, nicht lua Bibliotheken.

Ich habe an einem Ersatz für shell.execute gearbeitet, bisher soweit erfolgreich, dass es z.B. in der SciTEStartup.lua funktioniert. Leider lässt sich meine Funktion aus meiner Lua Bibliothek NICHT mit "dostring" in der SciTEUser.properties benutzen. Deshalb habe ich gefragt. - Auch mit require "MeinModul" lässt sich meine Funktion zwar in der SciTEStartup.lua benutzen, aber nicht mit "dostring" in der SciTEUser.properties.

command.help.$(file.patterns.lua)=dostring \
...
shell.exec('"'..chrome..'" "'..manual..sel..'"')
...

Muss man für shell.exec noch etwas in der SciTEUser.properties einfügen, um die Bibliothek einzubinden?

Dank eurer Hilfe funktioniert es nun. Mein Befehlsblock sieht nun so aus:

command.help.$(file.patterns.lua)=dostring \
local chrome = "C:/Program Files/Google/Chrome/Application/chrome.exe" \
local manual = "file:///C:/CODE/Lua/doc/lua5.3/manual.html#pdf-" \
local sel = props["CurrentWord"] \
if sel == "" then manual = "file:///C:/CODE/Lua/doc/lua5.3/manual.html" end \
os.execute('start "" "'..chrome..'" "'..manual..sel..'"')
command.help.subsystem.$(file.patterns.lua)=3

Folgende positiven Dinge sind hervorzuheben:

• os.execute('start "" "'..chrome..'" "'..manual..sel..'"') lässt das Windows CMD Fenster nur kurz aufblitzen, anstatt die ganze Zeit zu laufen, bis der Browser geschlossen wird.
• local sel = props["CurrentWord"] ermöglicht es, die Hilfe aufzurufen, ohne dass ein Wort markiert ist. Es genügt, wenn das Caret in oder an einem Wort steht.
• Zusätzlich funktioniert damit auch das Markieren des Suchwortes, so wie mit local sel = props["CurrentSelection"]. was nützlich ist bei Suchworten, die mit Punkt verbunden sind, z.B. "os.execute" oder "string.format".

Wer auch das Markieren von Suchworten, die mit Punkt verbunden sind, automatisch haben will, kann folgendes in die SciTEUser.properties hinzufügen.

# Wort-Erkennung in Lua Dateien auf zweiteilige Wörter mit Punkt "." dazwischen erweitern.
# Dadurch wird z.B. beim Aufrufen der Hilfe mit Param "CurrentWord" ein zweiteiliges Wort
# mit Punkt dazwischen als Suchbegriff erkannt, z.B. "os.execute", wenn das Caret darin steht.
# Auch werden beide Wortteile markiert, wenn man auf nur einen Wortteil doppelklickt.
word.chars.lua=$(chars.alpha)$(chars.numeric)$(chars.accented)._%
word.characters.$(file.patterns.lua)=$(word.chars.lua)