Apache OpenOffice (AOO) Bugzilla – Issue 111775
[MAC OSX] Can't paste to Base form text fields in readonly documents/forms
Last modified: 2017-05-20 10:47:43 UTC
In OOo 3.2 Base on Mac OSX 10.5 you cannot paste anything from the clipboard to any text field within a Base form - neither by keyboard shortcurt nor by selecting "Paste" in the "Edit"-menu. Apart from that, copy and paste works within and across other OOo-applications (tried Writer and Calc). Copying highlighted text from a Base form and pasting it elewhere (e.g. in Writer) also works. Only paste doesn't, no matter where the content of the clipboard has been copied from (another OOo-application, any other application or the same Base form). It used to work in OOo 3.1.1. My system: MacBook Pro Mac OS X Version 10.5.6 CPU: 2.5 GHz Intel Core 2 Duo RAM: 2 GB 667 MHz DDR2 SDRAM I tested on another Mac: iMac: Mac OS X Version 10.5.8 CPU: 2.66 GHz Intel Core 2 Duo RAM: 4 GB 1067 MHz DDR3 Same problem here. Steps to reproduce: Create any simple test database (internal HSQLDB) under 3.2 on Mac OSX (just quickly clicked together through the Base wizard) including a form and try to paste text from the clipboard to a text field within the form (btw: the issue also occured with a MySQL database connected via jdbc). In OOo Base 3.2 Windows version everything works fine. In reply to my forum post about this: http://user.services.openoffice.org/en/forum/viewtopic.php?f=17&t=30813&sid=0da70a87b791e28e74d5959092f64503 lgusaas confirmed this behaviour - so it's most likely a bug.
Same behaviour with Mac OS 10.6.3 using OOo 3.2.1rc1 and OOo-dev 3.3.0 DEV300m78(Build:9501). Larry Gusaas
I can reproduce this. The text field needs to be bound to a database field As a workaround you can use the PASTE command in the context menu of the text field
I'm seeing similar behavior in form textboxes that are bound to database fields. Cmd-V inside the textbox doesn't work, but the context menu's version of Paste does. I got it working for a little while by going into Customize and setting Paste to Cmd-V for Base: Design View, but that stopped working when I closed the window and opened it again. (The customized keys are still defined, but they don't actually work. I checked.) Another data point: I use TextExpander ( http://www.smileonmymac.com/TextExpander/ ) to expand short strings into longer phrases; it modifies the clipboard as part of its operations. Whenever I type a short string that it's supposed to expand, TE gets as far as clearing the short string out, but when it pastes the long phrase, that paste never shows up.
cannot reproduce, neither in OOo 3.2.1, nor in OOO330.m7 (to-be 3.3). MaxOS X 10.5.8. Created a new text document, inserted a form control, switched off design mode, typed some text into the document, copied this text to the clipboard using Cmd+C, focused the form control, pasted the text using Cmd+V. Works like a charm. Anybody having more specific instructions on how to reproduce this?
re: fs's comment The problem seems to be specific to Base forms, and as msc comments above, controls that are tied to a database field. I was also able to paste (using Command-V) into a textbox created in Writer, but not in Base forms. (Using OO 3.2.1 on Mac OSX 10.5.8)
Ah, I missed that "bound to a database field" thing, thanks for the hint. Will try.
it hasn't to do with being bound to a database field. Instead, it is caused by the complete text document being read-only. That is, if you open a database form for editing, and switch off the design mode, you also have text fields bound to a database field. There, Cmd+V works just fine. But if you open this text document read-only (which happens, for instance, when you double-click a form in a database document, but you can also show this by switching a standalone document to read-only), then Cmd+V does not work in any text field in this document, no matter whether the field is bound or not. Adjusting summary accordingly. Grabbing back.
fs->pl: This seems to be a problem of the key event handling on Mac/Aqua: Normally, Edit controls paste clipboard content by reacting on the KEYFUNC_PASTE key input event (see Edit::ImplHandleKeyEvent). However, for a form control, this key event never arrives. (The fact that Cmd+V nonetheless works *nearly* all the time is because Cmd+V is an accelerator for the .uno:Paste command, and the form shell intercepts this command when an input control is focused. Thus, when the document is read-only, this UNO command is disabled, so Cmd+V does not work in exactly this case.) It seems that in [VCL_NSApplication sendEvent:], where the main menu is asked whether it can handle the event (the call to "[pMainMenu performKeyEquivalent:]" in vcl/aqua/source/app/vclnsapp.mm), the Cmd+V is consumed. So effectively, it seems that on Mac, the key combination is consumed by the system long before any part of VCL can handle it. Changing the control flow in VCL_NSApplication is probably not a good idea, but ... I'd appreciate any idea from you ...
As said above, the fact that Cmd+V works in a writable document is because the .uno:Paste slot is bound to Cmd+V, so when the key is dispatched to the main menu, it is recognized as accelerator, translated into .uno:Paste, dispatched to the form shell, and executed there. Looking into the definition of SID_PAST (resp. ".uno:Paste") shows that this slot has the "ReadOnlyDoc = FALSE" attribute, which means that OOo's application framework disables it in read-only docs, without asking anybody for its actual state. This implies that we cannot simply "overrule" this command's state in the form shell. I'm somewhat stuck here ... waiting for pl's command on the key event handling part.
Can't fix - in fact MacOS claims to have handled the Cmd+V shortcut, even if the menu entry associated with it (Edit/Paste) is disabled, and thus nothing actually happened. Discussed this with PL, and he agreed there's nothing we can do on our side. Re-targeting to "Later" - I don't like closing the issue, since after all, it's still a valid problem, but one we simply cannot fix within OOo.
*** Issue 115872 has been marked as a duplicate of this issue. ***
Reset assigne to the default "issues@openoffice.apache.org".