It worked on UEZ avatar also, 45 confidence.
You are mistaken because the confidence value is printed behind "confidence" itself.
Since your inserted image is too small, it was printed out of bounds and is therefore not visible.
The value "45" is corresponding to the angle the face has.
Try with a bigger image and see four yourself 
Hier mal etwas was mich besonders genervt hat, vielleicht kann es ja jemand gebrauchen:
Wie kann man die Konsolenausgabe während der Ausführung mitscrollen lassen und nach dem Beenden des Programms das Ende der Konsolenausgabe anzeigen?
Dazu einfach in die SciTEGlobal.properties gehen welche sich in C:\Program Files (x86\AutoIt\SciTE\ (bzw. im Installationspfad von AutoIt) befindet.
Solltet ihr SciTE nicht für AutoIt explizit nutzen schaut im Startpost den Properties-FAQ-Post an.
Den Kommentar in Zeile 32 #output.scroll=0 mit output.scroll=2 ersetzen, oder einfach in die Zeile dadrunter schreiben, spielt keine Rolle.
Es gibt insgesamt drei Optionen:
Soweit ich das beurteilen kann scheint es doch zu funktionieren?
Du kriegst ein Dll Handle zurück. die "00F5801A" ist dein cout und die 0 dahinter (es ist schlecht formatiert) dein @error-code welcher fehlerfrei ist.
Jetzt musst du deine ProcessVREvents noch mit Code füttern statt nur dem Handle in die Konsole zu schreiben.
Der DllCall-Fehlercode schaut sehr schleierhaft aus. Hast du mit dem DllOpen deine selbstkompilierte DLL geöffnet oder die OpenVR? (Ich habs nächträglich noch mit _Helper.dll) angepasst.
Ist deine Dll 32- oder 64-Bit?
Bitte post deinen ganzen Code (der ist so nicht lauffähig, $hDLL ist nicht declared) Code das nächste mal in einem Codeblock (</> Zeichen im Editor) damit das schöner formatiert ist.
Dein DllCall benötigt noch die Anweisung, dass es sich hierbei um c-declared und nicht um std DllCalls handelt. Probier mal folgendes und poste die Konsolenausgabe bitte:
$hDll = DllOpen("OpenVR_Helper.dll")
ConsoleWrite("DllOpen Handle = " & $hDll)
$aReturn = DllCall($hDLL, "ptr:cdecl", "init_OpenVR")
ConsoleWrite("init_OpenVr - @error=" & @error)
DllCall($hDLL, "none:cdecl", "ProcessVREvents", "ptr", $aReturn[0])
ConsoleWRite("ProcessVREvents - @error=" & @error)Leider sind all unsere Glaskugeln beim letzten Thread der keinen Code gepostet hatte schon verbraucht worden.
Bitte merk dir fürs nächste Mal:
Poste eine Verlinkung zur Dokumentation der DLL die du zu callen versuchst.
Lade ein Skriptbeispiel mit DLL hoch welches deinen Fehler reproduziert und beschreibe deinen Fehler.
Dann können wir dir auch weiterhelfen.
Na klar gibts die, die BigNum-UDF wäre da die richtige UDF dafür. Aber Vorsicht, es gibt einige Beschränkungen, diese kannst du den Funktionsdefinitionen entnehmen.
https://www.autoitscript.com/forum/topic/83529-bignum-udf/
#include "BigNum.au3"
$e = "2.718189498"
Local $input = "36"
$wert = _BigNum_Div("1", _BigNum_Add("1", _BigNum_Div("1", _BigNum_Pow($e, $input))))
ConsoleWrite("Ergebnis: " & $wert & @CRLF)
;Ergebnis: 0.999999999999999767763908998206514770589513530113802979409804181020248936134136150420526303242148127315226216464845499874868416583789909672114002122934739687223769156313358444743820418206106983353358522680862119209076330932385884686472575940159279311702609756597725480811850725893669905236966908396033748642715861136371126721971523033617528212911Ich bin grad am generalisieren bzw. "UDF" machen der Funktion und leider klappt das ganze nicht so wie ich es vorhatte.
Ursprünglich wollte ich einfach die Schriftarten auslesen und die Werte anpassen, aber der bereits angesprochene Rundungsfehler macht alles kaputt.
Wenn die GUI-Größe nun so gewählt ist, dass sie sich nicht durch 1.5 teilen lässt, verschwinden Buttons einfach wenn man die GUI oft genug über den Rand hinaus zieht.
Ich werde also die Controlgrößen auch einspeichern müssen und diese dann manuell setzen. Es wird dann immer von der 100% Variante resized.
Vorgehen: Fenster spawnt auf 100%. Ziehe auf 150. Skaliere GUI auf 100%, setze alle Controlgrößen wie bei 100%. Skaliere GUI auf 150% mit $GUI_DOCKAUTO.
Zieht man das Fenster nun von 150% auf 200%. Skaliere GUI auf 100%, setze Controlgrößen wie bei 100%. Skaliere GUI auf 200% mit $GUI_DOCKAUTO.
Ich hoffe ich krieg das heute noch hin, hab mich gestern abend ne gute Stunde damit aufgehalten herauszufinden warum eine ListViewSpalte sich unbedingt resizen muss wenn ein neues Element hinzugefügt wird.
Ich dachte ich könnte in Ruhe frühstücken aber wenn UEZ hier so einen Druck macht 
Aufgeräumt und einigermaßen dokumentiert findet ihr es im Anhang.
Das Skript ist nur ab Win 8.1 / 10 lauffähig, da Windows 7 keine Per-Monitor-DPI Scaling hat.
Die Schriftarten muss ich nicht explizit alle setzen (also Schriftart, -größe, -stil) sondern das wird alles automatisch ausgelesen und gesetzt.
Das einzige Problem was im Moment besteht ist von einem 150% Monitor auf 100% und wieder zurückzukommen, da die Werte gerundet werden.
Startet die Schrift mit der Größe 16 wird sie auf 10.666667 skaliert. Das wird aber dann auf 10 abgeschnitten, und skaliert man zurück sinds nur noch 15.
Das Beispiel verwendet Round statt Int, also wird das hier nicht passieren, aber bei anderen Werten schon.
Ich werd bei meiner _GUI_SetResizing-Funktion einfach nach dem erstellen alle Werte intern speichern, damit immer vom Standardwert aus skaliert werden kann und nicht vom ausgelesenen Wert.
Wäre dieser ein float statt long, wäre das kein Problem, ist leider nicht so 
Zum Testen einfach über die Display ränder hinaus ziehen.
ACHTUNG! Das Skript geht davon aus, dass Monitor 1 der ist auf dem das Fenster spawnt. Das wird natürlich in der finalen Version nicht so bleiben, sondern ist erstmal Mittel zum Zweck.
Später wird das natürlich automatisch ausgelesen.
Das Deregistrieren der Nachrichten ist dazu da, um nicht die GUI tausendfach neuskalieren zu lassen, sollte die Größe so variieren, dass die Nachricht direkt nochmal abgefeuert wird.
Das passiert in dem angehängten Beispiel nicht, war aber bei meiner anderen GUI der Fall. Das werde ich auch noch genauer untersuchen.
Schön, das mit den Koordinaten zu berechnen aber MouseClicks sind immer so eine Sache für sich, also mit Vorsicht genießen.
Falls der ganze Inhalt im iframe liegt kann man auch übrigens einfach auf das src-Attribut davon navigieren und anschließend all seine Befehle absetzen.
Kurzer Zwischenbericht:
Per-Monitor-DPI-Scaling ist soweit implementiert aber ganz zufrieden bin ich damit noch nicht.
Das Fenster wird automatisch resized sobald es auf einen Monitor mit unterschiedlicher DPI wechselt und die Schriftgrößen werden ebenfalls automatisch angepasst.
D.h. man hat am Ende eine gestochen scharfe GUI auf jedem Monitor, unabhängig davon auf welcher DPI das Programm gestartet ist oder nicht.
Es fehlt nur noch Kleinigkeiten und sobald ich das ganze implementiert habe werde ich hier ein Beispielskript posten, mein Skript ist leider viel zu unaufgeräumt um da durchsteigen zu können.
Damit ich die Fehler diagnostizieren kann bräuchte ich solch ein "script".
Ihr konzipiert ein Spiel, d.h. ich gehe davon aus, dass ihr es programmiert.
Wozu braucht ihr ein Diagnoseskript wenn ihr Zugang zum Quellcode habt? Das ist doch bescheuert.
Zeig uns doch mal Screenshots von dem was du machen möchtest, wir können dir nicht helfen wenn du uns nicht hilfst.
Von welchem Programm redest du denn?
Nun, dafür musst du uns erstmal sagen was du genau wo machen möchtest.
Deine Beschreibung ist ziemlich ambivalent und lässt sich auf tausende von Anwendungsmöglichkeiten ummünzen.
Beschreib uns einfach mal dein Anwendungsfall konkret und wir schauen ob wir dir da unter die Arme greifen können.
Ja, das ist möglich.
So, hab Windows 10 kurzerhand auf dem Zweitrechner installiert und das einzige was meinem Skript gefehlt hatte war SetProcessDPIAware.
Das verhindert, dass die GUI einfach hochskaliert wird mit Informationsverlust (als ob man ein 200x200px Bild auf 800x800px zieht).
Mit meinem Verfahren danach kann ich problemlos hochskalieren und habe keine Unschärfe, sondern alles skaliert so wie es soll.
Per-Monitor-DPI hab ich mir noch nicht angeschaut, dafür muss ich erstmal einen alten Bildschirm vom Dachboden runter holen.
Aber ich denke das bekomme ich auch hin.
Kanashius ich liebäugle auch schon mit dem Ryzen und einer neuer GPU (besonders interessant ist die RX 5700 XT) damit ich meinen Zweitrechner (i7 960/abgerauchte 660 Ti) durch meinen i7 4790/970 OC austauschen kann.
Ich bin grad dabei Windows 10 auf meinen Zweitrechner zu installieren, ich schau mir das "gleich" mal selbst richtig an.
Achso du hast verschiedene DPIs auf den Monitoren? Ja das erklärt wohl einiges. Es wird nur die AppliedDPI von den Metrics in der Registry gelesen. Per-Monitor-DPI ist noch nicht implementiert.
Ich vermute stark, es es daran liegen wird. Ich werd mir das mit dem DPIAwareness nochmal genauer ansehen. (Ich glaub Windows7 hat per-monitor-dpi nicht oder?)
Kannst du mal Screenshots davon posten?
Genau, so sollte es aussehen. Wenn der Monitor z.B. auf 125% gestellt wurde, sollte die GUI auf dem Monitor genauso aussehen, wie bei 100%. Ohne die Funktion wird die GUI größer und unschärfer.
Moment, steh ich grad auf dem Schlauch?
Wieso soll die GUI so aussehen wie bei 100%? Wozu stelle ich denn die DPI überhaupt auf 125%, 150%, 200%?
Ich setz die DPI doch absichtlich hoch, damit die Texte größer werden und einfacher zu lesen sind.
Mit der Funktion die du gepostet hast anti-scale ich doch alles, wo ist denn der Sinn dahinter?
Ich bin der Meinung, wenn ich sage DPI = 200% soll alles um 200% größer gemacht werden. Windows scheint auch der Meinung zu sein, sonst würden die Buttons und Labels ja nicht alle größer werden.
"Meine Methode" macht ja genau das, das Fenster wird so skaliert als ob alles 200% größer wäre und es bleibt bombastisch scharf.
Oder sieht das ganze auf Windows 10 anders aus? Ich hab leider nur Win7.
