Unexpected TextCtrl behaviour #1

Closed
jodonoghue opened this Issue Apr 18, 2012 · 7 comments

Comments

Projects
None yet
2 participants
Owner

jodonoghue commented Apr 18, 2012

(reported by Heinrich Apfelmus apfelmus@quantentunnel.de - see http://permalink.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/1191)

The more important issue is that TextCtrl widgets have changed their behavior: the entry function will now create a multiline widget!

To create a single-line text entry widgets, I have to use the textCtrlEx function with flag 0 .

This is extremely weird. Also, the latter widget sometimes crashes on me when trying to set the text, but the former doesn't. This is so weird that I can't even tell whether the problem is likely with wxWidgets or with the Haskell bindings.

Contributor

HeinrichApfelmus commented Apr 18, 2012

Concerning the multiline thing.

It appears that wxMac 2.9.3 interprets the wxTE_RICH flag differently from wxMac 2.8. The entry function was changed to use this flag in commit d0f2be4 as part of a change concerning text colors.

The main problem with this is actually that the TextCtrl widget is assigned a vanishing default width on creation.

Not sure what to do here. Escalate to the wxWidgets maintainers? The easiest fix for us would be to revert to the 0 flag.


Unfortunately, the text widgets is prone to crashes when writing text to it. Strangely, this mainly happens when the wxTE_RICH flag is not set.

Contributor

HeinrichApfelmus commented Apr 18, 2012

Concerning the crashes.

It appear that wxMac 2.9.3 is crashing whenever we try to write the text attribute, whose definition is basically

      ifInstanceOf w classTextCtrl
        (\tc -> (textCtrlGetValue tc, \s -> do textCtrlClear tc; textCtrlWriteText tc s)) $
        (windowGetLabel w,windowSetLabel w)

It appears that the combination

do textCtrlClear tc; textCtrlWriteText tc s

will crash, while the combinations

do textCtrlClear tc; textCtrlSetValue tc s
do textCtrlSetValue tc s

work just fine.

It may be worth to use the wxTextCtrl::ChangeValue function here because it doesn't raise a wxEVT_COMMAND_TEXT_UPDATED event, but that's another discussion best left to another issue.

Owner

jodonoghue commented Apr 20, 2012

I just did some experiments on the wxTE_RICH problem. It looks as though wxTE_RICH really does something on Mac - specifically, the colour doesn't work when I get rid of it. Will look further.

Owner

jodonoghue commented Apr 20, 2012

Fix pushed as patch f225d0c, although have opened new bug on TextCtrl colour support.

jodonoghue closed this Apr 20, 2012

Contributor

HeinrichApfelmus commented Apr 22, 2012

Awesome, thanks! If you could make a small bugfix release on hackage, then I can bump the wx dependency for reactive-banana-wx as I would like to avoid to ship it with broken examples.

Owner

jodonoghue commented Apr 22, 2012

I'll push all of last week's work on GitHub to Darcs and make a new release on Cabal once I have tested on Windows and Linux.

I'll try to do Linux today, but Windows will need to wait until I have access to a Windows box, as the Windows VM on my Mac is painfully slow.

Contributor

HeinrichApfelmus commented Apr 22, 2012

Great!

By the way, I plan to initiate several design discussions on the mailing list, but maybe I should wait a bit until the dust settles with respect to the Darcs / Github question and other things.

@Happy-Ferret Happy-Ferret pushed a commit to Happy-Ferret/wxHaskell that referenced this issue Jul 22, 2014

@jodonoghue jodonoghue Fix behaviour of textEntry and entry controls on OSX.
See jodonoghue/wxHaskell#1 (comment)

It seems that using the wxTE_RICH attribute in textEntry and entry causes a multi-line text control style to be created by default on OS X. This is new behaviour on wxWidgets 2.9.x.

This patch makes the wxTE_RICH and wxTE_RICH2 attribute settings dependent on the host OS (only sets them on Windows)

This patch also fixes bugs associated with the use of textCtrlClear followed by textCtrlWriteText, reported in the same issue.

Note that this does not fix the problem that the textColor attribute is not respected.
f225d0c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment