I've tried runimmx_jijs_ in place of my timer. It does indeed behave like APL+Win "Defer", but doesn't allow system events to get a look in.
Frequent calls of wd'msgs' during the duty-cycle don't fix the problem either: they cause the gui windows to judder and they are unresponsive. Although the J session does accept keystrokes with no apparent response delays and statements can be executed. So I'm afraid I shall have to go back to using my timer. Pity. I would like to know though, how it is that the IJX window can avoid judder and be responsive whereas my wd-defined windows can't? Surely it's using the same technology? Has it got some other way besides wd'msgs' of letting system events get through? On Wed, Apr 27, 2011 at 6:47 PM, Ian Clark <[email protected]> wrote: > Hey... then it ought to do what I'm using systimer for! > > "Immediate" in the 9!:26-29 write-ups suggested to me it was running > the given expression there-and-then, at whatever point it was called > in the code. > > I'll try some experiments. It'll be super if it works. Because > systimer is a b* nuisance and keeps crashing the Mac if you exit, or > try editing anything, with the timer running. > > > > On Wed, Apr 27, 2011 at 2:11 PM, chris burke <[email protected]> wrote: >> Your description is correct - they run J expressions after return to >> immediate execution, and differ only in whether the entries are displayed. >> It sounds like APL+Win Defer does the same. >> >> The main intent was to run expressions in Tools|FKeys, but they or similar >> could be used anytime. See also the docs for 9!:26 to 29. >> >> Chris >> >> On Wed, Apr 27, 2011 at 5:59 PM, Ian Clark <[email protected]> wrote: >> >>> There are a pair of verbs in J602 JWD: runimmx0_jijs_ and >>> runimmx1_jijs_ . What do they do? >>> >>> (You may assume I've read about 9!:26 et seq in >>> ~help/dictionary/dx009.htm -but don't grok the word "immediate".) >>> >>> I've been finding runimmx1_jijs_ useful for executing a given >>> statement from within J code as if it had been typed into the J >>> session. Occasionally doing this behaves differently from running it >>> as a bare line of code in a verb. For example: cocurrent 'mylocale' >>> --which stops the current locale reverting on exit from the calling >>> verb and forces it to remain in mylocale. >>> >>> Something one wouldn't normally need to do in operational code I >>> guess. But it's convenient for writing what used to be called CASE >>> tools. (The need arises in-part because I can never spell "cocurrent" >>> right first time :-) >>> >>> Are there implications? Am I misusing the facility? What should I >>> really be doing? >>> >>> An allied matter (at least I think so)... >>> >>> APL+Win has a facility called "Defer" which posts a statement to be >>> executed only when the current process has finished running, typically >>> a gui control handler and its nested calls. Good for gui housekeeping. >>> I've been approximating this effect by setting systimer to execute >>> (once only) the required statement as a callback, a millisecond or so >>> in the future. It's a cumbersome way of doing things. Is there a >>> neater way? >>> >>> BTW I'm using a Mac under Snow Leopard. Things which work under >>> Windows can't be guaranteed to do so on the Mac, and vice-versa, >>> because the system event queues are a bit different. >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
