Batch-Fenster öffnet sich nicht

Begonnen von reap705, Februar 18, 2019, 09:57:00

« vorheriges - nächstes »

Paganini66

Zitat von: Cypheros am März 08, 2019, 21:00:11
Die Batchliste war nie dazu gedacht, dass der User dran rum fummelt.
Wenn ich das jetzt ändere und XML oder sowas nehme, wird bestimmt auch wieder rumgemeckert und es wird auch trotzdem Bastler geben, die es schaffen die Batchliste kaputt zu editieren.

Ich habe die Batchliste nicht kaputt editiert bzw. dran rum gefummelt. Wenn sie funktinieren würde, würde ich garnicht auf die Idee kommen, die Datei zu öffnen. Da mir aber nicht geholfen werden konnte, musste ich selber auf die Suche nach Fehlern gehen. Ergebnis, es werden bei manchen Filmen auch Filmbeschreibungen in die Batchliste geschrieben die das Ausführen der Batchliste unterbinden. Woher kommen diese Filmbeschreibungen und wie kann ich diese unterdrücken, so dass sie nicht in die Batchliste geschrieben werden?
DM 8000, DM 920 UHD

Cypheros

Unser Keilriemen-Spezialist hat es mal wieder geschafft ein neues Problem herbeizuzaubern.
Keine bisherige Batchliste hier hatte ein einzelnes LF als Zeilenumbruch. Die nächste Version behandelt jetzt auch den "neuen" Fall wie von Mam vorgeschlagen.

Trotzdem erklärt das nicht, wie bei Paganini66 oder anderen die CR,LF Zeichenfolge in die Batchliste kommt, denn die Routine, die die Batchliste erstellt, filtert CR,LF bei der Beschreibung definitiv raus. Oder siehst Du das anders Mam?


Mam

#32
Zitat von: Cypheros am März 09, 2019, 11:00:53
Unser Keilriemen-Spezialist hat es mal wieder geschafft ein neues Problem herbeizuzaubern.
;D er reisst sich halt am Riemen, selbst, wenn der keilig ist  8)

Zitat von: Cypheros am März 09, 2019, 11:00:53
Trotzdem erklärt das nicht, wie bei Paganini66 oder anderen die CR,LF Zeichenfolge in die Batchliste kommt, denn die Routine, die die Batchliste erstellt, filtert CR,LF bei der Beschreibung definitiv raus. Oder siehst Du das anders Mam?
Ich seh das im Moment gar nicht, denn da liegt bislang nur ein Screenshot vor, nicht die Datei selber. Deshalb kann man nicht wirklich erkennen, WAS da WO drin ist.

Das mit dem "lonesome LF" war allerdings ein "educated guess" von mir. Habe schon soviele Penetrationstests über meine Programme ergehen lassen müssen, da fügt man solche defensiven Zeilen schon ohne Nachdenken automatisch ein.

Allerdings solltest Du mal in Deine Doku für das Müslizeuchs gucken. Vielleicht gibt es ja eine globale Variable, die steuert, wie bei Textdateien das Zeilenende signalisiert werden soll. Es gibt einige Frameworks, wo man das als Flag angeben kann, bzw. in einer globalen Config irgendwo hinterlegen. Vielleicht macht der Doc ja dann nicht, was der Papa des Docs beabsichtigt hat? Es kann auch sein, dass das Verhalten unter irgendeinem Emulator ANDERS ist, bislang es aber noch niemand gemerkt hat.


Mam

#33
Also, bei genauerer Betrachtung erfüllt Dein Code immer noch nicht wirklich meine Qualitätsanforderungen and den Programmierstandard  :-*

Da sind einfach zu viele potentielle Fehler nicht abgefangen.

