Beiträge von BugFix

Zitat von Professor Bernd

Ist das bei dir anders?

Ja - obiger Code komplett markiert: Strg+Shift+Q ergibt

#cs

    While 1
        Switch GUIGetMsg()
            Case $GUI_EVENT_CLOSE
                ExitLoop
;~             Case $idCOLORREF
;~                 _ShowChoice($hGUI, $idMemo, 0, _ChooseColor(0, 255, 0, $hGUI), "Gewählte COLORREF-Farbe: ")
            Case $idBGR
                _ShowChoice($hGUI, $idMemo, 1, _ChooseColor(2, 0x808000, 1, $hGUI), "Gewählte BGR-Farbe: ")
            Case $idRGB
                _ShowChoice($hGUI, $idMemo, 2, _ChooseColor(2, 0x0080C0, 2, $hGUI), "Gewählte RGB-Farbe: ")
        EndSwitch
    WEnd
EndFunc   ;==>Example

#ce

Hast du evtl. deinen Shortcut für Blockkommentar überschrieben?

Edit:

Allerdings hat diese Funktion noch nie als Toggle funktioniert - du kannst also nur den Blockkommentar setzen.

Zitat von Professor Bernd

In Au3 Dateien ist es aber genauso.

Dann prüfe mal deine Einstellungen. So sollte es in etwa aussehen:

#Comments functions definition
comment.block.au3=;~
comment.block.at.line.start.au3=1
comment.stream.start.au3=#cs
comment.stream.end.au3=#ce
comment.box.start.au3=#cs
comment.box.middle.au3=
comment.box.end.au3=#ce

Zitat von Professor Bernd

Es geht um das Ein-Auskommentieren von Code. SciTE nimmt "Block Comment or Uncomment" viel zu wörtlich und toggled jede einzelne Zeile in einem markierten Block, anstatt den ganzen Block auszukommentieren. Auskommentiere Zeilen kommentiert es ein, einkommentierte Zeilen kommentiert es aus. Das nervt gewaltig!

Du befindest dich dort in einer *.properties - Datei. Da gibt es keinen Blockkommentar! Jede Zeile wird deshalb mit einem Kommentarzeichen versehen.

Wie kann man in SciTE4AutoIt3 eine weitere Hilfedatei einbinden, z.B. für Lua?

Zitat von Professor Bernd

Wie kann man in SciTE4AutoIt3 eine weitere Hilfedatei einbinden, z.B. für Lua?

Ich habe lokal abgespeichert: C:/CODE/Lua/doc/lua/www.lua.org/manual/5.1/manual.html

Das Verzeichnis "doc" habe ich angehängt, dann brauchst du nur den Rest des Pfades (und den Pfad deines Browsers) anpassen.

Wenn du keine shell.exec verwendest, musst du dort: os.execute verwenden. Oder mit Default-Browser: os.execute('start "" "'..manual..sel..'"')

(dann gibts das Aufpoppen des Cmd-Windows)

Der Aufruf einer Hilfedatei ist immer an das hinterlegte Filepattern gebunden (au3->AutoIt, lua->Lua, etc.)

In den "SciTEUser.properties" dann einfügen:

command.help.$(file.patterns.lua)=dostring \
local chrome = "C:/Program Files (x86)/Google/Chrome/Application/chrome.exe" \
local manual = "file:///C:/CODE/Lua/doc/lua/www.lua.org/manual/5.1/manual.html#pdf-" \
local sel = props["CurrentSelection"] \
if sel == "" then manual = "file:///C:/CODE/Lua/doc/lua/www.lua.org/manual/5.1/manual.html" end \
shell.exec('"'..chrome..'" "'..manual..sel..'"')
command.help.subsystem.$(file.patterns.lua)=3

Wenn du jetzt einen Begriff in einem lua-Skript markierst und F1 drückst, wird das Manual mit dem Begriff geöffnet (sofern dafür eine Beschreibung hinterlegt ist). Ohne Markierung wird das Manual am Beginn geöffnet.

UPDATE

Die Version 5.1 ist ja obsolet. Ich habe mal die 5.3 noch angefügt.

Für den Aufruf dann "lua5.3.zip" entpacken und mit "file:///Lw:/DEIN/PFAD/lua5.3/manual.html" darauf verweisen:

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

EDIT

Bei Verwendung von Hilfedateien (*.chm) würde der Aufruf so erfolgen (Bsp. Python):

command.help.$(file.patterns.py)=$(CurrentWord)!C:\Python27\Doc\python274.chm
command.help.subsystem.$(file.patterns.py)=4

Sicher auch sinnvoll: Lua-Skripte mit F5 ausführen

(ebenfalls in "SciTEUser.properties" eintragen)

command.go.$(file.patterns.lua)=dofile $(FilePath)
command.go.subsystem.$(file.patterns.lua)=3

EDIT:

Syntaxcheck ist auch brauchbar

Dazu habe ich eine Funktion geschrieben, die so in "SciTEUser.properties" eingebunden wird:

# 22 Syntax Check Lua, if error --> selects error line and makes it visible
command.name.22.$(file.patterns.lua)=SyntaxCheck Lua
command.22.$(file.patterns.lua)=dofile $(Lua.User.Scripts.Path)/LuaCheck.lua
command.mode.22.$(file.patterns.lua)=subsystem:lua,savebefore:yes
command.shortcut.22.$(file.patterns.lua)=Ctrl+F5

Lua.User.Scripts.Path ist eine Property, die vorher definiert werden muss, z.B. Lua.User.Scripts.Path=C:\Code\Lua

-- TIME_STAMP   2020-10-03 10:25:18

do
    local time = function() local tD = os.date("*t", os.time()) return string.format('%02d:%02d:%02d',tD.hour,tD.min,tD.sec) end
    print("+ ["..time().."] Syntax-Check <"..props['FilePath']..">") io.flush()
    local status, err = pcall(function() assert(loadfile(props['FilePath'])) end)
    if status then
        print("> ["..time().."] ------> OK") io.flush()
    else
        local filename = (props['FileNameExt']):gsub('([%(%)%.%%%+%-%*%?%[%^%$])', '%%%1') -- escape magic characters
        local line, errout = err:match(filename..":(%d+):%s+(.+)")
        editor:GotoLine(tonumber(line) -1) editor:LineEndExtend()  -- go to error line, make it visible, select line
        print("! ["..time().."] Line: "..line..", ERROR: "..errout) io.flush()
    end
end

Das ist eine Option, die einen Neustart von SciTE erfordert. Das hatte ich absolut nicht auf dem Schirm.

Nun gut, das Flashen ist weg - aber das ist ja nur die Kosmetik gewesen, das Basisproblem bleibt.

Zitat von Professor Bernd

Dein Link geht zu einer Anmeldung mit Google-Konto, das ich nicht habe. Kannst du das anders verlinken?

Google Groups: scite-interest

Zitat von hipfzwirgel

Demnach liegt das Verhalten am _WinAPI-Code.

Dann versuch mal, die Konsole wieder freizugeben. Sollte man nach Möglichkeit immer tun, wenn man auf Systemressourcen zugreift.

Func _WinAPI_FreeConsole() ; returns true/false
    Local $aRet = DllCall("Kernel32.dll", "bool", "FreeConsole")
    If Not @error Then Return $aRet[0]
EndFunc

Ich habe mir gerade mal die pure Version von SciTE (aktuell Version 4.4.5) installiert und getestet, ob das Flashen tatsächlich weg ist.

Also entweder mache ich was falsch, oder es geht doch noch nicht. Ich habe mal hier angefragt.

Zitat von Bitnugger

Genau betrachtet ist es hauptsächlich sehr ärgerlich, dass der Support für diverse Lua-Dlls unter aller Sau ist.

Leider wahr.

Schade, dass @progandy nicht mehr an Bord ist. Er hatte damals einige Lua-Dll für SciTE verfügbar gemacht.

Zitat von progandy

Für LUA gibt es einige praktische Erweiterungen als DLL, die jedoch nicht mit der in SciTE integrierten Version funktionieren.
SciTE verwendet LUA 5.1 und exportiert die nötigen Funktionen auch in der SciTE.exe. Die DLLs erwarten dagegen die Exports durch eine DLL namens lua5.1.dll.

Ich habe mir zwar die Dll (original für Lua und angepasste für SciTE-Lua) im Hex-Editor angeschaut, auf der Suche nach dieser Einstellung - leider ohne Erfolg.

Sein Wissen in diesem Bereich hätte uns vielleicht hier auch nutzen können.

Zitat von Professor Bernd

könnte Jos nun mit der neuen Version von SciTE eine neue Version von SciTE4AutoIt3 erstellen, in der bei os.execute kein DOS-Fenster mehr aufpoppt. Das wär doch was, oder?

Ja, so sieht es aus.

Jedoch ist das zwar ein Übel, aber eindeutig das geringste.

Die Unmöglichkeit Dll's einzubinden ist das weitaus größere Problem.

Zitat von Musashi

Klingt für mich so, als ob z.B. luaL_register nicht wieder "integriert" wird.

Macht das die von Dir und auch z.B. Bitnugger erstellten Lua-Skripte (sofern sie diese Funktion benötigen) nun gänzlich unbrauchbar, oder könnte man sie mit vertretbarem Aufwand umschreiben ?

Das Hauptproblem ist, dass wir ja nicht auf diese Funktion zugreifen, sondern der Einbindebefehl für Bibliotheken require. Es müsste also in SciTE4AutoIt eine entsprechende Anpassung vorgenommen werden, die require mit luaL_setfuncs in Verbindung bringt. Das muss also derjenige tun, der SciTE4AutoIt kompiliert - in diesem Fall also Jos. Wir haben hier keine Möglichkeit, durch Umschreiben von Skripten zum Ziel zu kommen.

Unsere momentane Lösung sieht so aus:

1. die neueste Version von SciTE4AutoIt installieren

2. die dort enthaltene scite.exe gegen die letzte mit funktionierendem luaL_register austauschen.

Somit haben wir zwar keine neuen Funktionalitäten des Basis-SciTE, aber alle auf neue AutoIt-UDF bezogene Funktionen (Calltips etc.).

Zitat von Musashi

Gibt es eigentlich einen triftigen Grund, warum u.a. luaL_register entfernt wurde ?

Ja, eine neue Lua Version, die das nicht mehr beinhaltet. s. diesen Thread

Zitat von Professor Bernd

Da schmöckere ich nun schon seit Stunden

Da dein Thema CallTip ist: In diesem Post siehst du gut die Erstellung von CallTips in Lua (hier zur Farbanzeige).

Zitat von Professor Bernd

Sind diese Events in Lua auswertbar? Gibt es noch andere Events?

Ja:

Zitat von SciTE Lua Scripting Extension

To begin, you can handle any many of the events exposed by the SciTE Extension Interface. You do this simply by defining functions with the same name as the event. Currently, OnOpen, OnClose, OnSwitchFile, OnSave, OnBeforeSave, OnChar, OnKey, OnSavePointReached, OnSavePointLeft, OnDwellStart, OnDoubleClick, OnMarginClick, OnUpdateUI, and OnUserListSelection are supported.

Die meisten meiner AddOns basieren darauf.

Dazu fehlen in PSPad (dafür soll es doch sein?) die Grundlagen.

In SciTE existieren 2 Events:

- OnKey (die gedrückte Taste, layoutabhängig)

- OnChar (das eingefügte Zeichen, layoutunabhängig)

Letzteres Event wird dazu ausgewertet.

Wenn das Layout nicht bekannt ist / nicht abfragbar ist - dann sieht es schlecht aus mit einer Tastaturauswertung.

Also, das ist schon sehr seltsam.

