Beiträge von Mars

Hatte vor Urzeiten auch mal was angefangen: Eine Makrosammlung für C++ (die hinten und vorne nicht funktioniert hat und inzwischen unauffindbar verschwunden ist, vermutlich irgendwann gelöscht beim PC neu aufsetzen...).

Die Idee dahinter war, dass man AutoIt-Code "fast" 1:1 als C++ laufen lassen kann, sofern man die richtigen Makros/Klassen definiert hat (ein bisschen Preprocessing ist trotzdem notwendig). Als jemand der ausschließlich Windows nutzt war der Plan dahinter aber nicht, dass Linux unterstützt wird (das könnte ich gar nicht machen, da kenne ich mich kein Stück aus). Das war einfach eine Spielerei.

M

Wahnsinn, wer hätte gedacht dass es es mal AutoIt-Videos auf Deutsch gibt

So ein paar verstreute Beispiele habe ich irgendwo schonmal gesehen, aber mehr ist mehr

lg

M

Das ist doch alles nur Spaß

(Ich habe meinen Beitrag noch 5x editiert, aber da war die Antwort schon da )

Je komplizierter desto besser. Hmm... stimmt. Die Entropie muss auch noch an anderer Stelle ergänzt werden, weil die "Ziehungen" nicht unabhängig voneinander sind (es ist ja eine Ziehung ohne Zurücklegen) was in der Entropie nicht berücksichtigt wird... (also Wahrscheinlichkeitsverteilung nach jedem Schritt renormieren). Und dann noch das mit den Fehlversuchen die man erst weiß nachdem man danebenlag... Und die Wahrscheinlichkeitsverteilung von Nutzereingaben die sich von der üblichen Buchstabenhäufigkeit unterscheidet...

Ich glaube das wird mir zu kompliziert.

Zitat von AspirinJunkie

1. Die Anzahl der Versuche richtet sich nach dem zufällig ausgewähltem Wort:
   Mein Vorschlag (mit nicht ganz trivialer Stochastik) zur Berechnung der Anzahl der Fehlversuche wäre daher hierzu folgender:

Da habe ich direkt an folgende Methode gedacht:
Die Entropie eines Worts ist (ungefähr) proportional zur Anzahl Bits, die eine Huffman-Kodierung (mit einem Tree der mit Wahrscheinlichkeiten für deutsche Buchstaben erstellt wurde) von diesem Wort ergibt. Mit unseren bereits implementierten Huffman-Kodierern sollte das trivial machbar sein (bzw. einfach mit der Entropieformel und der Wahrscheinlichkeitsverteilung der Buchstaben, den Kodierer braucht man ja nicht).

Ein Problem ist natürlich, dass beim Galgenraten automatisch "alle" Vorkommen des Buchstabens und nicht nur das erste aufgedeckt werden, sodass die reine Entropie hier einen "zu großen" Wert liefert. Vermutlich reicht es das Wort auf die ersten Vorkommnisse zusammenzustauchen: "vorkommnisse" -> "vorkmnise", und dann die Entropie zu berechnen. Der Wert dafür müsste eigentlich ein guter Indikator dafür sein wie kompliziert es ist das Wort "zufällig, aber mit dem Wissen über die Buchstabenverteilung" zu erraten.

In deiner stochastischen Analyse gehst du von einer Gleichverteilung der Buchstaben aus. Das sollte ein wenig zu kleine Ergebnisse liefern. Vielleicht kann man das irgendwie kombinieren und den "Ultimativen Galgenraten Versuchsanzahl Abschätzer" entwickeln

lg

M

Mir wäre das zu viel Text. Wenn ich eine 100 Zeichen Nachricht verschlüsseln will hätte ich keine Lust, dass 300 Zeichen herauskommen. Erst recht wenn man das im Kopf machen muss, so viel RAM hab ich gar nicht

Zitat von Alina

Aber es kann nicht passieren, das hier ein Fehler auftritt.

Das schreibe ich in Zukunft in meine Codekommentare direkt neben "this should never happen".

Zitat von Andy

Auf ein Beispiel was du wirklich meinst, wäre ich ECHT gespannt!...und ich bin ziemlich sicher...DU AUCH!

Tatsache. Ich habe nur die Hälfte von dem geschrieben was ich mir dabei gedacht habe, so ergibt das natürlich keinen Sinn (bzw. es ist einfach falsch)

Eigentlich wollte ich da auf die Unterschiede zwischen Clamp und BitAnd eingehen (also aus einer Zahl das 0x00??0000 via BitAnd und Div 256^n rausholen vs: Die gesuchte Zahl berechnen und clampen). Dann dachte ich mir, dass das wahrscheinlich nichts bringt und habe den halben Text irgendwie trotzdem geschrieben. Mysteriös.

lg

M

Schau dir BitOr, oder die Addition im Hexadezimalsystem an.

Beispiel:

Du hast: 0xRRGGBB (hex). Jeder dieser Teile hat 8 Bit. Es sind also 0xRR0000 + 0x00GG00 + 0x0000BB

Du möchtest: 0xAARRGGBB, es fehlt also der 0xAA000000 Teil. Je nachdem wie du das angehen möchtest kannst du also "einfach" 0xFF000000 addieren, oder (was sicherer ist, da es das Überlaufen in benachbarte Bytes verhindert, falls einzelne Werte größer als 255 sind. Das sollte bei hardgecodeten Werten nicht passieren, wenn die Werte aber berechnet werden und ein Clamp fehlt macht das beim einfachen Addieren die Farben kaputt) ein BitOr verwenden. Noch eine Alternative wäre das Zerlegen in Strings, sodass man via Int("0xFF" & "1A49BC") ebenfalls zum Ergebnis kommt (das wäre die "nicht mathematische Lösung").

lg

M

Mit "das größte Problem sind Datenstrukturen" habe ich natürlich ne steile These hingelegt. Sobald man mit "auto", "impl", Templates oder überladenen Operatoren anfängt (da weiß schon intellisense manchmal nicht mehr was der Code eigentlich macht) ist das Spiel sowieso vorbei

Mit der Geschwindigkeit (also dass man Code ziemlich doll umschreiben muss damit er in AutoIt ebenfalls "schnell" läuft) habe ich "relative geschwindigkeit" gemeint. Natürlich ist AutoIt 1000x langsamer, wenn man mies übersetzt ist es aber 5000x.

Mein Trip endet, sobald meine aktuelle Aufgabe endet.

Dann kommt die nächste Aufgabe und damit der nächste Trip

lg

M

Gerade bei der Geometrieverarbeitung erwartet dich in AutoIt nur Trauer und Schmerz. Ich habe selbst einiges aus C++ nach AutoIt übersetzt um einfache Tools zu basteln, und man merkt immer und immer wieder wie Pointer und Datenstrukturen fehlen.

Das ist auch das allergrößte Hindernis an einem Übersetzungsprogramm: Datenstrukturen. (das 2t größte Hindernis sind die 10.000 Stunden Aufwand die ein Übersetzer kostet)

Ja, wir haben DllStruct in AutoIt, die können aber nur primitive Datentypen halten. Möchte man verschachtelte Datenstrukturen verwenden muss man das mit Pointern erledigen. Um Pointer effektiv nutzen zu können muss man via DllstructCreate und kernel32-alloc manuell dafür sorgen, dass die Datenstruktur nicht gelöscht wird sobald keine AutoIt-Variable mehr vorhanden ist die sie hält (man will ja nur den Pointer haben), zusätzlich muss man aber irgendwie trotzdem dafür sorgen, dass der Speicher später freigegeben wird (ist möglich, aber unschön). Möchte man Datenstrukturen "in place" verwenden (z.B. Ball = (float x, float x, float diameter), BallPark = (Ball[10])) um z.B. direkt über alle "Ball" zu loopen muss man im Prinzip rekursives unrolling und alignment betreiben (sodass in der endgültigen Struct nur noch primitive vorhanden sind, die man dann auf umständliche Art und Weise via in Place erzeugter Struct anspricht). usw usw. Da kann man sich auch gleich nen eigenen Speichermanager schreiben. Was wahrscheinlich sowieso mal bitter nötig wäre, wenn man jemals über die "Struct die Primitive enthält" hinauskommen möchte.

Außerdem sind DllStructs in AutoIt deutlich langsamer als z.B. Arrays (oder seit einiger Zeit Maps mit IntegerKeys... die aus "Gründen" schneller sind als Arrays, solange die Größe < 256 Elemente ist). Was in C++ ein immenser Geschwindigkeitsvorteil ist (z.B. loop über alle "Ball", wenn sie aligned im Speicher liegen) ist in AutoIt unfassbar langsam (loop in verschachtelten Arrays/Maps). Apropos verschachtelte Arrays/Maps: Es gibt in AutoIt KEIN same scope ByRef. Du kannst den Inhalt eines Verschachtelten Arrays nicht direkt ansprechen. In der Klammersyntax ($A[0])[0] kann ein Array das in $A[0] liegt nur gelesen, aber nicht geschrieben werden, außerdem wird jedes Mal dereferenziert, wenn man das macht -> Langsam. Einziger Umweg ist über Funktionen mit ByRef Parameter, dann hat man aber den Overhead eines Funktionsaufrufs, was sich nur lohnt, wenn das Array das man beschreiben will eine gewisse Größe hat, für kleine Arrays ist 2x Kopieren schneller als 1x Funktionsaufruf mit ByRef.
Was ich damit eigentlich sagen will: Code der in C++ richtig schnell läuft muss komplett umstrukturiert werden um in AutoIt ebenfalls schnell zu laufen.

Es ist schon echt nervtötend "einfache" Sachen aus C++ von Hand zu übersetzen (ich meine nicht platten C-Code (flat API), der geht natürlich easy), und ich bin nicht in der Lage mir ein automatisches Programm dafür auch nur vorstellen zu können...

Edit: Hier mal ein Beispiel das wirklich nur für diesen einen Spezialfall funktioniert:

- Zeigt wie man "in place" eine Liste aus Structs in einer Struct bastelt, die auch (nur in diesem Fall hier) korrekt im Speicher liegt und daher von C++ 1:1 übernommen werden könnte (falls man 32bit aligned ist. bei 128 wird die Ball Struct noch 32Bit padding am Ende bekommen. Wenn man Vektorisierung angeschaltet hat wird das wahrscheinlich so sein, dann kann der Compiler auch automatisch sse verwenden, dann mag er 4x32er Blöcke lieber).

- mit "Spezialfall" meine ich z.B.: Der Typ "BALL" und der Feldname "ball" muss im UpperCase-Fall identisch sein. Man kann nicht mehrere Felder mit "BALL" Typ haben. "BALL" darf keine Feldnamen wie x, y, d haben. Und unendlich + 2 weitere Einschränkungen. Das ist kein Code den ich für irgendwas sinnvolles verwenden würde, er dient nur als Minimalbeispiel.

- Wenn man das "allgemein" Lösen will ist man Monate dran (und nicht die 15 Minuten die mich dieses Beispiel gekostet hat) und hat danach immernoch unendlich viele Bugs.

#include <Array.au3>
#include <Memory.au3>

Global $_DN[] ; Structnamen hinterlegen
Global $_DS[] ; Sizes

DllStructRegister('BALL;float;float;float')

; numBalls ist nur hier damit man zeigen kann wie man "in diesem Fall hier" das Offset berechnen kann. numBalls wird nicht verwendet.
$balls = DllStructCreate2('int numBalls;BALL ball[10]')

$oneBall = DllStructCreate2('Ball')
DllStructSetData($oneBall, 1, 1)
DllStructSetData($oneBall, 2, 2)
DllStructSetData($oneBall, 3, 3)

For $i = 0 To 9 Step 1
    DllStructSetData($oneBall, 1, Random(0, 10, 1))
    DllStructSetData($oneBall, 2, Random(0, 10, 1))
    DllStructSetData($oneBall, 3, 7)
    DllStructSetData2($balls, 'ball', $i, $oneBall) ; memcpy
Next

For $i = 0 To 9 Step 1
    $v = DllStructGetData2($balls, 'ball', $i) ; $v ist jetzt die "Ball" Struct (Kopie)
    ConsoleWrite('Type: ' & VarGetType($v) & ' size: ' & DllStructGetSize($v) & ' -> ')
    ConsoleWrite('Ball[' & $i & ']: ' & DllStructGetData($v, 1) & ', ' & DllStructGetData($v, 2) & ', ' & DllStructGetData($v, 3) & @CRLF)
Next


Func DllStructSetData2($v, $sName, $i, $xValue)
    If MapExists($_DS, StringUpper($sName)) Then
        Local $size = $_DS[StringUpper($sName)]
        Local $sStruct = $_DN[StringUpper($sName)]
        Local $iOffset = DllStructGetPtr($v, $sName) - DllStructGetPtr($v)
        Return _MemMoveMemory(DllStructGetPtr($xValue), DllStructGetPtr($v) + $iOffset + $size * $i, DllStructGetSize($xValue))
    EndIf
    DllStructSetData($v, $sName, $xValue, $i)
EndFunc

Func DllStructGetData2($v, $sName, $i)
    If MapExists($_DS, StringUpper($sName)) Then
        Local $size = $_DS[StringUpper($sName)]
        Local $sStruct = $_DN[StringUpper($sName)]
        Local $iOffset = DllStructGetPtr($v, $sName) - DllStructGetPtr($v)
        Return DllStructCreate($sStruct, DllStructGetPtr($v) + $iOffset + $size * $i)
    EndIf
    Return DllStructGetData($v, $sName, $i)
EndFunc

Func DllStructCreate2($sStruct)
    Local $a = StringSplit($sStruct, ';', 2), $b, $s = '', $c, $d
    For $i = 0 To UBound($a) - 1 Step 1
        If StringInStr($a[$i], '[', 0, 1) Then
            $b = StringSplit($a[$i], '[', 2) ; TYPE name
            $c = StringSplit($b[0], ' ', 2)
            If MapExists($_DN, StringUpper($c[0])) Then
                $d = StringSplit($_DN[StringUpper($c[0])], ';', 2)
                $s &= $d[0] & ' ' & $c[1] & ';'
                For $j = 1 To UBound($d) - 1 Step 1
                    $s &= $d[$j] & ';'
                Next
                For $j = 0 To Number(StringTrimRight($b[1], 1)) - 2 Step 1
                    $s &= $_DN[StringUpper($c[0])] & ';'
                Next
            Else
                $s &= $a[$i] & ';'
            EndIf
        Else
            If MapExists($_DN, StringUpper($a[$i])) Then
                $s &= $_DN[StringUpper($a[$i])] & ';'
            Else
                $s &= $a[$i] & ';'
            EndIf
        EndIf
    Next
    ConsoleWrite($s & @CRLF)
    $s = StringTrimRight($s, 1) ; remove ';'
    Return DllStructCreate($s)
EndFunc

Func DllStructRegister($sStruct)
    Local $sName = StringSplit($sStruct, ';', 2)[0]
    $sStruct = StringTrimLeft($sStruct, StringLen($sName) + 1)
    $_DN[StringUpper($sName)] = $sStruct ; String Key
    Local $_ = DllStructCreate($sStruct)
    $_DS[StringUpper($sName)] = DllStructGetSize($_)
EndFunc

lg

M

Die Einzige Version dich ich eine Weile lang parallel mitbenutzt habe ist die Beta 3.3.9.5. Grund war, weil das die einzige Version von AutoIt ist in der man das "$" bei Variablen weglassen kann, und ich so eine Rarität selbstverständlich zu schätzen weiß.

lg

M

Seit ich Visual Studio verwende, habe ich auch die Farbgebung in SciTE entsprechend angepasst.

(Ist eine Kombi aus dem Standard VSC++ Dark Theme und dem alten Dark Theme von SciTE für AutoIt)

Das verwende ich bereits so lange, dass ich AutoIt gar nicht mehr lesen kann, wenn das Farbschema "original" ist