ich versuch mal ein etwas stabileres Redesign:


    myLine := FileSeparateEntry.AreaFiles[FileIndex].Description;
   /* ersmal potentiell vorhandene CRs in LFs umwandeln, somit hat der Rest nur noch gegen LFs zu kämpfen */
    myLine := StringReplace(myLine,#13,#10,[rfReplaceAll]);
    /* nun in einer Schleife alle doppelten LFs zu einzelnen reduzieren (Pseudocode, keine Ahnung von Müslisprache, create your own loop */
    do
       {
             myLine := StringReplace(myLine,#10#10,#10,[rfReplaceAll]);
        } while (instring(myLine,#10#10) > 0 )
    /* am Ende die verbliebenen einzelnen LFs durch <br> ersetzen */
    myLine := StringReplace(myLine,#10,'<br>',[rfReplaceAll]);
    BatchFile.Add(myLine);


Das überlebt auch den Fall, dass jemand nur CRs drin hat, oder die Reihenfolge LF/CR verwendet statt CR/LF. Und es löscht alle unnötigen Leerzeilen.

Wobei die Schleife erforderlich ist, denn rfReplaceAll wird wohl kaum rekursiv vorgehen intern. Somit wird LF/LF/LF/LF beim ersten Durchgang zu LF/LF reduziert und bei der nächsten Schleife erst zu LF (wenn es doch gleich funktionieren sollte, schadet die Schleife auch niemanden und signalisiert dem Leser, dass hier ein Mehrfachdurchgang erfolgt)

PS: die "rfIgnoreCase" kannse Dir schenken, kosten nur CPU und Speicherressourcen und machen für diese Anwendung absolut keinen Sinn. (Strings werden beide umkopiert und in Kleinschrift gewandelt, dann verglichen, aber CRs und LFs gibts nicht in Klein/Großsschrift, also kommt immer dasselbe raus))

PPS: sowas gehört als überlagerte Funktion mit in die String Klasse, so dass auch der luhrige Programmierhansel es nicht vergessen kann...

PPPS: noch wichtiger, als hier beim Wegschreiben, ist die Einlesefunktion. Du kannst Dich ja offensichtlich nicht darauf verlassen, dass niemand an den Daten rumgepfuscht hat, also muss dort auch eine Toleranz mit eingebaut werden. Ein schnödes "readln()" wird nicht reichen.

Mam

Zitat von: AX98 am März 10, 2019, 23:12:53
Beim Einlesen der geschnittenen Datei wird die zuvor erstellte txt-Datei verwendet und die Zeilenumbrüche werden richtig gesetzt.
Was sieht denn dabei "richtig" aus?
Entweder LF oder CR/LF, aber doch bitte nicht wild gemischt!

Mam

Zitat von: AX98 am März 11, 2019, 10:01:20
Aus dem Fenster der Details habe ich den Text markiert, in ein leere Textdatei kopiert und mit dem Notepad++ geöffnet (Neues Textdokument2). (Bild_10)
Was sieht nicht richtig aus ?
Lesen! mitt die Augens!
Wenne die Untaschiede zwischen B6 & B5 nicht erkennen kannst, dann hilft wahrscheinlich auch keine Brille nie nich mea!

Offensichtlich nimmt Scheffe zur "Feldtrennung" das Zeilenende CR/LF, in der ursprünglichen Datei wurde in der Beschreibung "Description" die Trennung nur mit LF vorgenommen. Du machst daraus wieder CR/LF und wunderst Dich, warum der Doc dann auf die Schnauze fällt ? ? ?

Da hilft wohl auch kein Keilriemen mehr (gibts die eigentlich überhaupt noch? selbst mein Fahrrad hat inzwischen einen ZAHNriemen stattdessen...)

Mam

#36
Zitat von: AX98 am März 11, 2019, 10:46:36
Ich habe jetzt nicht die Zeit alles genau zu vergleichen, mache ich aber später nach dem Arbeitstag.
Dazu braucht man keine Zeit, das sieht ein Blinder mit Krückstock  8)

Aber, was pröhlst Du eigentlich dann hier rum, wenn Du gar kein Problem hast ?

Und das mit den Vergleichen von Äpfeln und Birnen ist Dir auch schon mal zu Ohren gekommen? ? ?

Deine "Infos" sind also reiner Unsinn und nicht zweckdienlich... (warum bin ich nicht wirklich überrascht?)


Mam

Na ja, zumindest ist ein "Besserwisser" nützlicher als ein "Garnichtwisser".

Aber, bevor dieser Thread mal wieder gekapert wurde und vollends in die Sinnlosigkeit abdriftet, zurück zum wirklichen Problem:

*) das "interne Format" der Datei ist nicht wirklich krisenfest
*) Der Doc lässt sich durch simple Manipulationen auf Abwege bringen
*) sowohl Rausschreibe-, als auch Wiedereinlesenroutine müssen überarbeitet werden

Paganini66

Also für mich hat sich das Problem gelöst. Seit dem letzten Update (2.2.14) wird die Filmbeschreibung in der Batch Datei mit ,,<br>" unterbrochen.
Die Batch Datei ist wieder aus dem Programm heraus zu öffnen und vollumfänglich zu benutzen.
Vielen Dank dafür.
DM 8000, DM 920 UHD

Kiraly-Cutter

Bei der Benutzung des Batchprozessings fällt mir aber auf, dass nur die Anzeige der Prozente für den ersten Schnitt bei 100 % endet. Bei den folgenden von der gleichen Aufnahme gehen die Prozente zurück am Ende der Datei (60 bzw 38 %).  :o
Das Logo von One HD ist wohl nicht im zip des Ordners Logos.
Ich habe es aus dem Internet geladen und es dem zip hinzugefügt.
Dann wird es beim Öffnen der Aufnahme angezeigt.
Dreambox DM920 UHD 4K
VU+ Duo 4K SE


www.cypheros.de