Beiträge von 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/a…cs/appendix/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

Moin,

Anbei ist ein Skript, das aus einem Film einen "Movie Barcode" vorgegebener Größe erzeugt.

Der Code ist mehr oder weniger aus dem DE und EN Forum zusammengeklaut und neu zusammengesetzt. Da ich aber noch niemanden gesehen habe der so einen Generator gebastelt hat, dachte ich es wäre praktisch das mal zu machen. Damit das Skript funktioniert muss irgendwo eine FFMPEG.exe herumliegen. Da man sich heutzutage erstmal durch 20 Websites die 50 Versionen des Sourcecodes für alle möglichen Linux-Versionen anbieten klicken muss, bevor man eine .exe findet ist hier ein Direktlink: https://github.com/BtbN/FFmpeg-Builds/releases

Hier ist das Skript

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

Global Const $ffmpeg_path = 'ffmpeg.exe'

; Movie Barcode test
_FFMPEG_Barcode('irgendein_film.avi', 'irgendein_film.png', 1024, 256)

Func _FFMPEG_Barcode($sFile_Input, $sFile_Output, $iWidth, $iHeight, $nOversampling = 0.1)

    Local $iOffset = 0
    Local $iFrames = 1000 ; Irgendeine Zahl größer als jeder Frame des Videos
    Local $iFPS = 29.97

    Local Const $tagBITMAPFILEHEADER = "struct;align 2;word bfType;dword bfSize;word bfReserved1;word bfReserved2;dword bfOffBits;endstruct;"
    Local $tBMPHEADER = DllStructCreate($tagBITMAPFILEHEADER & $tagBITMAPINFO)
    Local $tBMPHEADER_B = DllStructCreate("byte[" & DllStructGetSize($tBMPHEADER) & "];", DllStructGetPtr($tBMPHEADER))

    Local $bData, $bTmp, $sErr, $iLen

    Local $sCMD = __FFMPEG_CMDGetFrames($sFile_Input, 0, 0, 0, 0, 1)
    ConsoleWrite("> CMD: " & $sCMD & @CRLF)
    Local $hPID = Run($sCMD, @ScriptDir, @SW_HIDE, BitOR(0x2, 0x4))

    Local $sStderr = ''
    While True
        Local $sTmp = StderrRead($hPID)
        $sStderr &= $sTmp
        If StringInStr($sStderr, 'Duration') Then ; Das steht nach Duration im Output
            $sStderr = $sTmp
            While True
                $sStderr &= StderrRead($hPID)
                If StringInStr($sStderr, 'Stream') Then ExitLoop 2
            WEnd
        EndIf
    WEnd

    Local $aLines = StringSplit($sStderr, @CRLF, 3), $iDuration, $nFPS_Source
    For $i = 0 To UBound($aLines) - 1 Step 1
        Local $sLine = StringStripWS($aLines[$i], 8)
        If StringStartsWith($sLine, 'Duration') Then
            Local $aSplit = StringSplit(StringSplit($sLine, ',', 2)[0], ':', 2)
            $iDuration = Number($aSplit[1]) * 3600 + Number($aSplit[2]) * 60 + Number($aSplit[3])
        EndIf
        If StringStartsWith($sLine, 'Stream') Then
            Local $aSplit = StringSplit($sLine, ',', 2)
            For $ii = 0 To UBound($aSplit) - 1 Step 1
                If StringInStr($aSplit[$ii], 'fps') Then
                    $nFPS_Source = Number($aSplit[$ii]) ; Schneidet den String "fps" ab und macht ein double daraus.
                    ExitLoop 2
                EndIf
            Next
        EndIf
    Next
    ConsoleWrite('get info ...')
    ProcessWaitClose($hPID, 1000)
    ConsoleWrite('done.' & @CRLF)

    $iFPS = $nFPS_Source * $nOversampling
    $iFrames = Round($iDuration * $iFPS * 1.1) ; Etwas überschätzen damit platz ist.

    Local $iFrameWidth = 1 ; Jeder Frame = 1 pixel breit
    Local $iFrameHeight = $iHeight ; mal Oversampling

    ConsoleWrite('Time[s]   ' & $iDuration & @CRLF)
    ConsoleWrite('FPS       ' & $nFPS_Source & @CRLF)
    ConsoleWrite('Frames  ~ ' & StringLeft(Round($iDuration * $nFPS_Source) & '        ', 10) & ' ( ~ ' & Round($iDuration * $iFPS) & ' with oversampling factor of ' & $nOversampling & ')' & @CRLF)

    $sCMD = __FFMPEG_CMDGetFrames($sFile_Input, $iOffset, $iFrames, $iFrameWidth, $iFrameHeight, $iFPS)
    ConsoleWrite("> CMD: " & $sCMD & @CRLF)
    $hPID = Run($sCMD, @ScriptDir, @SW_HIDE, BitOR(0x2, 0x4))

    _GDIPlus_Startup()
    Local $hBMP = _GDIPlus_BitmapCreateFromScan0($iFrames, $iFrameHeight)
    Local $hGFX = _GDIPlus_ImageGetGraphicsContext($hBMP)
    Local $vLINE = DllStructCreate('byte col[' & $iFrameHeight * 4 & ']') ; Reverse order (stride = -4)
    Local $hLINE = _GDIPlus_BitmapCreateFromScan0(1, $iFrameHeight, $GDIP_PXF32ARGB, -4, DllStructGetPtr($vLINE) + ($iFrameHeight - 1) * 4)
    Local $iLineOffset = 0, $bFirst = True

    While True
        $bTmp = StdoutRead($hPID, False, True)
        If @error Then ExitLoop

        If BinaryLen($bTmp) Then
            $bData = Binary($bData & $bTmp)

            While 1
                DllStructSetData($tBMPHEADER_B, 1, $bData)

                $iLen = BinaryLen($bData)
                If $iLen < $tBMPHEADER.bfSize Then ExitLoop

                If Not $bFirst Then ; Der erste Frame ist immer doppelt ?! Keine Ahnung warum...
                    DllStructSetData($vLINE, 1, BinaryMid($bData, 55, $tBMPHEADER.bfSize - 54))
                    _GDIPlus_GraphicsDrawImageRect($hGFX, $hLINE, $iLineOffset, 0, 1, $iFrameHeight)
                    $iLineOffset += 1
                EndIf
                $bFirst = False

                $bData = BinaryMid($bData, $tBMPHEADER.bfSize + 1, $iLen)
            WEnd
        EndIf

        $sErr = StderrRead($hPID)