pasted-from-clipboard.png

(Nur als Input, falls das auch jemand verwenden möchte, jeder hat ja andere Präferenzen )

Edit: Sehe gerade, dass die Datei von BugFix doppelt so groß ist wie meine. Habe nicht ausprobiert was beim Einfügen meiner Datei in ein anderes Setup passiert. Ggf. muss man also ein wenig von Hand herumbasteln bis es klappt.

Edit2: Meine ".properties" Datei ist NICHT wie von Bugfix vorgeschlagen eine eigenständige Datei die in die eigentliche .properties eingebunden wird. Ich habe die Datei vor langer Zeit so angepasst wie sie jetzt ist und einfach aus meinem Ordner kopiert. Wenn man es "richtig" machen will nimmt man die Version von BugFix

lg

M

EDIT BugFix:

Ich war mal so frei und hab daraus eine reine Theme.properties erstellt, zu laden mit import dark_theme_mars

Für "einzelne" Flags ist BitOr und "+" das Selbe, da hier immer nur ein einziges Bit gesetzt ist. Für Kombinierte Flags ist das nicht mehr gegeben.

(nur zur Info, falls dich das verwirrt. Beide Schreibweisen können richtig sein, sofern man weiß was man tut)

Beispiel (binär):

0001 + 0100 = 0101 ist gleichbedeutend mit BitOr(0001, 0100) = 0101

0101 + 0100 = 1001 ist NICHT gleichbedeutend mit BitOr(0101, 0100) = 0101

Im ersten Fall ist jeweils nur 1 Bit gesetzt -> BitOr und "+" sind identisch.

Im zweiten Fall sind mehrere Bits gesetzt -> BitOr ist die einzige richtige Lösung.

lg

M

Aaaaah, jetzt verstehe ich das erst

Dazu musst du bei der GUI Erstellung die ensprechenden Flags setzen:

Global $hGUI = GUICreate('test', 800, 800, -1, -1, 0x00040000 + 0x00020000 + 0x00010000) ; Resizable GUI

