Is there a systematic way of determining which verb name is the name of the currently running event handler?
Thanks, -- Raul On Thu, May 19, 2016 at 7:27 AM, bill lam <[email protected]> wrote: > c++ jqt side did not know what had happened on the j engine so it will keep > on calling J on paint. You need to make j paint verb a no-op after the > first popup. > > For debug suspension, you may want try catchd instead of catch. suspension > in the presence of events is rather troublesome. IIRC all events except > paint are discarded during suspension, so that you may still get infinite > in suspension. > > what I used to do is set > wdinfo_z_=: smoutput_z_ > in order to debug gl paint error. > On May 19, 2016 5:28 PM, "Raul Miller" <[email protected]> wrote: > >> So... maybe it would make sense to replace >> >> wdinfo 'wdhandler';'error in: ',wd_fn,wd_err >> >> in wdhandler with something like >> >> if. -.wdquery 'wdhandler';'error in: >> ',wd_fn,wd_err,LF,'continue?' do.throw.end. >> >> ? >> >> Except... I tried that, and throw. was not sufficient to stop the >> infinite condition with debugging disabled, and that line of code >> never runs with debugging enabled. So there is something else going >> on, also... >> >> Perhaps the best compromise for development purposes would be to >> disable the offending handler (erase the name) if the user elects >> cancelling out of it? >> >> Thanks, >> >> -- >> Raul >> >> >> On Wed, May 18, 2016 at 6:36 PM, bill lam <[email protected]> wrote: >> > the popup dialog box is raised by a try catch block in the verb >> wdhandler, >> > since it does not throw an error after the popup, there is no suspension. >> > the gl area partially hidden by the popup box is repainted and since the >> gl >> > paint or any other jqt events has no knowledge that there has been an >> error >> > in j wdhander being caught so there is an infinite loop. You may add >> some >> > codes in the j paint verb to detect that error condition. >> > >> > this had been reported but fixing it is a low priority. >> > On May 19, 2016 5:09 AM, "Raul Miller" <[email protected]> wrote: >> > >> >> Currently, if I am using the gl commands for an isigraph control, and >> >> there's an error, I get behavior which I do not understand. >> >> >> >> (1) I get a popup telling me that there was an error (and giving me >> >> the details of the error. >> >> >> >> (2) I only have an "OK" option on that popup. >> >> >> >> (3) When I click "OK", execution resumes as if there were no error >> >> (presumably on the line following the line with the error. >> >> >> >> This quickly leads to an infinite loop condition where my only option >> >> is to shut down J. >> >> >> >> At the very least, I think I should get an option to have the error >> >> stop execution somehow. >> >> >> >> (13!:0]1 avoids this problem, but why was it a good idea to make me >> >> lose control of the J session in the first place?) >> >> >> >> (I'm not sure if this goes in jsource, since I think this is a jqt >> >> issue, not a j engine issue. Please let me know, though, if there's a >> >> better forum for this topic.) >> >> >> >> Thanks, >> >> >> >> -- >> >> Raul >> >> ---------------------------------------------------------------------- >> >> 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
