Eto: [WPF] La sélection RichTextArea ne fonctionne pas correctement

Créé le 4 oct. 2018  ·  7Commentaires  ·  Source: picoe/Eto

Comportement prévisible

Texte correctement sélectionné selon la plage définie.

Comportement réel

Il y a une erreur de placement de 5 caractères à droite.

Étapes pour reproduire le problème

  1. Créer un champ RichTextArea
  2. Saisir du texte
  3. Définir une sélection pour définir sa couleur

Code qui démontre le problème

rtfcontrol.Appen(initialtext, true);
rtfcontrol.Append(sometext, true);
rtfcontrol.Selection = new Range<int>(rtfcontrol.Text.Length - sometext.Length, rtfcontrol.Text.Length -1);
rtfcontrol.SelectionForeground = Colors.Blue;
rtfcontrol.Append("\n", true);
rtfcontrol.Selection = new Range<int>(rtfcontrol.Text.Length);

Caractéristiques

  • Version : 2.5.0-ci-10013
  • Plateforme(s) : WPF
  • Système(s) d'exploitation : Windows 10

WPF :

wpf

GTK2 (Linux) :

gtk2_linux

Xamarin.Mac :

xamarin mac

Commentaire le plus utile

@DanWBR , ah oui cela ne fonctionnera malheureusement pas comme vous l'avez fait - WPF ajoute une nouvelle ligne à la fin de la propriété Text (peu importe si votre texte l'a ou non). Je n'ai pas trouvé de moyen de contourner cela à ce stade, mais c'est une question distincte de celle-ci.

Ce que je recommanderais, c'est de conserver la position actuelle dans une variable et de l'incrémenter après avoir ajouté du texte. L'accès à la propriété Text chaque fois juste pour obtenir la longueur ralentira à mesure que le texte s'agrandit.

Tous les 7 commentaires

Sous Windows, les caractères de fin de ligne ne sont en quelque sorte pas comptés dans les indices des sélections. J'utilise actuellement le code suivant comme solution de contournement :

private void Write(string message, Color c)
        {
            Append(message + Environment.NewLine, true);

            int idx = -1, last = -1;
            if (Environment.OSVersion.Platform == PlatformID.Unix)
            {
                idx = Text.LastIndexOf(message);
                last = Text.Length;
            }
            else
            {
                var lines = string.Join("", Text.Split(new[] { '\r', '\n' }, StringSplitOptions.RemoveEmptyEntries));
                idx = lines.LastIndexOf(message);
                last = lines.Length;
            }

            if (idx == -1)
                return;

            Selection = new Range<int>(idx, idx + message.Length);
            SelectionForeground = c;
            Selection = new Range<int>(last, last);
        }

Mais c'est bien un bug...

Oui, j'ai déjà utilisé le même hack que @ManuelHu , ce n'est pas joli. Je ne sais pas encore comment résoudre efficacement ce problème sans être lent avec un texte volumineux.

Merci d'avoir signalé le problème !

Salut @DanWBR ,

Cela devrait être corrigé dans la dernière branche de développement. Pourriez-vous essayer ? Sur toutes les plateformes, les nouvelles lignes sont désormais traitées comme un seul caractère \n .

Salut @cwensley , il reste encore un caractère à corriger :

captura de tela 2018-11-16 as 08 06 39

@DanWBR , avez-vous un repro pour le problème par un ? Je n'arrive pas à le reproduire.

https://github.com/DanWBR/dwsim5/blob/windows/DWSIM.UI.Desktop.Forms/Forms/Flowsheet/Flowsheet.eto.cs#L1245

Peut-être que j'utilise de mauvais index ? Cela fonctionne cependant sur macOS et GTK.

@DanWBR , ah oui cela ne fonctionnera malheureusement pas comme vous l'avez fait - WPF ajoute une nouvelle ligne à la fin de la propriété Text (peu importe si votre texte l'a ou non). Je n'ai pas trouvé de moyen de contourner cela à ce stade, mais c'est une question distincte de celle-ci.

Ce que je recommanderais, c'est de conserver la position actuelle dans une variable et de l'incrémenter après avoir ajouté du texte. L'accès à la propriété Text chaque fois juste pour obtenir la longueur ralentira à mesure que le texte s'agrandit.

Cette page vous a été utile?
0 / 5 - 0 notes