Beiträge von BugFix

Leider nicht, da der Verweis auf die Funktion fehlt.

Ich verstehe es so:

SciFnDirect pSciMsg = (SciFnDirect)SendMessage(hSciWnd, SCI_GETDIRECTFUNCTION, 0, 0);

SCI_GETDIRECTFUNCTION gibt den Pointer auf die Scintilla-interne Sendmessage-Funktion zurück: pSciMsg

sptr_t pSciWndData = (sptr_t)SendMessage(hSciWnd, SCI_GETDIRECTPOINTER, 0, 0);

SCI_GETDIRECTPOINTER gibt den Pointer auf das ScintillaFensterHandle zurück: pSciWndData

sptr_t CallScintilla(unsigned int iMessage, uptr_t wParam, sptr_t lParam);{

return pSciMsg(pSciWndData, iMessage, wParam, lParam);

}

Die interne Funktion wird mittels Pointer aufgerufen und der Pointer für das Handle übergeben (plus Msg/Parameter).

Eigentlich sollte AutoIt mit Funktionspointern klarkommen, wurde ja vor nicht allzu langer Zeit integriert - aber der Handle-Pointer scheint das Problem zu sein, wenn ich das richtig interpretiere.

In Anlehnung an dieses Thema wollte ich mal probieren die Scintilla-interne Messagefunktion zu nutzen.

Aber C/C++ ist nicht meine Baustelle, da gerät Portieren zur reinen Raterei. Kann mir jemand sagen, wie man das in AutoIt umsetzt (falls es überhaupt geht)?

On Windows, the message-passing scheme used to communicate between the container and Scintilla is mediated by the operating system SendMessage function and can lead to bad performance when calling intensively. To avoid this overhead, Scintilla provides messages that allow you to call the Scintilla message function directly. The code to do this in C/C++ is of the form:

#include "Scintilla.h"
SciFnDirect pSciMsg = (SciFnDirect)SendMessage(hSciWnd, SCI_GETDIRECTFUNCTION, 0, 0);
sptr_t pSciWndData = (sptr_t)SendMessage(hSciWnd, SCI_GETDIRECTPOINTER, 0, 0);

// now a wrapper to call Scintilla directly
sptr_t CallScintilla(unsigned int iMessage, uptr_t wParam, sptr_t lParam){
    return pSciMsg(pSciWndData, iMessage, wParam, lParam);
}
SciFnDirect, sptr_t and uptr_t are declared in Scintilla.h. hSciWnd is the window handle returned when you created the Scintilla window.

While faster, this direct calling will cause problems if performed from a different thread to the native thread of the Scintilla window in which case SendMessage(hSciWnd, SCI_*, wParam, lParam) should be used to synchronize with the window's thread.

Hier mein Versuch:

#include <SendMessage.au3>

Global Const $SCI_GETDIRECTFUNCTION = 2184
Global Const $SCI_GETDIRECTPOINTER = 2185
Global Const $SCI_GETCURLINE = 2027

; Handle des Editors ermitteln
Global $hWndSciTE = WinGetHandle('[Class:SciTEWindow]')
Global $hWndSciTEEditor = ControlGetHandle($hWndSciTE, '', '[Class:Scintilla;Instance:1]')

;===================================================================================================
Global $pSciMsg = Ptr(_SendMessage($hWndSciTEEditor, $SCI_GETDIRECTFUNCTION))
Global $pSciWndData = Ptr(_SendMessage($hWndSciTEEditor, $SCI_GETDIRECTPOINTER))

Func CallScintilla($iMessage, $wParam, $lParam)
    Return $pSciMsg($pSciWndData, $iMessage, $wParam, $lParam)
EndFunc
;===================================================================================================

Global $iLen =  CallScintilla($SCI_GETCURLINE, 0, 0) 
ConsoleWrite("@@ Debug line" & @TAB & @ScriptLineNumber & "   var: $iLen --> " & $iLen & @LF)

; ERROR
; ==> Variable cannot be accessed in this manner.:
; Return $pSciMsg($pSciWndData, $iMessage, $wParam, $lParam)
; Return $pSciMsg^ ERROR