Ich hatte erst keinen versteckten Text. - Erst nachdem ich die Bar bewegt hatte, erschien er doch im Info-Tool. Die Variante von AspirinJunkie funktionierte dann - aber ausschließlich beim ersten Aufruf wurde die korrekte Zeit ausgegeben. Dieser Zeitwert wurde bei allen späteren Zeitabfragen erneut ausgegeben, obwohl ich zwischendurch immer wieder die aktuelle PC-Zeit übernommen habe.

Erst nach erneutem Bewegen der Bar konnte die korrekte Zeit ausgelesen werden.

Das lässt sich reproduzieren:

- Neustart Software: Kein versteckter Text - Zeit nicht ablesbar

- Manuelles Verschieben der Bar: Text wird in den Fensterbereich "versteckter Text" übertragen

- solange die Bar nicht erneut bewegt wird, bleibt der zuletzt gelesene Zeitwert unverändert

Auf Grundlage dessen denke ich, dass dieser Weg nicht zielführend ist.

Zitat von mikush

Falls das nicht so funktionieren wird gäbe es noch einen zweiten Lösungsansatz. Das Lichtprogramm sendet seine aktuelle Zeit per Netzwerk an ein ein anderes Programm dieses Entwicklers auf einem Raspi welches ich installiert habe um die aktuelle Zeit auf einem Ipad zu sehen wenn das Programm Im Hintergrund läuft.

Kannst du dieses Programm mal posten (bzw. das Client-Programm des Raspi)? Vermutlich kann man darin IP-Adresse/Port auslesen, wohin gesendet wird. Netzwerk ist nicht meine Spezialstrecke, aber da wird sich hier sicher der eine oder andere finden, der dann weitere Ideen hat.

Zitat von mikush

Hier gibt es keine Ausgaben, die Konsole öffnet sich nicht.

Es würde eine MsgBox aufpoppen.

Mithilfe der Demo konnte ich feststellen, dass auf der Bar 2 Edit-Ctrl enthalten sind: Uhrzeit und der Faktor. Ich kann mir zwar die Handle dafür holen - aber bekomme bisher keinen Wert ausgelesen.

Ich probiere mal weiter.

P.S.: Bei mir wird kein versteckter Text des Fensters angezeigt.

Zitat von mikush

War das richtig?

Das Ctrl wurde also gefunden, die Handle stimmen mit dem vom Info-Tool überein.

Zitat von mikush

So sieht das Fenster aus. Es funktioniert auch im Hintergrund, allerdings mit der falschen Uhrzeit.

Dass du die falsche Zeit bekommst.. hmm, sollte eigentlich funktionieren.

Probiere bitte diese Version, (einfach in SciTE mit F5 ausführen) ich bin hier davon ausgegangen, dass nur eine Uhrzeit in dem Control enthalten ist und dieses einstellige Stunden mit Vornull anzeigt.

#include <WinAPISysWin.au3>

Global $sTime = _GetTime()
If Not @error Then MsgBox(0, 'Uhrzeit', $sTime)


Func _GetTime()
    Local $oldOpt = Opt("WinTitleMatchMode", 2)
    Local $hWindow = WinGetHandle("[TITLE:Light @ Night; CLASS:TLichtwerkForm]")
    Opt("WinTitleMatchMode", $oldOpt) ; Option zurücksetzen
    If Not IsHWnd($hWindow) Then Return SetError(1,0,'')  ; "Light @ Night" wurde nicht erkannt!
    Local $aChilds = _WinAPI_EnumChildWindows($hWindow, False)
    If @error Then Return SetError(2,0,'') ; Child-Windows konnten nicht erkannt werden.
    Local $iInstance = 0, $hwndInstance2 = 0
    For $i = 1 To $aChilds[0][0]
        If $aChilds[$i][1] = "TdxBarControl" Then
            $iInstance += 1
            If $iInstance = 2 Then 
                $hwndInstance2 = $aChilds[$i][0]
                ExitLoop
            EndIf
        EndIf
    Next
    If $hwndInstance2 = 0 Then Return SetError(3,0,'')
    Local $aTime = StringRegExp(WinGetText($hwndInstance2), '\b(\d{2}:\d{2})\b', 1)
    If @error Then Return SetError(4,0,'')
    Return $aTime[0]
