Page 1 of 2 1 2 LastLast
Results 1 to 15 of 24

Thread: RichEdit: 'Alt->' toont chinese tekens in het edit veld.

  1. #1

    RichEdit: 'Alt->' toont chinese tekens in het edit veld.

    Hallo,

    Ik zit met het volgende probleempje: (Windows7, Delphi 10.2) Als ik durf meerdere keren Alt met een pijltjestoets drukken dan toont de RichEdit bij het intypen van het eerstvolgende 'normale' teken (dus zonder Alt) een of meerdere extra chinese tekens op de positie waar ik alt characters invoerde.

    Ik heb al getracht die Alt characters te inderdrukken in het "OnKeyDown" event (Key op 0 zetten), maar dat werkt niet, die tekens bereiken de RichEdit component toch blijkbaar.

    Er komt geen OnKeyPressEvent bij het ingeven van een Alt teken.

    Extra info:sommige Alt tekens (o.a. Alt linkse pijl) worden in mijn programma gebruikt als shortcut keys, dus ik kan die toesencombinatie niet helemaal onderdrukken (moest ik al weten hoe dat te doen).

    Ik zoek eigenlijk een methode om te zorgen dat Alt codes enkel de Rich edit niet bereiken, ook als is die Richedit de actieve control.

    Iemand enig idee?

    Bij voorbaat dank!
    Vriendelijke groeten,
    Dany

  2. #2
    Niet geprobeerd maar wellicht:
    - keypreview aan zetten op je main form
    - in het OnKeyDown event ssAlt uit de Sift state gooien wanneer Richedit ActiveControl is?

  3. #3
    Code:
    procedure TForm1.FormKeyDown(Sender: TObject; var Key: Word;
      Shift: TShiftState);
    begin
      if ssAlt in Shift then
      begin
        Shift := Shift - [ssAlt];
      end;
    end;

  4. #4
    Welbedankt voor de tips!

    Na enig experimenteren kwam ik tot de volgende oplossing:

    Code:
    procedure TForm1.RichEdit1Change(Sender: TObject);
    var TmpStr: string;
        Corr: Integer;
    begin
      if AltKeyPressed then
      begin
        AltKeyPressed := false;
        Corr := RichEdit1.ActiveLineNo; // CRLF is counted as 1 character in stead of 2
        TmpStr := RichEdit1.Text; // get the messed up text
        Delete(TmpStr, TmpSelStart + Corr + 1, RichEdit1.SelStart- TmpSelStart); // delete rubbish
        Insert(TmpChar, TmpStr, TmpSelStart + Corr + 1);  // insert last pressed character
        RichEdit1.Text := TmpStr; // restore text
        RichEdit1.SelStart := TmpSelStart + 1; // restore cursor position (+1 for the last pressed character)
      end;
    end;
    
    procedure TForm1.RichEdit1KeyDown(Sender: TObject; var Key: Word;
      Shift: TShiftState);
    begin
      if (Key = 18) then // the ALT key
      begin
        TmpSelStart := RichEdit1.SelStart;
        AltKeyPressed := true;
      end;
    end;
    
    procedure TForm1.RichEdit1KeyPress(Sender: TObject; var Key: Char);
    begin
       TmpChar := Key; // last pressed key
    end;
    
    begin
      AltKeyPressed := false; // initialisation
    end.
    Bij het drukken van de ALT toets haal ik de waarde van RichEdit.SelStart op, en daarna, bij het drukken van een gewone toets haal ik opnieuw die waarde op en laat alles tussen de 2 waardes weg in RichEdit.Text.

    Ik heb wel iets raars moeten doen voor het "nieuwe regel" teken: dat zijn 2 chars (CR en LF) maar SelStart telt dat maar voor 1 teken.

    Hopelijk zitten hier geen addertjes meer onder het gras? Zijn er nog bv tekens die afwijkend geteld worden?
    Vriendelijke groeten,
    Dany

  5. #5
    Quote Originally Posted by Dany View Post
    Zijn er nog bv tekens die afwijkend geteld worden?
    Tekens die bestaan uit 3 chars misschien. Of 4.

    Ik vind het originele probleem overigens ook heel raar en kan me niet herinneren dit ooit tegengekomen te zijn. En ik maak veelvuldig gebruik van de TRichEdit.

    Weet je zeker dat het geen andere reden heeft?

    Kun je een testprojectje maken waarbij dit probleem zich voordoet want met een simpel leeg project met TRichEdit kan ik het niet nabootsen.

    Of heb je een bepaald toetsenbord indeling onder Windows geïnstalleerd die Chinees ondersteund

    Ik hen het gevoel dat je nu vreselijk onhandig een oplossing hebt voor het gevolg en niet de oorzaak aanpakt.

  6. #6
    Bedankt Rvk!

    Hierbij het project dat ik gebruikte om de oplossing te testen (dus even de Richedit events verwijderen als je het probleem wil zien, druk wel de pijltjestoets meermaals in terwijl je de ALT toets ingedrukt houdt).

    Of heb je een bepaald toetsenbord indeling onder Windows geïnstalleerd die Chinees ondersteund
    Niet dat ik weet...

    Ik heb het gevoel dat je nu vreselijk onhandig een oplossing hebt voor het gevolg en niet de oorzaak aanpakt.
    Hm, ja. Ik moet er in elk geval voor zorgen dat de ALT pijltje events elders in het programma nog beschikbaar zijn. Ik mag dus niet zomaar het event, bv in het main form, wijzigen.
    Attached Files Attached Files
    Last edited by Dany; 05-Jan-19 at 17:42.
    Vriendelijke groeten,
    Dany

  7. #7
    Is dit misschien iets?

    How to change between keyboard input languages in Windows 7
    You can also use the keyboard shortcut Left Alt + Shift to achieve the same result.

  8. #8
    Quote Originally Posted by Dany View Post
    Hierbij het project dat ik gebruikte om de oplossing te testen (dus even de Richedit events verwijderen als je het probleem wil zien, druk wel de pijltjestoets meermaals in terwijl je de ALT toets ingedrukt houdt).
    Ah, ik zie nu wat je bedoeld. Raar. Bij mij is dat nooit een probleem geweest.

    Maar ik krijg inderdaad ook rare tekens.

    Name:  7BJgHvn.png