Bisher habe ich auf SciTE über Lua-Skripte oder das SciTE-Director-Interface zugegriffen. Das Interface erlaubt aber nur einen geringen Teil der Funktionen zu nutzen. Deshalb schreibe ich gerade ein Scintilla Interface. Im Wesentlichen ist das auch unproblematisch und hauptsächlich Schreibarbeit. Aber bei Funktionen, die Text auslesen sollen, also einen Buffer bereitstellen, an den die Funktion dann übergibt, hänge ich im Moment und weiß nicht warum.

Exemplarisch habe ich mal gewählt: SCI_GETCURLINE

Damit werden Inhalt und Länge der aktuellen Zeile abgefragt. Die Länge stimmt auch, aber der Textbuffer wird nicht befüllt und die Position in der Zeile wird nicht zurückgegeben.

Hat jemand eine Idee?

#cs
SCI_GETCURLINE(int length, char *text NUL-terminated) → int
This retrieves the text of the line containing the caret and returns the position within the line of the caret.
Pass in char* text pointing at a buffer large enough to hold the text you wish to retrieve and a terminating 0 character.
Set length to the length of the buffer which must be at least 1 to hold the terminating 0 character.
If the text argument is 0 then the length that should be allocated to store the entire current line is returned.
#ce

#include <SendMessage.au3>

Global Const $SCI_GETCURLINE = 2027

; Handle des Editors ermitteln
Global $hWndSciTE = WinGetHandle('[Class:SciTEWindow]')
Global $hWndSciTEEditor = ControlGetHandle($hWndSciTE, '', '[Class:Scintilla;Instance:1]')

; Länge der aktuellen Zeile (Zeile in der der Cursor steht)
Global $iLen =  _SendMessage($hWndSciTEEditor, $SCI_GETCURLINE)    ; inkl. Zeilenumbruch
ConsoleWrite("@@ Debug line" & @TAB & @ScriptLineNumber & "   var: $iLen --> " & $iLen & @LF)

; Buffer bereitstellen für Null-terminierten String
Global $tBuffer = DllStructCreate('char[' & $iLen +1 & ']')

; Text der aktuellen Zeile abfragen
Global $iPosInLine = _SendMessage($hWndSciTEEditor, $SCI_GETCURLINE, $iLen+1, DllStructGetPtr($tBuffer))
ConsoleWrite("@@ Debug line" & @TAB & @ScriptLineNumber & "   var: $iPosInLine --> " & $iPosInLine & @LF & "!@ " & @TAB & "#Error: " & @error & @TAB & "#Extended: " & @extended & @LF)

; Ausgabe in Konsole
ConsoleWrite('Current-Line:' & @CRLF & DllStructGetData($tBuffer, 1) & @CRLF)

Das gabs doch schon mal, vielleicht hilft dir das:

https://autoit.de/index.php?thre…0838#post360838

Es ist zwar nicht explizit erwähnt, aber da Hardlinks im Gegensatz zu Softlinks mit Run/ShellExecute nicht ausführbar sind, scheint da eine Begrenzung im System vorzuliegen.

Mal vormerken und in die Hilfe mit einfügen.

BTW:

Der Ordner C:\Windows\winsxs enthält ausschliesslich mit Hardlinks verknüpfte Daten. Wenn du was suchst, bist du dort richtig.

WFS.exe ist keine Datei - das ist ein Hardlink zu den tatsächlichen Speicherorten. Schau im Register Hardlink bei Dateieigenschaften, dann findest du die tatsächlichen Speicherorte:

C:\Windows\winsxs\amd64_microsoft-windows-f..client-applications_31bf3856ad364e35_6.1.7601.17514_none_d71fb1d63f05ef22\WFS.exe
C:\Windows\winsxs\amd64_microsoft-windows-f..client-applications_31bf3856ad364e35_6.1.7601.17559_none_d6f973983f21dd99\WFS.exe
C:\Windows\winsxs\amd64_microsoft-windows-f..client-applications_31bf3856ad364e35_6.1.7601.21659_none_d7831063583f7d63\WFS.exe

Zitat von Lashandan

Func _GetLastBootUp($_sComputer=$sComputer) ;"." steht für lokalen Rechner

