MacOSLib and CocoaMenuItem

I’m using the CocoaMenuItemPasteAndMatchSytyle class from MacOSLib. It’s created in IDE Menu. I’d like to intercept this event so I can make sure I can normalize any decomposed Unicode before the paste is completed. However, I can’t seem to find any way to do this except in the CocoamenuItemPasteAndMatchStyle.ActionSelectorName event (Xojo Menu Handlers don’t fire when this option is selected). I can put the code in the selection event, but I hate to modify MacOSLib itself. My question is, can I intercept this event outside of MacOSLib?

That is not the right thing to handle
That event is raised by the Cocoa Menu Item super to ASK what selector should be used for the item
Subclass the CocoamenuItemPasteAndMatchStyle menu item in your project and implement the action event instead
Then add your subclass to the menu bar

Thank you, I’ll try that.

Norman, I subclassed CocoamenuItemPasteAndMatchStyle and have inserted it in the Edit menu bar, like this

dim m as PasteAndMatchStyle //the subclass
m = new PasteAndMatchStyle
m.name = "PasteAndMatchStyle"
m.text = "Paste And Match Style"
EditMenu.Insert(6, m)

However, the Action event never fires when I select it (the paste occurs, but it bypasses the Action event). Any ideas why that is?

Some menu selections are handled by the OS level control & not given to you to handle at all
That’s the only thing I can think of

OK, thanks. So it looks like I’ll have to modify MacOSLib to get this functionality.

If its already selector that the control responds to that won’t make any difference
The control likely catches it before you ever get any way to respond to it

Why not insert a plain menu item with that title & respond to it like any other ?

Actually, I can trap it in the CocoamenuItemPasteAndMatchStyle.ActionSelectorName event.

Maybe I’m missing something, but it it’s just another menu item I have to handle enable/disable for every window with a text field/area, as well has have a menu handler for each window (or text control). I did that in Carbon, but with Cocoa it’s all handled by the OS, much easier. I never had a problem with that approach (in Cocoa) until now.

Right and controls that CAN actually handle the selector WILL
You don’t have to do anything

I think we may be talking at cross purposes here. To restate the problem…I am currently using the Cocoa selector mechanism and it works great. I now want to be able to trap the selection of Edit -> Paste And Match Style so that I can check if the clipboard contains decomposed Unicode (so I can replace it with normalized Unicode before the paste occurs). I’ve found that I can’t trap the menu Action event even if it’s subclassed. The only place I have found that I can intercept the menu selection event before the paste occurs is in the CocoamenuItemPasteAndMatchStyle.ActionSelectorName event, in MacOsLib.

I see no solution except to (1) to modify MacOSLib’s ActionSelectorName event, or (2) go back to the way I handled this in Carbon, which was to make Paste And Match Style a regular MenuItem and explicitly add code in my subclassed text areas and text fields to enable/disable as appropriate, normalize the clipboard text if necessary, and replace the .SelText. I think option (2) is what you’re suggesting above.

You can add an event handler for “Action” to the menuitem if that’s what you’re lookin for.

Nevermind. Doesn’t seem to fire…

I think the better question is why you’re trying to intercept paste. If normalization is your goal, it really needs to be done when you read data out of the text area. There are a number of things that can cause text to be entered into a text area, like accessibility and scripting, that you won’t be able to intercept.

There is another way around. Use a timer to check the content of the clipboard regularly. If it contains decomposed Unicode, replace with normalized Unicode. So instead of doing it in the paste, you do it when it appears in the clipboard. And you do not need to trap paste.

Timers waste battery life and programs, in my opinion, should never silently modify the user’s clipboard.

What about using a regular menuitem and in the menuhandler, do your validation and then call pasteAsPlainText on the textarea?

Something like this

[code]Function pasteAsPlainTextMenu() As Boolean
///validation code here

declare sub pasteAsPlainText lib “Cocoa” selector “pasteAsPlainText:” (obj as ptr,from as ptr)
declare function documentView lib “Cocoa” selector “documentView” (obj as ptr) as ptr
pasteAsPlainText(documentView(ptr(TextArea1.Handle)),ptr(pasteAsPlainTextMenu.handle(menuitem.HandleType.CocoaNSMenuItem)))
Return True

End Function
[/code]

Thanks, all, for the helpful comments.

I actually do normalize unicode (if necessary) when the text is saved to the database (Valentina in my case). The reason I wanted to do that on Paste, in addition, is that the field can have existing styled text (which I save as RTF), and when I normalize unicode on save I remove all styles (empty the RTF). Some users object to this (to them mysterious) lost of styled text when the field is next rendered. In thinking about this some more, I probably can leave the styled text (RTF) alone. The reason to normalize unicode is to make sorting and searching for naked text uniform, the styled text rendering can use either precomposed or decomposed UTF-8 (in the RTF), that won’t affect the user at all.

Very interesting discussion, thanks!