Have you tried applying the focus to another object instead of null such as:

stage.focus = stage;  // or some other non-text object

Did you adjust the bubbling of the event? The 3rd argument of a listener can be set to true to only use the "capture" phase of an event. Thus it has no bubble and you should be the first informant of a MouseEvent occuring and stopImmediatePropagation() might work.

e.g.

myInput.addEventListener(MouseEvent.MOUSE_DOWN, _someHandler, true);

 

function _someHandler(e:MouseEvent):void

{

    e.stopImmediatePropagation();

}

Although I'm not even sure the mouse is the first event fired in a TextField's focus scenario. The TextField supports "activate" and "focusIn" as events which may fire off before the MouseEvent. It'd be worth adding every single relevant event while tracing which is firing off to see which happens first.

Alternatively and unideally you may have to consider a custom input scenario. A hit area that simulates a TextField and cursor (TLFTextField boundary properties will let you position the cursor easily). A click on some transparent Sprite as a hitarea won't trigger the soft keyboard. You'd then just need to send the characters to dynamic text. Again not ideal but would solve the issue if you can't stop the event overall.

What I meant above is you would set the .mouseEnabled property to false to avoid the dynamic TextField from emitting any MouseEvents. The hit area you'd cover the TextField with would have the job of listening to MouseEvents and would never cause the soft keyboard to open.

I came up against a very similar issue in AS2 land about 6 years ago. To this day I still use this approach rewritten in AS3. I had a container clip full of interactive elements that can be panned. Having only the usual MouseEvents I had to figure out myself what the user intended when they pressed.

I just watched the movement of the user. If they touched the surface and moved more than X number of pixels then I would consider the user is trying to "pan" and would instantly start doing that. If a MOUSE_UP event fired before moving X number of pixels, it was a click.

It's not a huge amount of work to get that kind of system up but I'm not sure if you can avoid it trying to get gestures working how you want  while somehow avoiding basic events like MouseEvent. There must be an event hierarchy somewhere and I'm not sure where it begins but as I said, trace()ing a bunch would certainly let you know.