Das ist unklug, als Standardwert eine Variable zu verwenden. Wenn ein Parameter vorbelegt wird, verwendet man einen fixen Wert, der in der wahrscheinlich häufigsten Nutzung der Funktion zur Anwendung kommt. Dann spart man sich die Übergabe dieses Parameters.

Also entweder mit Vorbelegung lokaler PC

Func _GetLastBootUp($_sComputer='.')

oder ohne Vorbelegung

Func _GetLastBootUp($_sComputer)

Kann es sein, dass der WMI-Dienst bei dir nicht gestartet ist?

Frag das mal ab mit: sc query winmgmt

Wenn nicht aktiviert, starte mit: sc start winmgmt

3D ist vorstellbar, wie ein Rubik-Würfel (3x3x3).

Wenn du vorn draufschaust, siehst du Breite x Höhe. Von der Seite betrachtet kommt die Tiefe hinzu.

In AutoIt also Global $a3D[$BREITE][$HOEHE][$TIEFE].

Wobei es völlig egal ist, welche Dimension du als Breite/Höhe/Tiefe betrachtest. Beim Zugriff muss dir nur klar sein, welches Element du gerade ansprechen willst.

Zitat von Lashandan

bekomme dein Script irgendwie nicht zum Laufen - muss ich noch irgendwas mitgeben?

Bei Abfrage des lokalen PC ist der Name vorbelegt (.). Es reicht also _GetLastBootUp(). Nur für andere PC im Netzwerk ist der PC-Name mit zu übergeben.

Auf meinem PC (Win7 Pro x64) funktioniert es, wie gewollt.

Netzzugriff kann ich mangels anderer Netzwerk-PC nicht testen. Jedoch muss in der Windows Firewall WMI eingehend zugelassen werden.

- abfragen: netsh advfirewall firewall show rule name="Windows-Verwaltungsinstrumentation (WMI eingehend)"

- erlauben: netsh advfirewall firewall set rule group="Windows-Verwaltungsinstrumentation (WMI)" new enable=yes

Würde ich so machen:

Bei LogOff/ShutDown/Restart:

http://www.autoitscript.com/autoit3/docs/f…xitRegister.htm

Bei Startup:

In der Registry unter HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run führst du bei jedem Start ein Skript aus:

- Auslesen Startzeit

Func _GetLastBootUp($_sComputer='.')
    Local $oWMIService = ObjGet("winmgmts:\\" & $_sComputer & "\root\cimv2")
    If Not IsObj($oWMIService) Then Return ''
    Local $oColOperatingSystems = $oWMIService.ExecQuery("Select LastBootUpTime from Win32_OperatingSystem")
    Local $sBootup
    For $oOS in $oColOperatingSystems
        $sBootup = $oOS.LastBootUpTime   ; --> 20180210112637.125599+060
    Next
    Return StringRegExpReplace($sBootup, '(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2}).+', '\1-\2-\3 \4:\5:\6')
EndFunc

- Auslesen CurrentUser @UserName

-- beides Eintragen in deine Logdatei

Die LogOn Info bekommst du doch am Besten serverseitig über AD-Funktionen ausgelesen.

Zitat von Bitnugger

Bei mir verschwindet der Tip nicht, wenn ich das Caret nach rechts/links bewege

Da hatte ich mich vertan, es wird das Standardverhalten von Calltip verwendet, also Beenden bei Mausklick oder Pfeil-Auf/Ab, Enter. Das werde ich mal mit Einbauen.

Zitat von Bitnugger

Wenn der Farbwert nicht aus 6 Hex-Werten besteht, verhält sich das auch merkwürdig...

Ja, wegen der vorher möglichen Zuweisungserkennung mit Funktionen hatte ich fest auf Hex mit Länge 6 geprüft. Das werde ich mal noch großzügiger gestalten.

#include <WinAPISys.au3>
#include <WinAPI.au3>

GUICreate('Test')
Global $idCombo = GUICtrlCreateCombo('', 10, 10, 100)
Global $sData = 'Editor|Calculator|CMD'
GUICtrlSetData($idCombo, $sData, 'Editor')

GUISetState()

While True
    Switch GUIGetMsg()
        Case $GUI_EVENT_PRIMARYUP
            If _MouseInComboEdit($idCombo) Then _ActionCombo()
        Case -3
            Exit
    EndSwitch
WEnd

Func _ActionCombo()
    Switch GUICtrlRead($idCombo)
        Case 'Editor'
            ShellExecute('notepad')
        Case 'Calculator'
            ShellExecute('calc')
        Case 'CMD'
            ShellExecute('cmd')
    EndSwitch
EndFunc

Func _MouseInComboEdit($_ID_Combo)
    Local $hCombo = GUICtrlGetHandle($_ID_Combo)
    Local $hEdit = _WinAPI_EnumChildWindows($hCombo)[1][0]
    Local $hParent = _WinAPI_GetParent($hEdit)
    Local $tMouse = _WinAPI_GetMousePos(False, $hParent)
    Local $tEdit = _WinAPI_GetWindowRect($hEdit)
    Return _WinAPI_PtInRect($tEdit, $tMouse)
EndFunc

Du solltest aber noch zusätzlich prüfen, ob der Cursor beim Klick in der Combo steht. Das darfst du erst mal selbst probieren. Wenn es nicht klappt, melde dich wieder.

EDIT: Ich hatte gerade Lust, da habe ich es erledigt.

@hipfzwirgel ??? - Was bitte soll uns dieses Zitat sagen???

Edit Raupi: Nix soll der sagen, deshalb hab ich ihn auch gelöscht

Zitat von Bitnugger

Zudem sollte der ToolTip auch verschwinden, wenn man das Caret nach rechts/links bewegt.

Wenn die Maus bewegt wird oder eine beliebige Taste gedrückt wird, verschwindet der Tip.

Diese Events werte ich im Skript aus. OHK basiert aber auch auf Auswertung des OnKey-Events. Somit wird beim Aufruf über OHK das Skript ausgeführt (Position und Länge des Calltips sind korrekt), aber die Einstellungen des Calltips werden gleichzeitig zurückgesetzt auf Default (weiß), weil das Event auch genutzt wird um das Verschwinden des Calltip (besser gesagt den Auslöser dafür) zu erkennen.

Neil hat empfohlen, mit OnTimer oder OnIdle und der Prüfung auf SCI_CALLTIPACTIVE das Verschwinden des Calltip zu erkennen. Da werde ich mich mal dran probieren.

Ich habe in v0.9 die Auswertemöglichkeit von "$variable = eine_funktion()" wieder entfernt. Das behinderte doch mehr als es nutzte. Dadurch konnten deine Zuweisungen

Global $g_ispBlue = 0x268bd2 ; 4/4 blue 33 #0087ff 55 -10 -45 38 139 210 205 82 82

nicht erkannt werden.

Jetzt wird ausschliesslich nach "$variable = 0xABC123" in den Zeilen gesucht. Hinter dem Hex-Wert wird dann abgeschnitten.

OK, habe noch einen Fehler gefunden und beseitigt. Zusätzlich ist am Skriptanfang eine Variable "bDEBUG". Bei Problemen mal auf "true" setzen, dann wird der ganze Ablauf in die Konsole protokolliert.

Aber warum beim Aufruf aus OHK der Farbwert vom Calltip nicht angenommen wird, weiß ich noch nicht. Korrekt abgearbeitet wird das Skript. Ich werde das Problem mal vereinzeln und im SciTE-Forum nachfragen.

Neue Version v0.9

EDIT

Habe jetzt die Ursache für die Anzeige in weiß gefunden:

Ich prüfe bei Mausbewegung (Event OnDwellStart) oder Tastatureingabe (Event OnKey) ob colortip_show true ist (das setze ich, wenn der Calltip gezeigt wird) und diese Ereignisse beenden die Anzeige des Calltip. Deshalb setze ich die Werte zurück auf Standard (Farbe: weiß).

Während beim Aufruf des Skriptes aus Eintrag in SciTEUser.properties (command) dieses Ereignis abgewartet wird, wird bei Aufruf aus OHK sofort Default wieder hergestellt, obwohl die Anzeige noch besteht.

