I have read elsewhere on this forum that the same problem exists with Director 11.5 so I'd advise against splashing-out in the hope of a solution. I was going to suggest giving the D11.5 demo a go, but I expect the publish functions will be locked so you wouldn't be able to do the necessary tests.
Also, in 11.5.9 (the latest version) Adobe have introduced an exciting new bug that causes the same problem to occur in projectors that contain Flash textbox components or Flash SWFs containing text boxes / fields / components (the problem didn't exist in 11.5.8). The edit shortcuts do seem to work with native Director text fields though, although I'm not sure if the same is true for a DCR in Win7+IE9.
I only use Director for projector-based projects so don't know much about how things go when embedding a DCR in a web browser, but with projectors I work around the paste problem by not using Director's Flash components (they've always been problematic IMO). Rather, where a native Director text field won't cut-it, I embed a SWF that contains the fields etc that I need, and then use a behaviour to interface Director with the SWF sprite. Within the SWF I write a function that will paste text into the focussed field, whilst in Director I capture any [ctrl]+[v] key presses on the Flash sprite, use pasteClipboardInto() to paste the clipboard text into a text member, and then pass this text from the text member to my custom paste function in the SWF. A bit convoluted, but it works in projectors - can't say if it will work in a Shockwave running in IE9, but it's a possible avenue to explore.
I haven't got Win7+IE9 to test this with, but I've just popped a page online that contains a native Director text field that you can try to paste into. The DCR was created with Director 11.5.9 on Mac.
Thanks for the link , I tried it in IE9 Win7 and it does not allow paste via keyboard shortcuts.
When you use ctrl+v it just displays the letter 'v'
I did try in safari / mac and it worked as normal.
It must be a bug in the IE shockwave player specifically under Win7. I have only 64 bit Windows 7 , maybe it is related to the 64 bit player rather than the 32 bit. Do you know anyone with 32 bit Win7 that can test it??
if you use ie on 64bit Win7 everything is 32bit.
If you use ie64, then it's 64 bit.
So ie(32bit is the same as in 32bit Win7.
I've made some changes to the test DCR: I've applied a behaviour that listens for a [cntrl]+[v], and that then uses Lingo to paste the clipboard into the field when triggered. This is still just a basic Director-native text member, BTW. The test is at the same URL as before.
FYI - Applying the behaviour made the field behave strangely in Safari - specifically, the caret position was stuck at the last character in the field, and if I clicked anywhere in the text field it would create a selection from the clicked point to the end of the field. So the behaviour also takes care of placing the caret / making a text selection. (It's particularly weird cos this didn't happen with the first test so would seem to be something to do with attaching a behaviour to a text sprite).
There's also a possibility that I've stumbled upon a the cause of the problem: When I tested this DCR in Safari I noted that the first attempt at pasting causes the SW player to show an alert box asking the user to confirm that they want to give the app access to the clipboard. When you click "yes" nothing happens, but if you then try to paste again it will work (and no confirmation box is shown).
Given that this didn't happen with the first test DCR I'm presuming that the confirmation box is being triggered by the behaviour's call to the pasteClipboardInto() method. And this is making me wonder whether, in the absence of the user granting specific permission, IE9 is simply blocking the paste command, hence it not being passed to the DCR, and hence the problem you're having.
This also makes sense when you consider that a keyboard-shortcut paste command would (I expect) need to be passed from IE9 into SW Player in order to work. So when you hit [cntrl]+[v] IE9 blocks the command because it hasn't been granted permission, and because SW Player therefore doesn't receive the command it doesn't trigger the clipboard-access-confirmation dialog that would allow SW Player to instruct IE9 to enable paste shortcuts.
If this is the case then simply calling pasteClipboardInto() when the DCR loads and then clicking "yes" on the clipboard-access-confirmation dialog, may be sufficient to persuade IE9 not to ignore the paste commands, thus solving your problem. You could test this using the movie(s) you're having problems with - just add a dummy text member to a cast and call pasteClipboadInto() on it from a startMovie handler. For example:
Fingers crossed again...!