(In der Hilfe findet man alles: https://www.autoitscript.com/autoit3/docs/a…x/GUIStyles.htm)

lg

M

Moin,

Habe gemerkt, dass scheinbar etwas interesse daran besteht eine UDF zu haben die das GUI Erstellen (vorallem für Skalierbare Fenster) etwas vereinfacht. Ein großes Problem ist üblicherweise, dass man unmengen hardgecodete Zahlen braucht und mit GUICtrlSetResizing irgendwie nicht das hinbekommt was man gerne hätte.

Da ich nur eine einzige Person bin unterliege ich dem "Funktioniert schon, weil es für mich funktioniert" Bias. Daher bitte ich darum, dass ein paar Leute einfach zum Spaß ein kleines UI mit dieser UDF bauen um Fehler zu finden / Vorschläge zu machen / Wünsche zu äußern / etc.

Im Anhang ist eine sehr "dahingetackerte" Version der UDF, die aber schon für einige Anwendungen funktioniert. Ich möchte die aber erst "in Form bringen", wenn sich sicher bin, dass die UDF keine gravierenden Designschwächen mehr hat (dann muss man nämlich einiges Umschreiben was unnötige Arbeit ist und grundsätzlich unmengen Bugs erzeugt).

Funktionsweise:

- Ein GUI hat eine ClientArea (via user32::GetClientRect abrufbar). Diese entspricht der "Root" Box.

- Eine Box kann entweder Horizontal (HBOX), Vertikal (VBOX), oder "Egal" (EMPTY) sein

- Boxen und GuiCtrlXXX können in Boxen gelegt werden. Sie werden dann automatisch skaliert um die umgebende Box auszufüllen.

Es gibt schon ein paar Feintuningmöglichkeiten:

- _UIBB_Insert($PARENT, $CHILD, $nScale) ermöglicht es die "default" Skalierung von Boxen und Ctrls einzustellen.

- _UIBB_SetSize($ANY, $nPxSize) setzt die Pixelgröße einer Box relativ zum Parent. Parent = HBOX -> $nPxSize = Breite, Parent = VBOX -> $nPxSize = Höhe

- _UIBB_SetPadding($ANY, $left, $right, $top, $bot) setzt den INNEREN Rand einer Box in Pixeln

- Genaue Anleitungen wie man was macht gibt es nicht, dazu muss man die Beispiele ansehen.

Hinweise:

- Alle Größenangaben die man setzt sind nur ein "Vorschlag". Sie werden nicht zwingend eingehalten (z.B. wenn man ein 100px breites Feld mit 3 Ctrls mit je 50px breite befüllt. Dann werden die logischerweise etwas gestaucht).

- Tabs und Groups sind "nonblocking" da sie keinen Platz verbrauchen. Sie erhalten Implizites Padding, sodass der Innenraum automatisch passt.

- Es gibt keine DPI unterstützung, ich habe nur auf Win10 getestet, Es gibt keine Schriftgrößenskalierung, etc.

Wenn die UDF fertig ist gibts dazu nen eigenen Thread in "Skripte", erstmal geht es aber darum die Idee überhaupt in Form zu bringen, und das kann ich nicht alleine. Fehler, Wünsche und Ideen von anderen sind wichtig, damit nicht "nur ich" mit dem Ergebnis zufrieden bin, sondern jeder der es potentiell verwendet. (gesucht sind also quasi "Feature Requests")

Known Issues:

- [TODO] Wenn man das Fenster extrem verkleinert verschwinden einige Ctrls (z.B. TABs). Danach ist das Fenster nicht mehr ansprechbar (vermutlich Messageloop unterbrochen, da Ctrl "kaputt"). Needs investigation, vielleicht ein AutoIt Problem, vielleicht ein UDF problem.

- [TODO] Größe von Boxen/Ctrls werden Iterativ angeglichen, das ist ziemlich langsam und ungenau. Das muss überarbeitet werden.

- [TODO] Tabs "ordentlich" in die UDF integrieren.

Requests:

- [DONE] Mindestgröße für das Komplette Fenster vorgeben (z.B. 600x400 px. Macht man das Fenster kleiner wird nicht mehr Skaliert. Die Ctrls werden dann "aus dem Fenster herausgeschoben", aber nicht mehr verkleinert. (Moombas #2)

- [HOLD] Dynamisches UI (man kann zur Laufzeit z.B. eine Elementbreite etc. einstellen damit sich das UI dynamisch verhalten kann) -> Problem: AutoIt hat keine Pointer und das UI ist komplett in einer Baumstruktur (verschachtelte Maps) untergebracht. Ein Direktzugriff auf ein spezielles Element ist nur mit extremem Overhead möglich, daher [On Hold] bis mir dazu etwas einfällt... (Mars)

Changelog:

- Mindestgröße für komplettes Fenster wird durch die Parameterreihenfolge in _UIBB_Box($UIBB_HBOX, 500, 300, $hGUI) zwingend erforderlich wenn man die UDF nutzen will. Damit wird verhindert, dass sich jemand keine Gedanken darüber macht.

- Mindestgröße für Boxen ist diekt in _UIBB_Box($UIBB_VBOX, 120) integriert. Kein redundantes "setSize" mehr nötig. Da Boxen (außer der Root-Box) nur eine Dimension haben (Breite oder Höhe) ist _UIBB_Box($UIBB_VBOX, 120, 200) stellvertretend für 120 = MindestWert & 200 = Maximalwert)

lg

M

Apropos "UI Skalierung". Ich habe gestern und heute ein bisschen gebastelt. Im Endeffekt brauche ich das auch selbst, war aber immer viel zu faul eine richtige UDF daraus zu machen. Die Methode verwende ich aber eigentlich immer um GUIs aufzubauen.

Im Anhang ist ein kleiner erster Eindruck der UDF. Das wird dir jetzt nicht viel bringen, weil man da das komplette UI vollständig neu gestalten müsste, aber wenn die UDF mal fertig ist hoffe ich, dass Skalierungsprobleme und Anordnungsprobleme bei User Interfaces der Vergangenheit angehören. Ich habe genug hässliche GUIs gesehen und genug hardgecodete Koordinaten und For-Loops um "schön angeordnete Buttons" zu produzieren. Das alles braucht man damit nicht mehr.

Die Erklärungen in den Kommentaren ist rudimentär. Genaueres gibts dann irgendwann (wer weiß wann....) in einem eigenen Thread.

lg

M

Das Problem liegt daran, dass in _QR_getLastCall() $__ga_LastCall[3] = "" (leerer String) ist. Das Nachfolgende Switch deckt diesen Fall nicht ab (hier könnte man Case Else verwenden, das fängt "alle" fälle ab die vorher nicht behandelt wurden). Da ich keine Ahnung von der QR UDF habe kann ich keine weiteren Aussagen treffen (kann also nicht sagen warum der Fehler auftritt, die Zeilen nach dem Switch (die mit DllStructSetData) verwenden nicht die dot-syntax weshalb hier @error gesetzt wird, weil $tOut keine Struct ist, sodass der Fehler bis in den Returnwert wandern kann)

Da die UDF von BugFix ist müsste er sich das vermutlich ansehen.

lg

M

Dann möchte ich mich entschuldigen. Ich schätze mal die "DAU-Programmierung" ("Dümmster Anzunehmender User") hat mich nachträglich beeinträchtigt^^
Meine Übliche Vorgehensweise ist: Wenn mein kleiner Bruder ein Programm länger als 5 Minuten verwenden kann, ohne dass es abschmiert, dann ist es solide programmiert. (der ist 27 und hat auch was mit IT zu tun, aber er ist für Software quasi das Gegenteil von Jesus: "Tod durch Handauflegen")

lg

M

Kleine Hinweise für .ini Dateien:
- [Todo] Ein Program das eine .ini verwendet sollte "immer" eine Default-Ini generieren, falls versucht wird die Ini zu lesen, obwohl keine vorhanden ist (im Idealfall mit einem kleinen nicht invasivem Hinweis das das soeben passiert ist). Diese Ini sollte an der Stelle liegen von der aus das Programm die Ini später auch lesen wird, sodass ein neuer Nutzer beim Programmstart direkt weiß was hier eigentlich los ist.

- [Bug] Dein Programm crasht wenn die .ini fehlt: "QR-Code-Generator.au3" (141) : ==> Subscript used on non-accessible variable.:"

- [Todo] Der Programmname gehört nicht in die .ini

- [Todo] Der übliche Nutzer erwartet, dass die .ini "config.ini", "settings.ini" oder ähnlich heißt.

Kleine Hinweise für Programme die irgendwer verwendet allgemein:

- [Todo] Bau eine Statusleiste unten an den Bildschirmrand in der unauffällig alle möglichen Infos (z.B. auch das Generieren der .ini) angezeigt werden. Falls mal irgendwas nicht klappt kannst du hier Fehlercodes ausgeben die der Benutzer dir dann mitteilen kann.

- [Todo] Der übliche Nutzer erwartet eine Titelleiste mit einem Menu das mit "Datei" (en. "File") beginnt um auf einige Grundfunktionen zugreifen zu können: Laden, Speichern, Beenden, etc. Alles sollte mit Hotkeys verwendbar sein.

- [Todo] Die Tabs sollten alle einen Namen haben, selbst wenn es nur Nummern sind. Falls dein Programm häufiger verwendet wird gewöhnen sich die Nutzer daran, dass sie z.B. "auf Tab 5 klicken müssen", das wird aber nicht passieren wenn die Tabs keine Bezeichnung haben.

- [Bug] Die Inputfelder für Ordner und Dateiname löschen sich automatisch, wenn man hineinklickt.

Das soll keine Kritik sein, nur eine Art Todo-Liste (von Sachen die mir auf die Schnelle aufgefallen sind), das sind alles Probleme die wieder auf dich zurückkommen, sobald mehrere Leute dein Programm verwenden

Zur UI Skalierung auch ein Hinweis:

- Es ist immer eine schwierige Sache, vor allem wenn das UI einige Teile enthält die unterschiedlich skalieren. Wenn du komplizierteres Verhalten möchtest musst du vermutlich von Hand etwas basteln (ggf. die RESIZE msg abfangen und die Elemente neu anordnen). Da musst du aber jemanden Fragen der sich damit besser auskennt (mit den Built-in Funktionen zum Resizen), ich selbst mache sowas immer "extrem" umständlich (mit verschachtelten Boxen. Das gesamte Fenster enthält "eine" Box, diese Box enthält z.B. 2 Boxen (eine große die die übergeordenete Box fast komplett ausfüllt und am unteren Rand eine mit voller Breite und 30px Höhe), in die Untere Box kommt dann z.B. die Statusbar, in die obere kommen weitere Boxen die das Fenster ein Regionen einteilen. In diese kommen dann die UI-Elemente selbst. Wird das Fenster skaliert, wird nur die eine einzige Box die alles weitere enthält skaliert. Anschließend wird die Skalierung an die unteren Boxen durchgereicht und alles passt sich automatisch von selbst so an wie man es eingestellt hat... Habe dafür aber leider keine UDF, sonst würde ich die garantiert mal posten)

lg

M

Wenn ich so eine Frage bekomme werde ich... gerne mal ausschweifend

1. Triviale Antwort: Ästhetik.

Es gibt im Netz ein paar Webseiten die "Movie Barcodes" von allen möglichen Filmen haben, zeigen, und sogar als Merch verkaufen. Von daher, wie bei jeder grafischen Spielerei: Es sieht einfach interessant aus.

2. Interessant anzusehen.

Auch wenn man kein Regisseur oder anderweitiger Profi ist, finde ich es interessant zu sehen welche Farbtöne unterschiedliche Filme zu unterschiedlichen Zeitpunkten haben. Die Beispiele "watchmen" und "das fünfte element" passen da zum Glück ganz gut (habe die eigentlich nur genommen, weil ich die Dateien davon herumfliegen hatte): Der eine ist Dunkelblau und Dunkelgrün, der andere ist Orange und Holzfarben.

3. Identifikation von Filmausschnitten / Duplikaten (ist hier nicht implementiert, aber deshalb kam ich überhaupt dazu soetwas zu basteln).

Die Idee dahinter ist, dass ein Filmausschnitt immer den selben Barcode ergibt, wenn er mit der selben Abtastrate (pixel pro Sekunde) erzeugt wird. Genauso erzeugt der selbe Film immer den selben Barcode, selbst wenn Codec, Auflösung, Qualität, FPS und sontiges unterschiedlich sind. Der Trick ist jetzt, dass der Barcode eines Filmausschnitts identisch zum Barcodeausschnitt eines Films ist (im Rahmen der Abtastrate. Ein paar Prozent Abweichung gibt es immer, da man verschiedene Frames erwischt). Der Barcode ist aber nur "eine" Bitmap die relativ einfach vergleichbar ist, während ein Film nicht ohne weiteres "verglichen" werden kann (das funktioniert natürlich nur, wenn man eine Variable Breite verwendet. Im hier geposteten Skript wird der Output ja immer via resize in die gewünschte Größe gebracht). Diese Eigenschaft lässt sich ausnutzen indem man für jeden bereits vorhandenen Film in einer Sammlung den Barcode generiert. Wird ein Film neu hinzugefügt, generiert man dort ebenfalls den Barcode, vergleicht ihn mit den bereits vorhandenen und kann darüber herausbekommen ob der Film bereits vorhanden ist. Falls er schon da ist kann man die Version mit höherer Qualität behalten und die mit niedrigerer Qualität löschen.
Genauso kann man, wenn man z.B. einen 5 Sekunden Clip von einem Film sieht, einen Barcode generieren, und diesen in der Datenbank suchen (teilweise Matches sind ja kein Problem). Dann findet man (sofern vorhanden) den Film aus dem der Clip stammt automatisch und einen Zeitstempel gibts gleich mit dazu.

Naja, jedenfalls war das die Idee. Aber ich habe nach dem ersten Schritt aufgehört, sodass es leider keine automatische Filmdatenbank gibt.

lg

M