Beiträge von Oscar

    Dann werde ich mal Fritzing anschmeissen und eine Schaltung modellieren.

    Noch kurz ein Hinweis (falls Du es nicht bereits weisst):

    Alle Arduinos/ESPs besitzen intern, per Software zuschaltbare, Pullup-Widerstände. Deswegen beim planen der Schaltung immer alle Schalter/Taster nach Masse (GND) schalten.

    Das spart die externe Beschaltung und erleichtert das zeichnen des Schaltplans. :)

    Aber Oskar wird dazu sicherlich seinen Senf auch noch dazugeben

    Naja, das bleibt ja nicht aus. :)

    Ich stimme Dir voll zu! Ich würde auch zu ESP8266 und somit WLAN greifen. Das ist deutlich einfacher und mit weniger Hardware zu realisieren, als einen Nano ins WLAN zu bringen oder gar eine 440/880 MHz Funkverbindung (stark störanfällig) zu versuchen.

    Witzigerweise sind momentan die Nano-Clones sogar teurer als die Wemos D1 mini (mit ESP8266).


    Ob es gleich SmartHome sein muss?


    Ich würde es selbst programmieren (in C Arduino-IDE).

    Man könnte da einen Wemos als Master (HTTP-Webserver) einsetzen, der die Relais schaltet (welche Spannung liegt da an?) und dann mehrere Wemos als Slave (Webclient).

    Dann kannst Du außerdem sogar vom Rechner und/oder Smartphone (solange sie im gleichen Netz sind) die Relais steuern.

    Und zusätzlich Feuchtesensoren an die Wemos anschliessen ist auch kein Problem.

    Hättest du da evtl ne Idee für mich woran das liegt bzw wie ich das zum Laufen bekomme?

    Hast Du schonmal nachgesehen, ob die Übertragungsparameter korrekt sind?

    Im Sketch verwendest Du "9600 Baud, 8N1". Wenn Du das nicht im AutoIt-Script einstellst, musst Du im Gerätemanager von Windows nachsehen.

    Aber mit WindowsXP habe ich schon seit Jahren nichts mehr am Hut. Warum so ein altes System?

    Wenn ich die Funktion "_5A()" so ändere, dann ist sie in beiden Fällen die jeweils schnellste:


    Edit:

    Und so ist die Funktion noch ein Tick schneller:

    Da man ja nie weiß, was der Anwender für eine Auflösung fährt, ist das Implementieren von mehreren Bildern entsprechender Größe ja nicht wirklich elegant...

    Du musst das Bild in der höchsten, von Deinem Programm unterstützten, Auflösung mitliefern und dann entsprechend der skalierten Bildgröße das Bild runterskalieren (mit GDI+) und in das Pic-Control einfügen.

    Beim runterskalieren musst Du das Seitenverhältnis des Bildes beibehalten (bei z.B. 300x200 Px muss das kleinere Bild auch das 3 zu 2 Verhältnis haben).

    Auf was könnte man da ausweichen und wo finde ich Information über die Pinbelegung? Was ist sinnvoll?

    Wenn Du möglichst wenig löten willst, nimm einen Wemos D1 mini (der hat einen ESP8266-Prozessor).

    So ein Wemos kostet nur 4,50€ bei Amazon:

    NodeMcu WiFi Entwicklungsboard mit ESP8266 Chip ESP-12F 4MB Byte Modul Kompatibel mit Arduino
    NodeMcu WiFi Entwicklungsboard mit ESP8266 Chip ESP-12F 4MB Byte Modul Kompatibel mit Arduino
    www.amazon.de

    oder 4,80€ bei Reichelt:

    https://www.reichelt.de/d1-mini-esp8266-v2-0-d1-mini-p253978.html?&trstct=pos_1&nbc=1


    Der ist zwar für diese Aufgabe totaler Overkill, aber trotzdem viel günstiger, als so fertige Karten.

    Das Programm für den Wemos kann ich Dir schreiben, das ist kein Problem.

    Ich suche noch eine alte Grafikkarte, um einen ebenso alten Rechner etwas aufzurüsten.

    Voraussetzungen:

    - Funktioniert noch

    - PCIexpress (x16)

    - schmal und kurz (keine über 2 Slots und/oder überlang)

    - max. 25W Leistung

    - DVI- und/oder HDMI-Anschluss


    Es gab damals so 256 oder 512 MB Karten, die diese Bedingungen erfüllten. Leider habe ich keine mehr davon.

    Falls jemand noch so etwas rumliegen hat und nicht mehr braucht, ich wäre interessiert.

    Ich biete im Austausch einen 20 € Schein. :)

    Fall somit erledigt

    Nur um mal zu zeigen, dass man das auch mit der Standard-MsgBox machen kann (_Timer-UDF missbrauchen):

    Diese Funktion berechnet und setzt die optimale Fontgröße für ein Gui-Element.

    Gerade, wenn man eine größenveränderbare GUI erstellt, hat man beim Resizing immer das Problem, dass sich die Fontgröße nicht mit ändert.

    Meine Funktion ermöglicht genau das (siehe Beispiel).


    Edit 07.10.2021:

    - Die Funktionen zu einer UDF ("CalcFontSize.au3") zusammengefasst. Diese kann jetzt per #include 'CalcFontSize.au3' in eigene Projekte eingebunden werden.

    - Um ein Label/Button für die automatische Fontgrößen-Anpassung zu registrieren, reicht nun ein _CalcFontSizeRegister($idCtrl) (siehe Example).

    - Die Anpassung geschieht jetzt in der Window-Procedur (Callback-Funktion). Damit ist GuiRegisterMsg wieder frei und das Maximieren/Wiederherstellen muss nicht mehr extra behandelt werden.


    Edit 09.10.2021:

    - Ich habe die UDF noch um eine Funktion erweitert _CalcFontSize. So eine Funktion kann ganz hilfreich sein, wenn man ein mehrsprachiges Programm schreibt und die Übersetzungen unterschiedlich lang sind. Dann kann man mit dieser Funktion die Anpassung einmalig (ohne Registrierung) aufrufen.

    - Das Beispielscript habe ich mal um ein zusätzliches Label erweitert, damit man den Unterschied sehen kann.

    - Einen kleinen Fehler beseitigt. In der WindowProc wurde die Fontgroesse erst nach dem ausmessen um eins verringert. Behoben!

    Ob ein abschließender Vergleich von InetGetSize mit der lokalen Dateigröße sinnvoll wäre muss Oscar entscheiden.

    Wenn InetGetSize vom Server eine falsche Dateigröße geliefert bekommt, macht ein anschließender Vergleich keinen Sinn, weil der dann eine Übereinstimmung ergibt und die Datei mit der falschen Größe trotzdem nicht gelöscht wird.


    In der Version von 2014 gab es noch den (achten) optionalen Parameter :

    Gibt es einen Grund, warum Du den aus der aktuellen Version entfernt hast ?

    Gute Frage...

    Ich befinde mich derzeit im Urlaub (Helgoland) und habe nur den "kleinen" Rechner hier. Ich weiß gar nicht mehr, warum ich den entfernt hatte.

    Vielleicht hielt ich das für überflüssig. Findest Du den Parameter wichtig?

    Mit GDI+ und dem Befehl _GDIPlus_GraphicsMeasureString kann man die Fontgröße experimentell ermitteln.

    Das funktioniert zwar nicht ganz perfekt, weil teilweise angezeigte Zeilen auch mit gerechnet werden, aber zumindest sieht es schonmal ganz gut aus:

    Ich zitiere mich mal.

    Wenn man mein Script noch etwas abwandelt, funktioniert es perfekt.

    Man muss nur zusätzlich die Zeilenhöhe einrechnen:

    Mit GDI+ und dem Befehl _GDIPlus_GraphicsMeasureString kann man die Fontgröße experimentell ermitteln.

    Das funktioniert zwar nicht ganz perfekt, weil teilweise angezeigte Zeilen auch mit gerechnet werden, aber zumindest sieht es schonmal ganz gut aus:

    Musashi

    Bekomme diese Fehlermeldung:

    Code
    >"C:\Program Files (x86)\AutoIt3\SciTE\..\autoit3.exe" /ErrorStdOut "C:\Users\mein\Desktop\Neuer Ordner\555555.au3"
    "C:\Users\mein\Desktop\Neuer Ordner\_DownloadWithProgress.au3" (258) : ==> Variable used without being declared.:
    $hLineBrush = DllCall($__g_hGDIPDll, 'uint', 'GdipCreateLineBrush', 'struct*', $tPoint1, 'struct*', $tPoint2, 'uint', 0xB0FFFFFF, 'uint', 0x00FFFFFF, 'int', 0, 'int*', 0)
    $hLineBrush = DllCall(^ ERROR
    >Exit code: 1    Time: 0.478

    Du benutzt eine veraltete Version von AutoIt.

    Ich weiß nicht genau, ab welcher Version die GDI+ Variable geändert wurde, aber aktuell ist jedenfalls: $__g_hGDIPDll.

    Es sollte doch mit Autoit möglich sein den Stream(Keyboard-Eingabe) direkt und ohne grafische Controls zu verarbeiten?

    Hier mal die Version mit dem Tastatur-Hook: