zijn rapportteksten in UTF-8?

@JayCee,
dank voor de tip, in dit geval gaat het over platte tekst .

het gaat niet om de _SETBEGI enz. Het gaat om de _FILEMODE("txt", overwrite) die vóór de _WRITBEGI staat.

Als het daarom ligt is het foutje snel verholpen.
Overigens:
_FILEMODE("text", OverWriten)
geeft geen foutmelding, het rapport wordt gewoon gemaakt.
bij:
_FILEMODEN("txt", OverWrite)
wordt het rapport ook gewoon weggeschreven.
Ik vraag me af welke invloed eea heeft op het wegschrijven.
PS op een Windows 10 computer

de Tagnaam/syntax die u gebruikt bestaat niet. Het moet _FILEMODE("txt", overwrite) zijn. Zie eventueel de handleiding voor sjablonen.

dus om precies te zijn is het:
_FILEMODE("txt", overwrite)
_WRITBEGI
hallo Daniël en Izaäk, alles oke?
_WRITEND

Dat heb ik gedaan, met wisselend sukses, mi is er meer aan de hand.
De niet bestaande codes zoals genoemd gaven geen foutmelding en genereerden het rapport, daarom vroeg ik me af wat hun invloed is.

Of er meer aan de hand is ligt aan andere factoren in uw script.
Als u foutonderkenning wilt zult u de Tag _ON en _OFF moeten gebruiken om te zien waar iets afbreekt. Maar als een Tag verkeerd geschreven is, wordt die niet als Tag gezien, dus is het gewone tekst.

U begon het draadje met een stelling en daar is mij dunkt afdoende antwoord op gegeven.

Welke stelling?
Mijn vraag is: samenvattend, waarom wordt er in sommige gevallen (voor mij niet te reproduceren) de umlauten wel of niet goed getoond?
U zegt dat ligt aan: het gaat niet om de _SETBEGI enz. Het gaat om de _FILEMODE("txt", overwrite) die vóór de _WRITBEGI staat. (vet van mij) en
Of er meer aan de hand is ligt aan andere factoren in uw script.
en wat zijn die andere factoren dan?

Mijn klomp breekt, het zal wel aan de hitte liggen....U begint dit draadje met de stelling

Francke schreef : _WRITBEGI
hallo Daniël en Izaäk, alles oke?
_WRITEND
geeft als tekst output: hallo Daniël en Izaäk, alles oke?

Is er een mogelijkheid het tekstbestand in UTF-8 mode weg te schrijven, zodat ä ë etc behouden blijven?

en nu verzandt het in een andere zaak dat u onder meer zegt dat het niet te reproduceren is.

Nou die klomp van mij ook.

Dag Francke,
Mijn klompen heb ik toch nog maar een keer opgezocht en aangetrokken.
Het onderwerp is "Zijn rapportteksten in UTF-8?"
Daarop is mijn antwoordt JA.
De extensie dat aan het bestand is gekoppeld middels _FILEMODE("extentie", optie )
Vervolgens zal Windows het bestand met de juiste programma dat is geassoceerd met de extensie uitvoeren.
Indien dit programma niet UTF-8 kan afhandelen dan zal de tekst "hallo Daniël en Izaäk" getoond worden als "hallo Daniël en Izaäk"
Indien de txt extensie wordt gebruikt en txt is in Windows gekoppeld aan Kladblok dan wordt dit juist weergegeven.
Een extensie die aan geen enkel programma is geassocieerd zal Windows komen met "Hoe wilt u dit bestand openen".

Los van het feit of ik nu een stelling, vraag of een opmerking maakte het volgende.

Ik constateer dat in EdtPad (Windows 1252: Western European) de diakrieten niet altijd goed worden weergegeven, dit geldt ook van de Crimson editor, in sommige andere editors zijn er geen problemen.
Hoe kan dat dan en waar ligt dat dan aan?
Dit is in het kort een samenvatting van mijn vragen en ik heb geen antwoord gehad.
@M. van Slageren.
1. de txt extensie is aan elke (platte) teksteditor te koppelen, niet alleen aan Kladblok.
2. achter _WRITBEGI gaat een schrijf-functie schuil die het bestand encodeert naar UTF-8 of UTF-16 en als zodanig wegschrijft, zodat bij openening vh bestand alles goed leesbaar is, zoals bv de diakrieten.
3. EditPad kan bijna elke encodering aan, zie Convert -> Text Encoding

PS
Trouwens de help van Aldfaer 7 heeft het over UTF-16, zie Opslag van gegevens

1. Ik heb nog niet kunnen constateren dat de diakrieten verkeerd worden weergegeven. Kan je me een reproduceerbaar voorbeeld toesturen (sjabloon + Aldfaer-bestand) waarbij dit het geval is?

2. Opslag van gegevens gaat over de interne representatie in het aldf-bestand. Dat is iets anders dan de codering van de rapporten.

Paul