Hi, proviso: this is my first mail to a Pharo list. I guess that it is pertinent for the pharo-dev list, since it describes a possible failure in Pharo 4 and an enhancement suggestion. If this mail is better suited for the pharo-users list, or else it should be better addressed to both lists, please let me know. Thanks! ---------------------------------- I just upgraded an application from Pharo 3 to Pharo 4. In this application, we use StrikeFont class>>fromUser:allowKeyboard: to let the user choose the point size of the font in a PluggableTextMorph. In fact, the size is applied to the selected part of the text only, so that we allow the edition of a text mixing different point sizes, and also bold, italics and underline. I hope to be able to publish shortly a button row that adds this capability to a given PluggableTextMorph. The mentioned method, StrikeFont class>>fromUser:allowKeyboard:, builds a menu where a check box is added to each option. This menu is told the currently selected point size, to propose it as pre-selected value. To build such a menu, the options are Associations (Boolean -> String), where the boolean is true for the option to be pre-selected, instead of just Strings. This works OK in Pharo 3. But in Pharo 4, we get an error when using StrikeFont class>>fromUser:allowKeyboard:. The reason lies in MenuMorph>>addToggle:target:selector:getStateSelector:enablementSelector:argumentList:, where the message translated is sent to the first parameter. This parameter is assumed to be a String, whilst in this case it is the Association I just mentioned. I provisionally patched this issue by modifying the class method in StrikeFont, in order to give the menu Strings instead of Associations. As far as this way of selecting a point size is still usable, it would be nice to have this issue fixed. If there is another, maybe more modern, way of graphically choosing a point size, please let me know. We had another problem to obtain a mix-style PluggableTextMorph. When the Text is accepted, the model is given actually a style-less Text, this is explicitly established in PluggableTextMorph>>acceptTextInModel. I guess that such is convenient when the Text being edited is code, so that the styles are automatically set by the editor, and must not be present in the code of a method. But in our case, it is the user that establishes the styles, so that they must be preserved. I created a subclass of PluggableTextMorph, in which the Text is passed unchanged to the model. If there is a better way to solve this issue, please tell me. Please consider the possibility of creating a specific CodeTextMorph in order to deal with the peculiarities of the code edition, instead of mixing them in the would-be-generic PluggableTextMorph. Cordially - Carlos Lombardi