;~         If $sErr Then ConsoleWrite($sErr)

        Sleep(10)
    WEnd

    _GDIPlus_GraphicsDispose($hGFX)
    _GDIPlus_BitmapDispose($hLINE)

    Local $hArea = _GDIPlus_BitmapCloneArea($hBMP, 0, 0, $iLineOffset, $iFrameHeight, $GDIP_PXF32ARGB)
    Local $hNew = _GDIPlus_ImageResize($hArea, $iWidth, $iHeight)
    _GDIPlus_ImageSaveToFile($hNew, $sFile_Output)
    _GDIPlus_BitmapDispose($hBMP)
    _GDIPlus_BitmapDispose($hNew)
    _GDIPlus_Shutdown()

EndFunc   ;==>_FFMPEG_Test

Func StringStartsWith($sString, $sSubstring)
    Return StringLeft($sString, StringLen($sSubstring)) = $sSubstring
EndFunc

Func __FFMPEG_CMDGetFrames($sFile, $iOffset, $iFrames, $iW, $iH, $iFPS)
    Local $sCMD = $ffmpeg_path & ' -y'
    If $iOffset Then
        Local $_iH, $_iM, $_iS
        _TicksToTime($iOffset, $_iH, $_iM, $_iS)
        Local $_iMS = $iOffset - _TimeToTicks($_iH, $_iM, $_iS)
        $sCMD &= ' -ss ' & StringFormat("%02s:%02s:%02s.%03s", $_iH, $_iM, $_iS, $_iMS)
    EndIf
    If $iFPS <> -1 Then
        $sCMD &= ' -i "' & $sFile & '"' & ' -r ' & $iFPS
    Else
        $sCMD &= ' -i "' & $sFile & '"'
    EndIf
    If $iW > 1 Or $iH > 1 Then $sCMD &= ' -vf "scale=' & $iW & ':' & $iH & '"'
    $sCMD &= ' -vframes ' & $iFrames & ' -update true -vcodec bmp -pix_fmt bgra -f image2 -'
    Return $sCMD
