Aldfaerscherm laat geen UTF codes meer zien

Ik heb sinds de aanschaf van een nieuwe PC (Win11 Pro, Nederlands) hetzelfde probleem. Wat mij opviel bij de installatie, is dat de map Documenten\Aldfaer\Veiligheidskopieën wordt aangemaakt met een "ruitje met vraagteken" in plaats van ë, evenals bij de instellingen van Aldfaer. Dit kan ik eenvoudig wijzigen, zowel in Windows als in Aldfaer. Wanneer ik datzelfde probeer bij een ruitje voor een datum met ± (Alt-0177) dan verdwijnt de gehele invoer uit het veld. Dat gebeurt ook wanneer ik probeer het ruitje te vervangen door "ca". De IE11 modus staat bij installatie overigens ingesteld op "standaard DOCTYPE". In de rapporten wordt het ruitje voor de datum keurig omgezet naar "omstr." of "omstreeks".

AANVULLING:
In voor- en achternamen worden de speciale tekens wel goed weergegeven, zowel in de Personenlijst als in de persoonskaart. Wat mij ook opvalt, is dat voor de plaatsnamen in de Personenlijst ook een ruitje met vraagteken wordt weergegeven, terwijl dit op de persoonskaarten niet het geval is. In de rapporten worden de speciale tekens in namen correct weergegeven, evenals de plaatsnamen. 
Voor zover ik nu kan overzien, wordt het ruitje alleen geplaatst bij een omstreeks datum en voor de plaatsnamen in de Personenlijst.
 

Michaël,

probeer eens met de taalsetting Englsh (United States) te verwijderen en pc herstarten.

Helaas pindakaas!
Ik heb de UK en US toetsenbord-definities verwijderd. En de PC herstart. Maar, noch voor de gegenereerde rapporten, noch voor het hoofdscherm maakt dit enig verschil. Helaas.

Michaël

Ik heb nog eens verder gekeken in de Personenlijst. Elke overlijdensdatum wordt voorafgegaan door een ruitje met vraagteken, met uitzondering van begrafenis/crematiedatums, soms zelfs met twee ruitjes. Dus ook bij correcte datums volgens het dd-mm-jjjj format. Datzelfde geldt voor plaats van overlijden, ook nu met uitzondering van plaats van begraven/crematie. Volgens mij gaat het hier om een beperkt aantal bijzondere tekens, die niet met een standaard ALT-code kunnen worden opgenomen: Alt-0xxx, zoals ✶ (Alt-10038) en ✝ (Alt-10013), hoewel dus ook ± (Alt-0177) niet werkt. In ieder geval voor mij werken alle Alt codes tussen 0192 en 0255 wel. Ook de balk met kolomnamen laat hetzelfde beeld zien.
Volgens mij is dit toch een probleem dat waarschijnlijk bij de nieuwste versie (11.1) van Aldfaer ligt. Ik heb dit probleem in geen enkele andere applicatie.
 

Dag Alle,
Ik moet je in mijn geval tegenspreken. Ik heb een aantal maanden met Aldaer 11.1 gebruikt, zonder dat dit probleem bestond.

Ik heb het idee dat er een essentieel bestand of Registry instelling is gewijzigd buiten Aldfaer om. Het probleem is om te achterhalen welk bestand of welke instelling hier gewijzigd is. Kennis van hoe Aldfaer omgaat met speciale karakters op het scherm en in rapportages kunnen misschien helpen om te weten waar ik moet kijken.

Michaël

Dag Michaël,

In de registry zijn geen instellingen opgenomen voor Aldfaer. Ook essentiële bestanden (Aldfaer.exe.manifest, Aldfaer.ini en Aldfaer.iniprogram) bevatten niets wat de oorzaak zou kunnen zijn. Tot het tegendeel wordt aangegeven, ga ik er van uit dat Aldfaer.exe hier het probleem vormt. Ik heb Scandinavische roots en kan zelfs de A-ring en a-ring (Alt-134 en Alt-143, zonder 0) niet invoeren.

Groet, Alle

Wie weet? Hebben jullie deze Windows instelling al bekeken:How to set UTF-8 encoding in Windows 11?Set a process code page to UTF-8

To configure your app to render UTF-8 text via GDI, go to Windows Settings > Time & language > Language & region > Administrative language settings > Change system locale, and check Beta: Use Unicode UTF-8 for worldwide language support. Then reboot the PC for the change to take effect.[/color][color=var(--IXoxUe)]20 Aug 2024[/color]Bij mij is Beta: Use Unicode UTF-8 ........unchecked.

Michaël Boers schreef :

Dag TR,
Dat is nog niet zo eenvoudig. De enige rapporten die ik uit december bewaard heb, bevatten AVG-gevoelige info, die ik hier dus niet kan delen.
Dan zou ik dat rapport eerst moeten gaan editen, maar dan kan juist de essentiële info uit het rapport verdwijnen.
Ik heb nog wel een HTML-bestand dat ik in juli 2024 met Aldfaer 10.1 heb gemaakt. Als dat helpt.

Michaël

 

1.
Ik probeer door het vergelijken van 2 rapporten te achterhalen in welke richting we moeten zoeken.
Als je het rapport van juli 2024 nog eens zou willen draaien, dan levert de vergelijking misschien een aanknopingspunt op.

2.
Ik kom bij het zoeken naar oorzaken een mogelijkheid tegen die je meteen simpel kunt uitsluiten (of bevestigen) (onder het motto nee heb je, ja kun je krijgen).
Er zijn programma's (bijvoorbeeld bepaalde versies van chrome) die storend werken bij alles wat met unicode te maken heeft onder de conditie dat die stoorzender na het opstarten van de pc als eerste te maken krijgt met unicode-tekens.

De work-around is dan als volgt.
Plaats een snelkoppeling met japanse (unicode) tekens in de naam op het bureaublad.
Dan zal windows verkenner (windows explorer) de eerste zijn die na of tijdens het opstarten van de pc met unicode te maken krijgt.

Probeer eens een snelkoppeling op het bureaublad te maken met de naam きぼう.lnk
Ik hoop dat de tekens gewoon vanaf deze pagina gekopieerd en geplakt kunnen worden.
Volgens google translate staan de letters voor: hoop.
Mogelijk werkt ook een (leeg) tekstbestand met de naam きぼう.txt
Hierna dus de pc herstarten.

Bron:
superuser.com/questions/520355/permanent...g-correctly-as-boxes

Groet,

TR
 

De instelling die JayCee beschrijft is ook onder windows 10 beschikbaar, echter niet bij alle of oudere versies.

Groet,

TR
 

Dank je wel, JayCee!
Dat was de oplossing voor mij! Waarom moet het allemaal toch zo moeilijk zijn?
Groet, Alle.

Alle,

Goed dat het opgelost is.
Ik gebruik nog steeds W10 en heb nooit problemen ondervonden met UTF codes. Het vinkje stond standaard uit en zodoende niet gewijzigd. Hoe stond het standaard bij u?

Dag JayCee,

Die instelling stond bij mij standaard aan, en heb ik uit moeten zetten.

Groet, Alle.