Henning Thielemann wrote:
> Heinrich Apfelmus wrote:
>> You can use the  textCtrlEx  function and pass additional style flags to
>> it to create text controls with the old behavior. I think the previous
>> source code was
>>   textCtrlEx parent (wxTE_MULTILINE .+. wxTE_RICH2) props
> I see. It sounds reasonable, too. Unfortunately switching back to this 
> line does not work. Even if it would, it would bypass the improvement that 
> was introduced with the last patch.

The idea would be to keep the source as it is, but use the  textCtrlEx 
function instead of the ordinary  textCtrl  function in the cases where 
you desire a text entry field with a monospace font.

> There were not many lines that changed, so I tried to revert them one by 
> one and found that this change caused the problem:
> -            (\tc -> (textCtrlGetValue tc, \s -> do textCtrlClear tc; 
> textCtrlWriteText tc s)) $
> +            (\tc -> (textCtrlGetValue tc, \s -> do textCtrlChangeValue tc 
> s)) $

I made this change because the old version actually crashes on MacOS X 
in some circumstances...

> It may be related to my observation that the textCtrl sometimes chooses a 
> variable-space font if I enter text at the end of a text Ctrl in an 
> otherwise mono-spaced text. That is, it seems to be important _how_ a text 
> is inserted.
> Maybe this is even a Wx bug?

Most likely.

It seems that in order to support monospace font, the text entry control 
is converted to Rich Text Formatting, and then you have font control 
commands as part of the input data.

Best regards,
Heinrich Apfelmus


How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
wxhaskell-users mailing list

Reply via email to