EndFunc

; Jaaaa
Func __FFMPEG_GetAverageColor($aBMPi0)
    Local $iData, $hData, $pData, $tData, $pStream, $hImage
    $iData = BinaryLen($aBMPi0)
    $hData = _MemGlobalAlloc($iData, $GMEM_MOVEABLE)
    $pData = _MemGlobalLock($hData)
    $tData = DllStructCreate("byte[" & $iData & "]", $pData)
    DllStructSetData($tData, 1, $aBMPi0)
    Local $bgra[4]
    For $i = 55 To $iData Step 4
        $bgra[0] += DllStructGetData($tData, 1, $i + 0)
        $bgra[1] += DllStructGetData($tData, 1, $i + 1)
        $bgra[2] += DllStructGetData($tData, 1, $i + 2)
        $bgra[3] += DllStructGetData($tData, 1, $i + 3)
    Next
    For $i = 0 To 3 Step 1
        $bgra[$i] /= ($iData - 54) / 4
    Next
    Return $bgra
EndFunc

; Kann man so machen. Für "große" Bilder ist das auch richtig so. Wir haben hier aber nur 1px breite Bilder. Man schießt nicht mit Kanonen auf Spatzen.
Func __FFMPEG_GetImage(ByRef $aBMP, $i)
    Local $iData, $hData, $pData, $tData, $pStream, $hImage
    $iData = BinaryLen($aBMP[$i][0])
    $hData = _MemGlobalAlloc($iData, $GMEM_MOVEABLE)
    $pData = _MemGlobalLock($hData)
    $tData = DllStructCreate("byte[" & $iData & "]", $pData)
    DllStructSetData($tData, 1, $aBMP[$i][0])
    _MemGlobalUnlock($hData)
    $pStream = _WinAPI_CreateStreamOnHGlobal($hData)
    $hImage = _GDIPlus_ImageLoadFromStream($pStream)
    _WinAPI_ReleaseStream($pStream)
    Return $hImage
EndFunc

Damit lässt sich z.B. sowas hier generieren:

(das fünfte element)

(watchmen)

Die Einstellungen fürs Oversampling sind mit Vorsicht zu genießen. Der Wert von 1.0 bedeutet: JEDER Frame wird decodiert und als eine 1px hohe Linie gespeichert bevor die Bitmap anschließend in Form gebracht wird. Bei einem Film mit 200.000 Frames wird das Probleme geben (daher habe ich als Default-Wert eine 0.1 eingetragen, dann wird jeder 10te Frame verwendet und mit 20.000 Frames geht noch alles gut).

(edit: Da ffmpeg die meiste Arbeit verrichtet werden sehr viele Videoformate unterstützt und die Geschwindigkeit ist auch ganz gut, da AutoIt nur das "Management" übernimmt und selbst gar nicht rechnen muss)

(edit2: Für sehr große Mengen an Frames ist AutoIt das Bottleneck, da im Code angenommen wird, dass die Zeit die AutoIt braucht um die dekodierten Frames abzuarbeiten vergleichbar ist mit der Zeit die zum dekodieren gebraucht wird. Geht das Dekodieren signifikant schneller als das Managen der Daten gibt es eine quadratische Laufzeit, da im inner Loop $bData = BinaryMid($bData, $tBMPHEADER.bfSize + 1, $iLen) verwendet wird, was extrem langsam ist, wenn bData z.B. 10.000 Frames enthält. Vielleicht überarbeite ich diese Methode nochmal für Lineare Laufzeit)

lg

M

Ob du das nachvollziehen kannst, oder nicht. In der kompilierten exe steckt "der Interpeter" & "das Skript". Das habe ich mir nicht ausgedacht, das war schon immer so und wird auch immer so bleiben. Wenn dein Skript eine konstante größe hat, dann ist der Interpreter der Teil der immer größer wird.

Nachlesen kannst du das hier: https://www.autoitscript.com/autoit3/docs/intro/running.htm (im Unteren Teil: Run a script using another compiled script, irgendwo gibts dazu auch noch eine bessere Beschreibung, das ist die erste die ich auf die Schnelle gefunden habe)

