Eto: [WPF] تحديد RichTextArea لا يعمل بشكل صحيح

في Windows ، لا يتم حساب أحرف نهاية السطر بطريقة أو بأخرى إلى فهارس التحديدات. أنا حاليًا أستخدم الكود التالي كحل بديل:

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);
        }

لكن هذا بالتأكيد خطأ ...

نعم لقد استخدمت نفس الاختراق مثل @ ManuelHu من قبل ، إنه ليس جميلًا. لست متأكدًا حتى الآن من كيفية معالجة هذا الأمر بشكل فعال دون أن تكون بطيئًا عند استخدام نص كبير.

شكرا للإبلاغ عن هذه المسألة!

مرحبًا DanWBR ،

يجب إصلاح هذا في أحدث فرع تطوير. هل يمكنك أن تجربها؟ على جميع الأنظمة الأساسية ، يتم التعامل مع الأسطر الجديدة الآن على أنها حرف \n .

مرحبًا cwensley ، لا يزال هناك شخصية واحدة يجب إصلاحها:

مرحبًا DanWBR ، هل لديك وصف للخروج من خلال إصدار واحد؟ لا يمكنني إعادة إنتاجه.

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

ربما أستخدم فهارس خاطئة؟ إنه يعمل على macOS و GTK ، رغم ذلك.

DanWBR ، آه نعم ، هذا لن يعمل بالطريقة التي لديك بها لسوء الحظ - يضيف WPF Text (بغض النظر عما إذا كان النص الخاص بك يحتوي عليه أم لا). لم أجد طريقة للتغلب على ذلك في هذه المرحلة ، لكنها قضية منفصلة عن هذه المشكلة.

ما أوصي به هو الحفاظ على الموضع الحالي في متغير وزيادته بعد إلحاق النص. الوصول إلى الخاصية Text كل مرة للحصول على الطول سيتباطأ كلما زاد حجم النص.