FlowDirection RightToLeft in TextBox with text c:\ when language is Arabic

[deepakG86]

I am trying to create a WPF textbox that can take user input for a folder/network path. The textbox needs to support other languages including Arabic.

The flowdirection for the textbox gets set based on the language, so for Arabic the flow direction of text box is right to left.

Now, the issue is when I enter "c:". This gets displayed as "/:c".
But when we enter the next character, it switches correctly for example : "c:\a" is displayed correctly as "c:\a".

Same think when we have "(" or ")".

What is the best solution to handle this behavior?
I have tried to detect neutral characters in the text and inserting a LTR character but that has weird consequence:
c
c:
c:\ --- here i enter the special LTR marker
the next typed character goes to the other end:
ac:?

[miloush]

First of all, you should ask any native user of what is their preferred behavior rather than trying to fix a problem 1) the way you think is the best 2) might not even exist. For example, the same behavior is in Windows Explorer address bar, common file dialogs as well as browser address bars, it's a standard bi-directional rendering, and while I agree it's not the best, users might prefer consistency with the OS.

Second, if by LTR marker you mean U+200E LEFT-TO-RIGHT MARK, then these are just non-spacing characters with strong directionality that my skew the directionality of surrounding weak or neutral characters (symbols), but do not affect other characters with strong directionality (letters). You can use directionality overrides (discouraged for security reasons) or embeddings to mark the whole section of text as the directionality you want if really needed.

Third, how do you know whether to insert LTR marker or RTL marker? You can have "(" in both LTR and RTL context.

Last but not least, when inserting similar characters into strings like paths and URIs, you might be breaking path resolving and autocomplete experience.

What is the best solution to handle this behavior?

My answer would be don't do anything special unless you get request from the native users that they want something else.

[BpsTheCool]

First of all, you should ask any native user of what is their preferred behavior

I'm a RTL language (Persian) native user and that behavior is bothering me and every other native user I know!
It's just that we got used to it! But we absolutely love it being fixed everywhere!

[miloush]

@BpsTheCool Cool, it's bothering me too, don't get me wrong! But perhaps Unicode/OS is the place where fixes should be requested, if you have an algorithm in mind that would improve the situation.

As I suggested above, the implementation can ensure the path begins with LRE and ends with POP, but it comes with price of extra parsing when dealing with the input. Forcing the TextBox's FlowLayout to LeftToRight (and aligning the text right if desired) will have similar effect, because ultimately, the problem here is that you want paths to be treated as LTR, and the text box seems to be for paths only in this case.