Delay bei animiertem GIF

[DBR]

Hallo!
Wie finde ich die unterschiedliche Dauer der Einzelbilder eines animiertem GIF heraus?
Danke schonmal!

DBR

[Andreas13]

Als Krücke & Provisorium: :oops:
die länger darzustellenden Bilder-Sequenzen mehrfach hintereiander verwenden...

[DBR]

Hä?
Wie ermittle ich "darzustellenden Bilder-Sequenzen", und was soll das nützen?

[Andreas13]

Sorry, ich habe Deine Frage falsch gelesen :oops::oops::oops:

[shebang]

Zitat:

Zitat von DBR (Beitrag 1541992)

Wie finde ich die unterschiedliche Dauer der Einzelbilder eines animiertem GIF heraus?

Schau dir am besten mal die die Doku zu TGIFGraphicControlExtension.Delay an.

[DBR]

Hab ich schon. Funktioniert nur nicht.

[DBR]

Habe jetzt eine Möglichkeit gefunden. Ob es eine bessere Lösung gibt, weiß ich nicht.

https://www.dbrsoftware.de/delphi/duration.php

Gruß
DBR

[himitsu]

FormDestroy ist unnötig, da sich dynamische Arrays selbst freigeben (beim Beenden dieser Unit, wo das global hingerotzt wurde).
Wenn schon, dann hätte man es wenigstens als privates Feld in die Form-Klasse reinmachen können (wo man gleich auch DurationOnce dazupacken könnte), aber besser ... siehe nachfolgend.

Delays gehört natürlich nicht global dahingeworfen, sondern z.B. als VAR-Parameter ins DurationOnce.
Und dann natürlich als lokale Variable ins Button1Click.

Delphi-Quellcode:

function DurationOnce(Datei: TFilename; var Delays: TArray<Integer>): Integer;

Dann konnte sich jemand nicht drauf einigen, ob #13, #13#10 oder #10, und hat alles wild miteinander krankhaft verwurschtelt.
PS: #13#10#10 sind zwei, nicht drei Umbrüche :stupid:
Wenn man keine Ahnung von nichts hat, dann würde ich sLineBreak empfehlen ... oder einheitlich #10 oder #13#10, aber niemals #13 (außer beim beschissenen TRichEdit oder bis vor 10 Jahren im iOS/MacOS).

Und warum achtet nie jemand auf die Meldungen des Compilers?
z.B. ungenutzte Variable, bzw. zugewiesener Wert würde nicht genutzt

[Sherlock]

'n bisschen mürrisch heute, oder?

[DeddyH]

Heute?

[himitsu]

Ohhh, das ist der selbe User. :shock:
Klang so, als hätte er was im Internet gefunden (von jemande Anderem), was er da nur verlinkt hatte.
Ich hatte ja nicht ihn, sondern liebevoll den Ersteller des verlinkten Beispiels gemeint. :oops:

Viele Fehler würden sich halt von selbst Lösen, täte jemand die Hinweise des Compilers lesen, vor allem so Dinge wie "Variable nicht initialisiert".

[DBR]

Ich finde es gut, dass manche Leute schlauer sind als ich Empiriker und danke für Kritik. Trotzdem macht der Ton die Musik.

PS.:
Nach meinem Wissen ist
#13 Zeilenanfang
#10 neue Zeile

[himitsu]

Nja, im Grunde kommt es von Plottern/Druckern, die von Schreibmaschienen abstammen.

NL aka #10 geht nur runter in die neue Zeile, bleibt aber in der Spalte
CR aka #13 geht eigentlich nur nach vorne, bleibt aber in der Zeile

Linux/Unix nutzt #10
Apple nutzte anfangs #13 als Zeilenumbruch (seit paar Jahren #10)
Windows #13#10, aber vielerorts alternativ auch #10

So gesehn war Windows eigentlich der Einzige, der es mit #13#10 richtig macht. :stupid:
(keine Ahnung, warum Windows-RichEdit es stattdessen mit #13 macht, weswegen Delphi hier leider am TRichEdit dran rumpfuscht)


Hier ist dann einer der Vorteile vom erwähnten sLineBreak, denn je nach Zielplatform (Windows, Linux, Android, iOS/OSX) ist es was Anderes.


In neuen Computersystemen wird beides oft als das Gleiche interpretiert -> "neue Zeile beginnen", also runter und nach links zum Anfang.
(nicht immer ... einige Windows-Komponenten behandeln z.B. #10, aber auch alternativ manchmal #13, gern nur als 0-Pixel breites "Zeichen" und machen sonst garnichts)

In alten EXCEL-Dokumenten oder einigen "CSV"-Implementationen wurde #10 und #13 gern absichtlich gemischt gleichzeitig genutzt, also z.B. #10 als Wert-Trenner und #13 als Zeilen-Trenner,
aber sonst ist es selten eine gute Idee es zu mischen und besser nur eine Variante zu nutzen.
PS: Da auch der Delphi-Editor damit gerne einige Probleme hatte, gibt es seit einer Weile die Option, die Zeilenumbrüche beim öffnen einer Datei/Unit "reparieren" zu lassen.