Aber wo nimmst Du den her?
Ich bin mal so frei:
Der weiche Zeilenumbruch wird mit GUICtrlSendMsg($idEdit, $EM_FMTLINES, True, 0 ) für das Control aktiviert. D.h. Umbrüche durch Word wrapping werden damit markiert anstatt mit CRLF
(https://msdn.microsoft.com/en-us/library/…0(v=vs.85).aspx).
Ich würde auf die Schnelle die Zwwischenablage so aktualisieren: ClipPut( StringReplace(ClipGet(), @CRLF, '') )
[OT]
Kann es sein, dass deutsch nicht deine Muttersprache ist? Deine Texte wirken wie vom Google Translator erstellt.
[/OT]
bringt nicht.
Eine Fehlerbeschreibung, die unwahrscheinlich aussagekräftig ist. [/Ironie]
wird aber unformatiert eingetragen.
Woher soll Excel wissen, dass du Formatierungen wünschst? Daten eintragen und Daten formatieren sind zwei unterschiedliche Paar Schuh.
Mit .NumberFormat kannst du Zellen/Spalten ein gewünschtes Format zuweisen.
Zeit A oder B brauchst du nicht. Nimm nur eine Spalte Zeit. Ist zu einem Zeitpunkt ein Wert für A, trägst du ihn dort ein, und/oder ist ein Wert für B, trägst du ihn dort ein. Dann hast du eine fortlaufende Zeit und zugehörige Werte in A und/oder B.
Ich habe den Eindruck, dass sie GUI-Events sich (warum auch immer) mit dem Programm nicht vertragen. 
Erklärung dafür habe ich bis jetzt keine. Also weiter suchen.
Ich habe jetzt eine Lösung, die alle (bisher bekannten) Macken fixen sollte. Den Dummy habe ich rausgeworfen, dafür gibt es $WM_COMMAND zum Auswerten. Damit die Zeitverzögerung beim Mausklick eleminiert werden kann, habe ich die Maus gehookt und Events für Klick links/rechts auf das Ctrl eingebaut.
Probiere mal, ob du da noch Fehler entdecken kannst.
Ich schaue mir derweil mal deinen Code an.
P.S. Habe deine Variante gerade ausgeführt - das Dummyproblem lässt sich damit auch nicht beheben. Finde diese Dummy-Lösungen eigentlich recht elegant, da man einfach nur eine ID abfragen muss. Warum die Funktion in diesem Kontext aussteigt, ist mir nicht plausibel. Ich werde bei Gelegenheit mal probieren, das Problem auf Minimalcode runterzubrechen, vielleicht findet man dann die Ursache (oder einen Bug).
Du prüfst in deinen Funktionen nicht, ob ein gültiges Window-Handle übergeben wurde... was z. B. dazu führt, dass nachdem $hBusy7 (in deinem Example) durch mein hinzugefügtes Event (s. w. unten) geschlossen wurde, durch einen Klick auf den Button $bt4 zwei neue BusyCtrl's erzeugt werden.
Ha-Ha, da habe ich mir ja ein Ei gelegt. Manchmal scheitert man an der eigenen Logik. Um die Überprüfung schlank zu halten, war mein Gedanke: Index vorbelegen mit "-1" und als hWnd "Null" übergeben um Neuerstellung zu bewirken, denn hWnd "Null" gibt es nicht also bleibt Index -1 == Neu. Dass der Index auch -1 bleibt, wenn ich ein falsches Fenster übergebe und somit auch Neu ausgelöst wird, kam mir irgendwie nicht in den Sinn 
. Da werde ich etwas umbauen.
Icons auch aus 'exe' und 'icl' extrahieren...
Hier solltest du den Pointer für Large Icons setzen...
Danke für die Hinweise, werde ich übernehmen.
Ist es "normal", dass ich die Maustaste ca. 1 Sekunde lang drücken, damit dieses Event ausgelöst wird?
Ich könnte ja sagen, es ist ein Feature, aber tatsächlich habe ich adhoc keine Erklärung. Das werde ich mal genauer unter die Lupe nehmen.
Nochmals Danke fürs Testen. Ist schon komisch, dass man bei eigenen Werken eine Art Betriebsblindheit hat und bei Fremdprodukten auf einen Blick die Schwachstellen sieht. Das ist halt auch das Gute am Forum, der Blick aus einem anderen Winkel.
EDIT:
Mir ist gerade noch etwas aufgefallen. Nach Auslösen des Events $GUI_EVENT_PRIMARYDOWN (also Aufruf von _GuiCtrlBusy_Close) funktioniert mein Dummy nicht mehr, das heißt ab diesem Zeitpunkt schlägt das Senden der Closed-Msg fehl (GUICtrlSendToDummy wird ausgeführt, gibt aber 0 zurück = Fehler). (neue Baustelle)
Das ist dann gültig für alle noch existierenden Ctrl. - Kannst du das verifizieren?
EDIT-2:
Das macht mich konfus. Mit _GuiCtrlBusy_Close wird im Parameterarray des Ctrl der Wert [$__gbBrake] auf True gesetzt. Im Callback prüft ein If-Statement ob dieser Wert True ist oder die Zeit abgelaufen ist. Bei abgelaufener Zeit funktioniert der Closed-Dummy, bei Setzen von True für [$__gbBrake] aber nicht, obwohl beide Abfragen im selben Statement sind!
; brake by script OR timeout/safety timeout ended
If $gaGCB_CTRL[$idxCtrl][$__gbBreak] Or _
$iTime - $gaGCB_CTRL[$idxCtrl][$__giTimestamp] >= ($gaGCB_CTRL[$idxCtrl][$__giTimeOut] = 0 ? $GCB_U_TIMEOUT_ZERO : $gaGCB_CTRL[$idxCtrl][$__giTimeOut])*1000 ThenJetzt wollte ich tricksen und statt [$__gbBrake] = True, einen Fantasie Timestamp und Timeout setzen, sodass dieser Abfragezweig zum Beenden des Ctrl führt. Das klappt auch, aber auch mit dem Effekt, dass der Dummy nicht mehr angesprochen werden kann.
Ich habe dafür keine Erklärung. Das entzieht sich meinem Verständnis.
Vielleicht hat jemand eine zündende Idee?
EDIT-3:
Manchmal bleiben nur Umwege. Ich habe versucht GUICtrlSendToDummy auszulagern, aber der Fehler trat immer weiter auf.
Jetzt werde ich wieder auf die anfangs verwendete Variante mit _SendMessage zurückgreifen. Im ersten Versuch gab es damals ein Problem, dass beim letzten Ctrl, dessen Closed-Msg 'verloren' ging. Ich nehme jetzt ein unsichtbares Fenster zum Aufnehmen der Closed-Msg. (wird mit _GuiCtrlBusy_GetClosed erstellt). Außerdem puffere ich die Nachrichten intern, sodass keine Nachricht verloren gehen kann. - Das ist erstmal der Plan.
Bleibt nur noch das Problem, der Zeitverzögerung beim Auslösen des Event. Da habe ich noch keinen Lösungsansatz.
Finale Version v1.0 im Startpost
NEU
- für jedes Ctrl eigenes Callback Intervall möglich
- Ansicht des Ctrl kann zur Laufzeit geändert werden (nur Titel / Titel+Uhrzeit/Titel+Countdown)
- Countdown (Timeout) ist mit jeder Ansicht verwendbar, Restlaufzeit über Platzhalter im Text anzeigbar
- Icon aus allen *.dll und *.ico verwendbar
Ist ja krass, das Ticket wurde geschlossen - kein Bug (sondern Duplikat, Problem seit 3 Jahren bekannt und ignoriert)!
It calls the function the first time to see what element of the array to set it to, then when AutoIt does the actual declaration for the element it calls it again to see where it's going.
Sorry, aber das ist gequirlte Kacke! Dann sollte das Problem ja nicht auftreten, wenn man den Ausdruck so darstellt: ....$aArr[ ( _function() ) ]
Das würde erzwingen, dass erst der Ausdruck in der runden Klammer aufgelöst wird und NUR dieser an die eckige Klammer ausgegeben wird. Aber auch in diesem Fall wird die Funktion doppelt ausgeführt.
Aber das bestätigt nur die bisherigen Erfahrungen mit Bug-Meldungen im EN-Forum: Wie kann ein User sich erdreisten, das Machwerk der Götter in Frage zu stellen!? 
EDIT:
Es ist ja gar nicht so weit hergeholt, dass man den Index für die Arrayadressierung mit einer Funktion bestimmen läßt. Und dass der Funktionsaufruf (dessen Return ja der Index ist) direkt in die Zuweisung eingesetzt wird ist auch nicht exotisch.
Wollte man jetzt diese Art der Adressierung trotz des Bugs vornehmen, muss man die Funktion mit dem Index-Return manipulieren:
#include <array.au3>
Global $aArr[20]
For $i = 1 To 5
$aArr[_GetNextIndex()] = $i
Next
_ArrayDisplay($aArr)
; eigentlich soll _GetNextIndex() nur den nächsten freien Index aus der Liste zurückgeben
; das führt aber zu dem Doppler-Fehler schon beim Zugriff auf das Index-Array
;~ Func _GetNextIndex()
;~ Local Static $aFreeIndices[] = [6,12,14,17,19]
;~ Local Static $iNextFreeIndex = -1
;~ $iNextFreeIndex += 1
;~ Return $aFreeIndices[$iNextFreeIndex]
;~ EndFunc
;~ ; mit dieser "Krücke" geht es dann
Func _GetNextIndex()
Local Static $aFreeIndices[] = [6,12,14,17,19]
Local Static $iNextFreeIndex = -1
Local Static $iCall = 1
If $iCall = 2 Then
; $iNextFreeIndex = $iNextFreeIndex
$iCall = 1
Else
$iNextFreeIndex += 1
$iCall = 2
EndIf
Return $aFreeIndices[$iNextFreeIndex]
EndFuncDas hat schon ein bischen was Perverses.
Es bleibt also nur, Wert vorher in eine Variable übernehmen und dann zuweisen.
Das Problem entsteht innerhalb der Arrayzuweisung. Wird die Funktion dort ausgeführt ist dieses Phänomen sichtbar.
Fangen wir aber .Pop() in einer Variablen auf und adressieren das Array damit, stimmt es.
#include<Array.au3>
Global $aArray[10]
Global $oStack = ObjCreate("System.Collections.Stack")
$oStack.Push(0)
$oStack.Push(1)
$oStack.Push(2)
;~ $aArray[$oStack.Pop()] = "test"
$iPop = $oStack.Pop()
$aArray[$iPop] = "test"
;( .Pop gibt den zuletzt gespeicherten Wert aus, dieser wird dann gelöscht und es kann auf den nächsten wert zugegriffen werden. Siehe https://autoit.de/index.php?thread/3407-alternativen-zum-array/)
_ArrayDisplay($aArray)Neue Version 0.11 in Post #1
Verwendung von Icon möglich (aus shell32.dll oder *.ico-Datei)
aber gibt es nicht vielleicht eine Möglichkeit die Maustaste als Hotkey zu deklarieren?
Nein, die gibt es nicht. Mit HotKeySet kannst du nur Tasten belegen.
Was die Funktion HotKeySet selbst betrifft, hat alpines völlig recht. Aber es gibt schon Möglichkeiten, auf Mausaktionen zu reagieren und dabei die eigentliche Mausaktion zu verwerfen. Sowas muss man dann an ein Fenster koppeln um sich nicht sein System lahm zu legen.
Hier ein nicht kpl. Bsp., es sind keine Aktionen definiert, kein Aktionsfenster festgelegt. Aber wenn du keinen Plan hast, was dort passiert, lass lieber die Finger von.
#cs WICHTIG!!!
In der Funktion "_MouseProcedure" darf nicht verweilt werden, d.h. MsgBox oder _ArrayDisplay sind absolut tabu!
Auch dürfen keine zeitintensiven Funktionen aufgerufen werden. Andere Aktionen über Globale Variablen oder AdlibRegister starten.
Die Funktion darf niemals mit einfachem Return verlassen werden, sondern ausschliesslich mit "Return _WinAPI_CallNextHookEx".
Es ist zwingend ein Aktionsfenster zuzuordnen, keinesfalls darf das Skript systemweit verwendet werden.
Überlege gründlich, welche Mausaktion genutzt werden soll, denn diese geht für das System verloren (innerhalb des Aktionsfensters)
und wird ausschliesslich von diesem Skript genutzt.
#ce
#include <WinAPI.au3>
#include <WindowsConstants.au3>
OnAutoItExitRegister('OnAutoItExit')
HotKeySet('^+q', '_Exit') ; Strg+Shift+Q -- nur um dieses Bsp. beenden zu können
Global Const $HC_ACTION = 0
Global $hStub_MouseProc = DllCallbackRegister("_MouseProcedure", "long", "int;wparam;lparam")
Global $hmod = _WinAPI_GetModuleHandle(0)
Global $hHook = _WinAPI_SetWindowsHookEx($WH_MOUSE_LL, DllCallbackGetPtr($hStub_MouseProc), $hmod)
Global $sTitleActionWindow = 'Der Titel des Fensters, in dem der Maus-Hotkey gültig sein soll'
While True
Sleep(50)
WEnd
Func _MouseProcedure($nCode, $wParam, $lParam)
If $nCode < 0 Then Return _WinAPI_CallNextHookEx($hHook, $nCode, $wParam, $lParam)
If WinGetTitle('[ACTIVE]') <> $sTitleActionWindow Then Return _WinAPI_CallNextHookEx($hHook, $nCode, $wParam, $lParam)
Local $info = DllStructCreate("int X;int Y;dword mouseData;dword flags;dword time;ulong_ptr dwExtraInfo", $lParam)
Local $iX = DllStructGetData($info, 1)
Local $iY = DllStructGetData($info, 2)
Local $mouseData = DllStructGetData($info, 3)
; Hier wäre noch sinnvoll zu prüfen, ob $iX und $iY innerhalb des Aktionsfensters sind
; --> wenn nicht: Return _WinAPI_CallNextHookEx($hHook, $nCode, $wParam, $lParam)
If $nCode = $HC_ACTION Then
Switch $wParam
Case $WM_MOUSEMOVE
; Reagieren auf Mausbewegung (sollte man nicht verwenden, dann bleibt die Maus auf der Stelle stehen!)
Case $WM_MOUSEWHEEL
If _WinAPI_HiWord($mouseData) > 0 Then
; Reagieren auf Mausrad vorwärts
Else
; Reagieren auf Mausrad rückwärts
EndIf
Case $WM_LBUTTONDOWN
; Reagieren auf linken Mausbutton drücken
Case $WM_LBUTTONUP
; Reagieren auf linken Mausbutton lösen
Case $WM_RBUTTONDOWN
; Reagieren auf rechten Mausbutton drücken
Case $WM_RBUTTONUP
; Reagieren auf rechten Mausbutton lösen
Case $WM_MBUTTONDOWN
; Reagieren auf mittleren Mausbutton drücken (Mausrad)
Case $WM_MBUTTONUP
; Reagieren auf mittleren Mausbutton lösen (Mausrad)
EndSwitch
EndIf
Return _WinAPI_CallNextHookEx($hHook, $nCode, $wParam, $lParam)
EndFunc
Func _Exit()
Exit
EndFunc
Func OnAutoItExit()
_WinAPI_UnhookWindowsHookEx($hHook)
DllCallbackFree($hStub_MouseProc)
EndFunc ;==>OnAutoItExitIch habe willkürlich ein paar Schriftarten getestet, das Ergebniss von FontGetHeight schien eigentlich immer zu stimmen.
Danke, dann werde ich mir als nächstes meine Measurement-Funktion nochmal vornehmen.
Scheint nur bei $_iTimeCounter = 2 so extrem aufzutreten.
DANKE, das war der goldene Hinweis. Habe die entsprechende Abfrage zum Neuzeichnen angepasst und schon geht die CPU-Last auf < 10.
Ich stelle Version v0.10 in Post #1 ein.
Gibt es dafür nicht _GDIPlus_FontGetHeight?
Da ich den formatierten Text ausmesse mit _GDIPlus_GraphicsMeasureString sollte das eigentlich dieselben Werte zurück geben. Aber die Werte sind für WinAPI-Funktionen unbrauchbar. Mit dem Faktor kann ich das zumindest ausgleichen, indem ich vor dem Messen die logische Größe damit multipliziere. Bei exotischen Fonts (z.B. Deja Vu) geht das aber daneben.
Falls du also eine Methode findest, wie man die Schriftgrößen für
- native AutoIt Funktionen
- GDI Funktionen
- WinAPI Funktion
hin- und her verrechnen kann, wäre das sehr hilfreich.
Übrigens, für die Zukunft: Wenn eine Frage geklärt ist, bitte
- Startpost --> Thema bearbeiten --> Als erledigt markieren
Ich habe es mal für dich gemacht.
Änderungen/Neuerungen Version 0.9, s. Post #1
$Ergebnis = Round( Deine_Rechnung, 2)
Edit: OK, du hast es bemerkt als ich gerade schrieb.