Views: 358
Size:  1.5 KB
    Name:  uPi39VP.png
Views: 365
Size:  1.5 KB
    Name:  MD9qBMd.png
Views: 354
Size:  1.3 KB

    Toch denk ik dat het aanpassen van de richedit inhoud achteraf niet de juiste manier is. Ik weet even zo 123 niet hoe dit op te lossen maar Wordpad heeft het probleem niet (en die maakt volgens mij ook nog gebruik van RichEdit dll, dacht ik).

    to be continued...

    PS. TRichMemo in Lazarus heeft dit probleem niet. Dus het zou ook iets kunnen zijn in Delphi (of er is in Lazarus TRichMemo omheen gewerkt).
    Last edited by rvk; 06-Jan-19 at 02:08.

  9. #9
    Welbedankt.
    Vriendelijke groeten,
    Dany

  10. #10
    Ok, tot zover weet ik dat het dus toch echt aan de RichED20.DLL ligt.

    In Lazarus had ik het probleem niet bij de TRichMemo maar dat kwam omdat deze standaard de nieuwere Msftedit.dll laadt. Ik heb dat even onderdrukt zodat ook deze de RICHED20.DLL pakt en dan heb ik het Alt-probleem daar ook.

    Delphi Code:
    1. {if LoadLibrary('Msftedit.dll') <> 0 then begin
    2.   GlobalRichClass := 'RichEdit50W';
    3. end else} if LoadLibrary('RICHED20.DLL') <> 0 then begin
    4.   if UnicodeEnabledOS then GlobalRichClass := 'RichEdit20W'
    5.   else
    6.   GlobalRichClass := 'RichEdit20A'
    7. end else if LoadLibrary('RICHED32.DLL') <> 0 then begin
    8.   GlobalRichClass := 'RichEdit';
    9. end;

    Dus het is een 'feature' van RICHED20.DLL zelf. Misschien onderdeel van de Alt+unicodegetal tikken.

    Je kunt in Delphi natuurlijk ook de nieuwere Msftedit.dll proberen te laden maar volgens mij is dat niet zo makkelijk.

    Volgende stap is dus inderdaad ervoor te zorgen dat de Alt de RichEdit niet bereikt. Maar dit kan ook weer een probleem geven met geldige Alt codes (zoals de Alt+0128 die ik vaak gebruik om het Euro-teken te gebruiken).

  11. #11
    In OnKeyPress alles weggooien wat niet west-europees is?
    Beetje bot, maar zou moeten werken.

    Of overstappen op Lazarus ;-)

    Bart

  12. #12
    Je kunt je ook afvragen in hoeverre dit een probleem is. In al mijn jaren met gebruik van RICHED20.DLL heeft nog geen enkele gebruiker van mijn programma hierover iets opgemerkt.

    Als ik mij Windows XP VM even start zie ik dat het in Wordpad daar ook is. De nieuwe Wordpad onder Windows 10 maakt ook gebruik van Msftedit.dll maar die van Windows XP maakt nog gebruik van RICHED20.DLL. Daar krijg ik dan echter wel kleine vierkantjes te zien (of vierkantjes met een vraagteken) omdat het lettertype de karakters waarschijnlijk niet goed ondersteund (ook de Calibri). Als ik die blokjes weer kopieer naar Windows 10 zie ik de bekende karakters weer.

    Ik kan ook geen structuur vinden in het gebruik van die Alt+(meerdere malen)Arrow en letter.

  13. #13
    Volgende stap is dus inderdaad ervoor te zorgen dat de Alt de RichEdit niet bereikt. Maar dit kan ook weer een probleem geven met geldige Alt codes (zoals de Alt+0128 die ik vaak gebruik om het Euro-teken te gebruiken).
    Welbedankt voor het uitzoeken. De geldige ALT-unicodes zijn inderdaad een probleem, met mijn voorgestelde oplossing verlies ik die mogelijkheid...
    Blijkbaar verlies ik toch niks want Richedit (zover ik kan testen) begrijpt bv ALT-0128 niet...
    Last edited by Dany; 08-Jan-19 at 14:07.
    Vriendelijke groeten,
    Dany

  14. #14
    Je kunt je ook afvragen in hoeverre dit een probleem is. In al mijn jaren met gebruik van RICHED20.DLL heeft nog geen enkele gebruiker van mijn programma hierover iets opgemerkt.
    Bij mij zijn er natuurlijk wél klachten

    Als ik mij Windows XP VM even start zie ik dat het in Wordpad daar ook is. De nieuwe Wordpad onder Windows 10 maakt ook gebruik van Msftedit.dll maar die van Windows XP maakt nog gebruik van RICHED20.DLL. Daar krijg ik dan echter wel kleine vierkantjes te zien (of vierkantjes met een vraagteken) omdat het lettertype de karakters waarschijnlijk niet goed ondersteund (ook de Calibri). Als ik die blokjes weer kopieer naar Windows 10 zie ik de bekende karakters weer.
    Ik kan ook geen structuur vinden in het gebruik van die Alt+(meerdere malen)Arrow en letter.
    Bedankt voor het uitzoeken!
    Vriendelijke groeten,
    Dany

  15. #15
    In OnKeyPress alles weggooien wat niet west-europees is?
    Beetje bot, maar zou moeten werken.
    Ik gooi nu alles weg wat ingetikt is tijdens het indrukken van de ALT toets, dus tot mijn spijt ook geldige unicode (vb alt-0128). Ik kan geen onderscheid maken tussen geldige and niet geldige codes, en wat West Europees en niet West Europees is.
    p.s. RichEdit OnKeyPress wordt niet aangeroepen tijdens indrukken van de ALT key, enkel bij 'normale' keys denk ik.

    Of overstappen op Lazarus ;-)
    Hm.
    Last edited by Dany; 08-Jan-19 at 14:10.
    Vriendelijke groeten,
    Dany

Page 1 of 2 1 2 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •