On Sun, 2013-02-24 at 22:34 +0000, Steve Fryatt wrote: > On 10 Jan, Michael Drake wrote in message > <530c15f056t...@netsurf-browser.org>: > > > In article <mpro.mgds7b08fs7pc01k4.li...@stevefryatt.org.uk>, > > Steve Fryatt <li...@stevefryatt.org.uk> wrote: > > > > > That shouldn't be too tricky to sort. I'm a little busy at present with > > > non-computery stuff, but will try to take a look in the next couple of > > > weeks if no-one else gets there first. > > > > Thanks, that would be great. All pastes happen as a result of passing > > KEY_PASTE to the core, so maybe it can request the clipboard when it > > passes that to the core, and then when the core calls gui_get_clipboard, > > maybe it will be easier? > > Will gui_poll be called between KEY_PASTE being passed in to the core and > gui_get_clipboard getting called in return? This would potentially have to > happen several times -- and the required number could vary.
gui_poll will only ever be called from the main loop. Beyond that, we make no guarantees. > If not, is it safe for the front end to go and make calls to its own > gui_poll before gui_get_clipboard returns? I'm not sure[1] if RISC OS > defines that a task won't get other poll codes (eg. redraws) during a > message exchange; if not, then there's the potential for the core to get > called for something else before gui_get_clipboard returns. User messages have higher priority than any others, so if there is a user message waiting, it will take precedence. I don't believe this permits any assumption about not having to deal with other message types (or other user messages, for that matter) However, I believe this is mostly moot, as we fixed paste some time ago: http://git.netsurf-browser.org/netsurf.git/commit/?id=64ae9e8693aaaf09cb4e35b63d029d446ef361b0 J.