Wie das mit den verschiedenen Größen aussieht kann ich auch nur mutmaßen.

lg

M

Weil die "kompilierte" Datei im Prinzip eine Kombination aus "Interpreter + Skript" ist.

Der Interpreter (die AutoIt.exe) wird mit jeder Version ein wenig größer. Das hat mehrere Gründe (spekulativ, da ich es natürlich nicht wissen kann, aber ich kann einen educated guess anstellen):

- Es wird selten/nie alter Code entfernt/ersetzt, sondern nur neuer hinzugefügt (kein Refactoring, sondern immer nur hinzufügen/instandhalten)

- Es werden werden Lookuptables für einige Funktionen hinzugefügt (damit sie grundsätzlich dasselbe Ergebnis liefern, egal auf welcher Hardware das Skript läuft)

- Es werden Features hinzugefügt/Bugs gefixt die neue #includes erfordern, sodass vielleicht nur 500 Byte neuer Code im Interpreter gelandet ist der aber eine 50 KB Vergrößerung verursacht.

- usw.

lg

M

Es ist eigentlich nur ein Spaß aus der SB, aber falls jemand interesse an sowas hat (und ggf daran weiterbasteln will) gibts dazu einen Thread.

Warnung: Der Code ist 100% Spaghetti (daher auch nicht im Skripte Forum, sondern in OffTopic). Nicht aufgeräumt, vollkommen verwirrend und ineffizient/falsch programmiert, und an verschiedenen Stellen die dasselbe machen wird "dasselbe" auf "verschiedene Art und Weise" erledigt (da ich einfach ein paar Methoden ausprobieren wollte). Alles in allem ist es nur ein Test wie ein paar Syntaxänderungen aussehen würden, wenn sie denn existieren würden.

Die eigentliche Idee dahinter ist einfach: Comfort.

AutoIt zwingt dem User gewisse Patterns auf: Es gibt keine One-Line Funktionen, Es gibt keine Initialisierungsmethode für Maps, es gibt kein #define, es gibt keine impliziten Arrays in einem Return (nur um 4 Beispiele zu nennen die auch im hier geposteten Code auftreten). Bei jedem dieser Teile fällt Boilerplate-Code an (trivialer Code der immer und immerwieder nahezu gleich ist und unmengen an Zeilen, oder ein Workaround braucht).

Ein Skript wie das folgende sollte mit dieser "UDF" nativ in Scite ausführbar sein, dieses Skript ist nur eine Demo die funkioniert. Es ist besser nicht zu erwarten, dass ein beliebiges großes Skript mit AutoItPlus laufen wird.

#AutoIt3Wrapper_Run_Au3Check=n
#include "AutoItPlus.au3"

; #Define - Compile Time Constants
; Diese Konstanten werden 1:1 im Code ersetzt.
#Define CaseSensitiveValue "CamelCase"
#Define casesensitivevalue "lowercase"
ConsoleWrite(CaseSensitiveValue & @CRLF)
ConsoleWrite(casesensitivevalue & @CRLF)

; #Define mit mehreren Zeilen (vorsicht, kein Support von #Define mit Variablen, also #Define something(x) x^2 wird nicht funktionieren.)
#Define MyFuncDefinition Func EuclideanLength($a, $b) \ Return Sqrt($a^2 + $b^2) \ EndFunc
MyFuncDefinition ; wird entpackt zu
; Func EuclideanLength($a, $b)
; Return Sqrt($a^2 + $b^2)
; EndFunc
ConsoleWrite('3^2 + 4^2 = ' & EuclideanLength(3, 4) & '^2' & @CRLF)

; #Define mit Strings
; Normalerweise werden Strings von #Define in Ruhe gelassen, es sei denn sie ergeben einen 100% match.
#Define 'test' 'erfolgreich'
ConsoleWrite('test ' & 'test' & @CRLF) ; das erste 'test ' enthält ein Leerzeichen und ist daher kein 100% match.

; #Enum - Compile Time Enum (verringert Overhead bei der Verwendung von Enums)
#Enum EINS, ZWEI, DREI
ConsoleWrite(EINS & ' ' & ZWEI & ' ' & DREI & @CRLF)

; Map als Nachschlagewerk, jeder Key wird mit dem leeren String initialisiert.
Global $List['a', 'b', 'c']
ConsoleWrite(MapExists($List, 'a') & ' ' & MapExists($List, 'x') & @CRLF)

