Copy & Paste

[C-J Gustafsson]

Om man ofta använder klipp & klistra från formaterade texter kan ett bra tips vara att klistra in texten i en ren texthanterare, t.ex. Notepad/Anteckningar. Därifrån gör man sen klipp & klistra till Disgens notis.

Det städar bort formateringstecken och lämnar bara formateringarna "radbrytning" och "nytt stycke", d.v.s. samma som Disgen och GEDCOM använder.

Formaterad text i en GEDCOM fil orsakar ofta att GEDCOM filen innehåller formella fel som gör att den inte accepteras för import. När en GEDCOM fil blir formellt felaktig är det till 99% orsakat av formaterade texter.

[andan1965]

Om man ofta använder klipp & klistra från formaterade texter kan ett bra tips vara att klistra in texten i en ren texthanterare, t.ex. Notepad/Anteckningar. Därifrån gör man sen klipp & klistra till Disgens notis.

Jajamän. Ett jättebra tips som jag använder hela tiden, och inte bara i Disgen utan i alla möjliga sammanhang.

Problemet är att infogar du inga ¥ (Shift+Enter) manuellt efter du klistrat in, så får du inga radbrytningar vid GEDCOM-export.

Så om du har i notisen:

Sid 12
3 bilder

Exporteras det till:

Sid 123 bilder

Vilket är hur dåligt som helst.

[C-J Gustafsson]

Rätt Anders, jag hade nog inte kollat så noga.

Sid 12
3 bilder

blev vid inklipp i Disgen
Sid 12 3 bilder

som vid GEDCOM export blev
Sid123 bilder

Men som Anders skriver, när man manuellt lägger in radbyte så blir det rätt
Sid 12
3 bilder

Disgen behöver göra någon justering, antingen att behålla löpande text och då justera GEDCOM exporten eller hantera CR-LF som radbrytning vid klistra in.

Det finns ju en poäng med det sätt som Disgen hanterar löpande text då det innebär att löpande text förblir löpande text även när det är olika radlängder på in-texter och ut-texter.

Bästa resultatet blir nog att det borttappade mellanslaget vid GEDCOM export fixas och att användaren med manuell radbrytning styr önskade radbyten.

[andan1965]

Jag förstår inte varför Disgen använder sig av egna påhittade "radbrytstecken" som ¶ och ¥.

Normalt använder de flesta "plain text" program/gränssnitt radbyte som just radbyte, och eventuellt två radbyten efter varandra som paragrafbyte. Vad jag förstår använder GEDCOM just den metoden med dubbla radbyten.

*OM* nu Disgen ska använda egna "radbrytstecken", *BÖR* Disgen omarbeta texten vid urklippsformaten CF_TEXT och CF_UNICODETEXT vid både "kopiera" och "klistra in", liksom alla andra Windows-program gör.

Funktionen bör vara sådan, att uppreppade kopiera och klistra in, fram och tillbaka, mellan Disgen och Anteckningar, inte ska förändra texten eller hur radbyten fungerar.

Det enklaste hade varit om Disgen behandlade CR-LF som ett vanligt radbyte, liksom alla andra. Jag förstår inte varför det inte är så, men det har kanske någon historisk orsak (bakåtkompatibilitet).

Hade Disgen varit mitt program, hade jag nog övervägt att i en ny release (version av databasen) ersätta alla sekvenser av "¥ CR LF" med "CR LF" och "¥ NUL" med "NUL", och sedan behandlat "CR LF" som radbyte. Vem har utnyttjat att Ctrl-Enter ger ett i Disgen synligt radbyte som vid export/presentation tas bort? I så fall borde man vända på det och låta "¥" betyda "bind ihop med nästa rad". Det hade varit mer naturligt.

Redigeringskommandon inom < och >, språkval efter $ och vilka andra koder som kan finnas, är en annan historia, de kan vara orörda som de är vid Copy & Paste. Jämför med hur man redigerar ett inlägg här i forumet.

(Jag har yrkesmässigt jobbat med programutveckling i ca 35 år inom DOS, Win16, Win32 och .NET).

[Christer]

Visst spelar arvet en stor roll. Men även vilka verktyg som utvecklingsmiljön erbjuder, vilket jag inte personligen har insikt i.

Jag har registrerat ditt förslag i vårt ärendehanteringssystem. Sen återstår att bedöma vilken arbetsinsats som krävs och vilken nytta ändringen tillför. I en värld med ideella krafter och begränsade resurser är prioriteringen minst lika viktigt som i den kommersiella.