EndFunc

Zitat von mikush

Folgende Infos werden ausgegeben:

WAS ist das denn für ein Info-Tool? Wer hat das denn so grauenhaft übersetzt? Es gibt Dinge, die darf man einfach nicht übersetzen, sonst wird (wie bei dir) aus dem Programmier-Handle ein "Griff"

Zum Thema. Leider keine Standard-Controls, teste das bitte:

#include <WinAPISysWin.au3>


; Handle des Fensters holen
; Option zum Erkennen von Teilen des Titels aktivieren (falls sich mal die Versionsnummer ändert)
Global $oldOpt = Opt("WinTitleMatchMode", 2)
Global $hWindow = WinGetHandle("[TITLE:Light @ Night; CLASS:TLichtwerkForm]")

; Option zurücksetzen
 Opt("WinTitleMatchMode", $oldOpt)
 
 ; haben wir ein Handle?
 If Not IsHWnd($hWindow) Then Exit MsgBox(16, 'Fehler', '"Light @ Night" wurde nicht erkannt!')
 
 ; Inhalt des Controls auslesen
 ; "TdxBarControl" ist kein Standard Windows Control, normale Funktionen für den Direktzugriff werden also nicht funktionieren.
 ; Aber jedes Ctrl ist nichts anderes als ein Window. Wir müssen es also identifizieren und dessen Text lesen.
 
 ; Wir lassen uns jetzt mal alle Child-Windows und deren Klassennamen für "Light @ Night" ausgeben (auch die nicht sichtbaren). 
 Global $aChilds = _WinAPI_EnumChildWindows($hWindow, False) 
 If @error Then Exit MsgBox(16, 'Fehler', 'Child-Windows konnten nicht erkannt werden.')
 Global $iInstance = 0, $hwndInstance2 = 0
 For $i = 1 To $aChilds[0][0]
    If $aChilds[$i][1] = "TdxBarControl" Then 
        $iInstance += 1 
        If $iInstance = 2 Then $hwndInstance2 = $aChilds[$i][0]
    EndIf
       ConsoleWrite(StringFormat('Handle: %s    ClassName: %s', $aChilds[$i][0], $aChilds[$i][1]) & @CRLF)
 Next
 
 ; wenn alles klappt, sollte hier 2-mal aufgelistet sein:
 ; Handle: 0x0000....     ClassName: TdxBarControl    <-- das 2.te Vorkommen ist die "INSTANCE: 2"
 ; und folgende Ausgabe sollte mit dem Ergebnis des Window-Info-Tools übereinstimmen:
 ConsoleWrite("Handle TdxBarControl: " & $hwndInstance2 & @CRLF)
 
 ; probiere bis hierhin und gib Bescheid, was rausgekommen ist

Wenn alles klappt, kommt das in eine ordentliche Funktion und der Text wird auch noch geholt.

(Kann man die Software irgendwo laden, um den Zugriff mal zu testen?)

Zitat von mikush

Ist es mit einem AutoIt-Script möglich aus einem Programmfenster, welches nicht den Focus am Bildschirm hat, einen Wert (Zeit Std./Min.) (siehe Bild) auszulesen und in ein neues Script zu schreiben?

Das ist davon abhängig, ob das betreffende Programm mit Standard-Windows-Controls arbeitet oder mit anderen (z.B. in Delphi erstelltes grafisches Interface).

Nutze dazu das AutoIt Window Info - Tool ( <Windows-Start Menü> <Programme> <AutoIt v3> <AutoIt Window Info> ).

Ziehe das Finder Tool mit gedrückter Maustaste über das betreffende Control. Poste dann mal, was du im Reiter "Summary" angezeigt bekommst.