; Map mit Initializer-List -> Da der Matcher nicht robust ist dürfen in der Initializerlist KEINE Operatoren verwendet werden. Nur Strings und Integer.
Global $Map['a', 'b', 'c', 1, 2, 3] = ['str a', 'str b', 'str c', 'int 1', 'int 2', 'int 3']
ConsoleWrite($Map['a'] & ' ' & $Map[1] & @CRLF)

; Implizites Array im Return
Func ReturnTest()
    Return [1, 2, 3]
EndFunc
ConsoleWrite(ReturnTest()[0] & ' ' & ReturnTest()[1] & ' ' & ReturnTest()[2] & @CRLF)

; Single Line Function (aktuell nur Global-Scope)
Global Add($a, $b) Return $a + $b
ConsoleWrite('3 + 5 = ' & Add(3, 5) & @CRLF)

; Kombinationen von obigen Sachen funktionieren "manchmal"
Global Array($a, $b) Return [$a, $b]
ConsoleWrite(Array(1, 2)[0] & ' ' & Array('a', 'b')[1] & @CRLF)

; Es stehen nur 40.000 Zeichen zur Verfügung...

Wenn weitere Ideen auftauchen, schreibt einen Kommentar

Gesucht sind keine "Verunstaltungen" der Syntax (Geschweifte Klammern, Semikolons, Syntax anderer Sprachen, etc), sondern "Vereinfachungen" von Stellen die beim Programmieren immer wieder nerven.

Und nicht vergessen: Immer schön "#define True False" verwenden, da kommt Freude auf

Andere Ansätze:

- synsug (von chesstiger)

lg

Mars

Bitte formuliere die Frage besser.

"gibt es eine Möglichkeit in autoit formen wie z.B ein Viereck oder ein Dreieck oder sowas zu erkennen"

Beispiel 1: Speichere die Koordinaten für ein Axis-Aligned-Rect und ein Dreieck in einem Array. Vierecke brauchen 4 Werte (x, y, w, h im R²), Dreiecke brauchen 6 Werte (3 Punkte mit je x und y)
-> Die Unterscheidung ist hier trivial via UBound.

Beispiel 2: Das Dreieck/Viereck ist in einer 2D Computergrafik (pixel), Alle Vierecke sind Axis-Aligned (also durch x, y, w, h darstellbar), alle Kanten sind scharf, alle Flächen sind einfarbig.
-> Ebenfalls trivial. Das Bild besteht nur aus einfarbigen Flächen verschiedener Form, ein "Ist das ein Viereck" check ist hier trivial. Ein Dreieck-Check wird etwas anstrengender aber auch möglich.

Beispiel 3: Das Dreieck/Viereck ist in einer 2D Computergrafik (pixel), alle flächen sind einfarbig. Freie Rotation ist erlaubt.
-> Hier hört der (triviale) Spaß bereits auf. Ein (halbwegs) einfacher weg (wenn alles einfarbig ist) besteht darin die Flächen via floodfill algorithmus aus dem Gesamtbild zu trennen. Dann kann man sie einzeln betrachten und außenkanten finden wo 50% der Pixelzentren links und 50% rechts von einer Linie liegen. Das macht man ein Mal für 3 und ein Mal für 4 Kanten, schaut wo der Fit besser passt -> Dreieck/Viereck unterschieden.

Beispiel 4: Das Dreieck/Viereck ist in einer 2D Computergrafik (pixel), Flächen können (milde) texturiert sein (eine Textur die Dreiecke/Vierecke beinhaltet wäre natürlich fies), freie Rotation ist erglaubt.
-> Hier hört das auf was ich zuverlässig ohne nachzuschlagen programmieren kann.

Beispiel 5: Das Dreieck/Viereck ist in einer Fotografie (pixel). Es ist perspektivisch verzerrt, hat eine Textur, die Kanten sind unscharf.
-> Hier hört das auf was ich zuverlässig mit viel Arbeit und Nachschlagen programmieren kann. Eine halbwegs funktionierende Version davon musste ich vor Ewigkeiten mal für eine Computer-Vision VL basteln. Da habe ich aber C++ draufgeworfen und zusammen mit OpenCV alles mit Rechenpower besiegt was nicht bei 3 auf dem Baum war. Das wird in AutoIt nicht funktionieren.


Daher bitte: Formuliere die Frage besser. Keiner kann wissen was du willst.

M

Das letzte ist wieder eine Permutation.

Es geht einfach nicht. Ich habe es auch eine ganze Weile lang versucht. Sobald man eine Anzahl N Zahlen (oder Buchstaben) aus einem Bereich der ebenfalls die Größe N hat will kommen die Sachen in geordneter Reihenfolge, oder als Permutation (keine doppelten). Und selbst wenn man mehrfach darauf hinweist, dass Zufallsziehungen voneinander Unabhängig erfolgen (ich muss ja nicht erst alle Zahlen von 1 bis 6 würfeln, bevor der Würfel wieder "resettet" ist. Der Würfel "resettet" sich nach jedem einzelnen Wurf) gibt es kein Licht am Ende des Tunnels. Daher kam auch meine ursprüngliche Formulierung, dass "doppelte ausdrücklich erwünscht sind" weil ich erwartet habe, dass Buchstaben dann wenigstens doppelt vorkommen. In voller Trollmanier gabs dann das eben gepostete Ergebnis mit aa, bb, cc, ... das "technisch gesehen" eine Zufallsfolge mit doppelten Buchstaben ist. Aber jeder Grundschüler würde das besser machen^^

Die einzige Chance ist es z.B. nach 10 Zufallszahlen im Bereich von 0 bis 3 zu fragen. Dann bekommt man tatsächlich einige Zahlen doppelt (weil es sonst unmöglich ist diese Frage zu beantworten)...

Ist schon seltsam: Schlüsselfragen zu wirklich kompliziertem Kram (Finite Element Analysis, das ist gerade mein Bastelthema) kann ChatGPT überraschend ordentlich beantworten und auch hinweise auf Fallstricke bei verschiedenen Methoden abliefern (vermutlich hat es sämtliche Fachzeitschriften dazu in den Trainingsdaten gehabt), aber einfach 26 zufällige Buchstaben ausgeben ist unmöglich

PS: An dem ersten Ergebnis ist einfach "alles" perfekt.
- Der Trollpost ansich "aa, bb, cc, dd, ..." (mit hervorhehobenem doppel d)
- Die Sprache "Bash" (in Anlehnung an die 2000er, wo "jemanden bashen" noch als "jemanden fertigmachen" in der Jugendsprache zu finden war)
- Der grenzwertig sarkastische Zusatzkommentar, dass Buchstaben doppelt vorkommen "können".
Etwas schöneres habe ich noch nie gesehen

Ich verwende das immer so:
MyFunc    -> Funktion die "klein" ist. z.B. Cosh, Sinh, Array, Map, MapContains, Print, StringToStruct, etc.
_MyFunc   -> Mittelgroße Funktionen, im Falle von UDFs: Diese Funktionen enthalten die Hauptfunktionalität
__MyFunc  -> ByRef Wrapper oder Internals.
___MyFunc -> ByRef Wrapper (andere Ausreden gibts nicht für 3 Layer :D)

Globale Variablen:
$ABC_MyVar, wobei ABC die Abkürzung für das Modul, oder die UDF ist. z.B. $A3D_PEN -> Teil von A3D, Enthält einen GDIPlus-Pen.

("große" Funktionen gibts bei mir nicht, weil ich üblicherweise alles zerteile, wenn es zu groß wird)

M

Zitat von Alina

Sorry, aber ich verstehe gar nichts. Was für ein Haltepunkt? Mir fehlt das innere Bild vor den Augen um was es geht.

Es geht um das Halteproblem was in gefühlt 99.9% der Fälle als theoretisch unlösbar dargestellt wird, dabei ist es nur auf Maschinen mit unendlichem Speicher theoretisch unlösbar (und selbst dagegen würde ich ein Veto einlegen. Wenn man schon "unendlich" viel Speicher ins Spiel bringt, dann ist 2^unendlich (die Menge Speicher die man brauchen würde um alle inneren Zustände von unendlich vielen Bits zu loggen) nicht weit hergeholt) dargestellt wird, obwohl es für Maschinen mit "endlichem" Speicher (N Bits) theoretisch lösbar ist (vorausgesetzt man hat 2^(N+1) Bits an Speicher um alle theoretisch möglichen Zustände der Maschine mitzuschreiben).

Dank der englischen Wikipedia (und noch ein paar anderen Infos die ich gefunden habe) ist mein Problem damit eigentlich geklärt, habe den Thread trotzdem offengelassen (und nicht gelöscht/geschlossen), weil mich die Darstellung immer ärgert


Anschauliches Beispiel:

- Ein Computer (oder eine Virtual Machine) hat 32 Bit RAM (ja ich weiß, das ist sehr wenig)

- Der Computer hat einen beliebig großen Programmspeicher.

- Jedes beliebige Programm A das auf diesem Computer läuft (egal wie groß es ist, es liegt im Programmspeicher) kann ausschließlich die 32 Bit RAM manipulieren

- Es gibt also 2^32 verschiedene Zustände die das RAM haben kann.

- Ein anderes Programm B (von außerhalb) soll beurteilen ob A hält oder nicht.

- Das andere B schreibt jeden Zustand von A in eine Logdatei (Größe der Logdatei ist maximal 2^33Bit = 8GBit)

- Sobald A in einen Zustand verursacht der schonmal in der Logdatei vorkam -> Programm ist in einer Endlosschleife

- Sonst: A wird eine Anzahl Innerer Zustände < 2^32 durchlaufen und dann terminieren ->

- qed.

Fazit:
Um das Halteproblem für ein Programm A zu lösen muss dem Überwachungsprogramm B ein Speicher von 2^N Bits zur Verfügung stehen, wobei N die Anzahl Bits ist die A manipulieren kann.

Für endliche Speichergrößen ist das Problem also lösbar (wenn auch unpraktikabel... Angenommen A hat 1MB RAM, dann braucht B 2*2^8388608 Bits RAM, was ziemlich viel ist), und für unendliche Speichergrößen ist es logischerweise auch lösbar, weil wenn man schon mit unendlich anfängt ist 2^(unendlich+1) auch möglich.

M

Moin,

immer mal wieder taucht irgendwo eine Doku, ein Video, ein Artikel, oder sonstiges über das Halteproblem auf (auch vor ein paar Wochen in der SB, wo ich etwas ähnliches geschrieben habe wie hier im Thread). Leider bin ich nicht in der Lage zu verstehen warum das Halteproblem ein Problem ist. Und inzwischen geht mir jede Erklärung die ich irgendwo sehe auf den Zeiger, weil ich sie einfach nicht verstehe (bzw. jede beliebige Erklärung sofort mit den unten genannten 2 Punkten widerlegen kann).

Definition (stark vereinfacht. Aber ich gehe davon aus, dass jeder das Problem kennt):

Das Programm H entscheidet ob Programm P mit input X (also P(X)) hält, oder nicht.

Das Programm R mit Input H(...) hält, wenn H(...) entscheidet, dass "..." nicht hält, das Programm R geht in eine Endlosschleife, wenn H(...) entscheidet, dass "..." hält.

H soll entscheiden ob R hält.

R hält, wenn H entscheidet, dass R nicht hält und umgekehrt -> Problem.

Meine Probleme damit:

1. Instanzen. ALLES ist instanziiert. Die Aussage "R hält, wenn H entscheidet, dass R nicht hält" ist Unfug, da H für einen vollständigen Input (P(X), oder eben R(...)) entscheidet ob P(X) hält. Die Parameter mit denen H gestartet werden sind also zum Zeitpunkt wenn H gestartet wird fixiert. Also können die Parameter sich im Nachhinein nicht mehr ändern und das Ergebnis von H beeinflussen. Und selbst wenn man annimmt, dass es keine Instanzen gibt, dann werden H, R, P und X alle auf einem endlichen Computer (mit endlichem Speicherplatz) ausgeführt, sodass Punkt 2 zur Geltung kommt.

2. Endlichkeit. ALLES ist endlich. Jedes Programm (wie auch immer es aussehen mag) hat eine endliche Anzahl innerer Zustände (alle bits die das Programm beeinflussen kann). Ein Programm H könnte jetzt jeden inneren Zustand von P(X) mitschreiben. Wenn P(X) in einen inneren Zustand eintritt den es früher schonmal hatte (weil P(X) deterministisch arbeitet), ist P(X) in einer Endlosschleife. Wenn P(X) vorheriges nicht erfüllt wird es nach endlicher Zeit seine endlichen inneren Zustände durchlaufen haben und halten. -> Problem gelöst.