Wenn man also die Region "region EventClass" auskommentiert, funktioniert das Skript, wie erwartet. Nachteil: der zuletzt verwendete Farbwert für den Hintergrund wird dann auch für die SciTE-internen Calltips verwendet.

Habe deine angehängte Datei erst jetzt gesehen. Ich schaue mir das mal näher an.

Zitat von Bitnugger

Bestimmt weil ich die Variablen vorab in Zeile 18 deklariert habe... und du dann den Wert in dieser Zeile suchst... den du da aber nicht findest

Das ist völlig egal, wo die Variable deklariert wird. Bei der Zuweisungssuche lese ich die gesamte Datei ein.

Füge mal in die Funktion FromCursor eine Debugzeile ein. Du wirst sehen, dass die Farbe gefunden und korrekt ausgegeben wird

....

        if beginPos ~= endPos then
            if endPos - beginPos > iLen then
                editor:SetSelection(beginPos + iLen, beginPos)
            elseif endPos - beginPos == iLen then
                editor:SetSelection(endPos, beginPos)
            else
                return
            end
            local R,G,B = tostring(editor:GetSelText()):match('('..self.pattHex2..')('..self.pattHex2..')('..self.pattHex2..')$')
print('DEBUG_RGB',R,G,B)
            scite.SendEditor(SCI_CALLTIPSHOW, beginPos+1, (' '):rep(iLen-1))
            scite.SendEditor(SCI_CALLTIPSETHLT, 0, iLen-1)
            scite.SendEditor(SCI_CALLTIPSETPOSITION, true)
            if _fBGR == true then
                scite.SendEditor(SCI_CALLTIPSETBACK, tonumber(string.format('0x%s%s%s', R,G,B)))
            else
                scite.SendEditor(SCI_CALLTIPSETBACK, tonumber(string.format('0x%s%s%s', B,G,R)))
            end
            self.colortip_show = true
        end
....

Aus einem mir unerfindlichen Grund nimmt scite.SendEditor(SCI_CALLTIPSETBACK, den Farbwert nicht entgegen.

Das ist ja paradox. Alle Calltip-Funktionen werden korrekt ausgeführt, außer der Farbsetzung.

OK: scite.SendEditor(SCI_CALLTIPSHOW, beginPos+1, (' '):rep(iLen-1))

OK: scite.SendEditor(SCI_CALLTIPSETPOSITION, true)

FAIL: scite.SendEditor(SCI_CALLTIPSETBACK, tonumber(string.format('0x%s%s%s', R,G,B)))

Die Werte werden korrekt ausgelesen und an die Funktion übergeben, alles wie gewünscht. Ich habe im Moment keine Ahnung, warum die Farbe sich nicht setzen lässt.

Ich grübele mal ausgiebig.

Mal noch ein Hinweis zur Aufbewahrung:

Das Erstellen von Rechnungen mit Word/Excel-Vorlagen ist OK, wenn daraus eine Papierrechnung resultiert, die aufbewahrt wird. Wird zusätzlich eine *.xls/*doc-Datei dieser Rechnung gespeichert ohne ein Dokumentenmanagementsystem zu verwenden, ist dies eine Ordnungswidrigkeit, da die Unveränderlichkeit des (digitalen) Beleges nicht gegeben ist. (s. hier)

PDF-Dateien sind aber auch nicht manipulationssicher und ein reines Abspeichern ist keine zulässige Aufbewahrung. (s. hier)

Es gibt also zwei Möglichkeiten der Aufbewahrung:

- nur Papier (die Datenbank in einem Warenwirtschaftssystem ist gut zum Nachschauen, gilt aber nicht als Aufbewahrung)

- digital mit einem DMS (wir verwenden ein System bei dem eine Einzelplatzlizenz etwa 300 EUR kostet), dann ist der Papierbeleg kpl. verzichtbar

Ich würde trotzdem von Anfang an auf digitale Sicherung setzen. Es hat auch den Vorteil (je nach DMS) den Rechnungen Scans von Begleitpapieren jeder Art anzuhängen. So hat man in der Archivierung auch immer den gesamten Ablauf (Anfrage-Angebot-Auftrag-Lieferschein-Rechnung-etc.) auf einen Blick zur Verfügung.