Kann es sein, dass das Halteproblem nur für "unendliche" Maschinen sinnvoll definiert ist?

Ich bin einfach zu blöd dafür und Wikipedia hilft mir auch nicht weiter...

Falls jemand eine "einfache" Erklärung hat wie der Hase läuft, her damit.

Vielleicht habe ich auch einen Denkfehler. Auch in diesem Fall: Her damit.

Edit: Kaum hab ich die englische Wikipedia angeschaut habe ich meinen eigenen Satz auf englisch gefunden...

The halting problem is theoretically decidable for linear bounded automata (LBAs) or deterministic machines with finite memory. A machine with finite memory has a finite number of configurations, and thus any deterministic program on it must eventually either halt or repeat a previous configuration

Na super... Dann bleibt nur noch die Frage übrig, warum das offensichtlich für "nicht existierende Computer" definierte Problem andauernd falsch dargestellt wird...

lg

M

Ich bin nicht sicher ob ich das Problem verstanden habe, aber hier der übliche Lösungsweg:

- Denke dir einen "Errorwert" aus (in den Meisten fällen ist das Int32 -1, also $s_Breite = -1)

- Prüfe am Ende, ob dein Wert -1 ist (If $s_Breite = -1 Then ...) um herauszufinden ob ein Wert gesetzt wurde.

Alternativ kann man auch ausnutzen, dass AutoIt einen Variant Datentyp hat. Wenn du exakt weißt, dass der Wert zu einem String (egal ob leer, oder voll) wird, dann initialisiere sie z.B. als Int32 (z.B. $s_Breite = 0). Anschließend kannst du via If IsInt($s_Breite) Then ... prüfen ob die Variable von irgendwem gesetzt wurde. Ein richtiger Errorwert wie -1 ist aber idr die bessere Idee.

lg

M

Das mit dem Akku ist bei uns auch so ne Sache. Mein Vater (der alte Hobbyelektriker) hat da was gebastelt, sodass wenigstens alle Kühlschränke und Gefrierschränke und einige andere kleine 24/7 Verbraucher auch Nachts über Solar laufen. Da ich keine Ahnung habe was der Spaß gekostet hat weiß ich nicht wie die Amortisierung aussieht.
Außerdem haben wir deutlich über 100% (im Sommer) ausgebaut, sodass man ca. 70% des Jahres quasi komplett über Solarstrom läuft sobald die Sonne aufgeht (ich wohne aber auch auf nem Berg, bei mir scheint immer die Sonne, in der Stadt kann man das wahrscheinlich knicken wenn der Schatten von Nachbarhäusern etc. die Sonne verdeckt, die Garage nicht im Freien steht, oder das Dach zu klein ist). Im Winter kommt dafür natürlich nicht genug rein, sodass hier wirklich nur die "Kleinverbraucher" dauerhaft via Solarstrom funktionieren. Was bei Überproduktion auch ganz praktisch ist ist ein Heizstab im Wassertank (Zentralheizung, aktuell mit Holzofen als Wärmequelle... eine Wärmepumpe ist in Planung, kommt aber erst irgendwann später, dafür muss man erstmal sparen), dann bleibt der Ofen das halbe Jahr lang aus und man hat trotzdem Warmwasser und Heizung (wobei letztere im Sommer ja eher wenig genutzt wird... hauptsächlich im Keller). Klingt (und ist) verschwenderisch, aber es ist aktuell (bei uns) sinnvoller den Überschuss komplett zu verbraten als ihn einzuspeisen^^

Was die Akkutechnik angeht hab ich aber schon seit Ewigkeiten aufgegeben an ein Wunder zu glauben. Zu oft wurde uns der "neue XYZ Akku mit 95% Wirkungsgrad und 3x Kapazität (vgl mit LiPo) und halbem Preis" versprochen und nie ist etwas dabei herumgekommen.

Selbstverständlich ist alles obige vollkommen Subjektiv. Für andere Leute an anderen Orten gelten andere Regeln