I am seeing some odd things here. One of which is that the previous
documentation for wdquery --
http://www.jsoftware.com/docs/help701/user/script_winlib.htm#wdquery
-- seems to no longer be valid. Another is that I can not find
documentation for wdquery for the current release. (And I am seeing
other oddities in behavior, but I am going to stop trying to enumerate
those oddities with those two observations.)
Anyways, perhaps wdhandler should be changed, replacing
wdinfo 'wdhandler';'error in: ',wd_fn,wd_err
with something like
if. 0~:wdquery 'wdhandler';'error in: ',wd_fn,wd_err,LF,'continue?' do.
echo 'DISABLED_',wd_fn
('DISABLED_',wd_fn)=: (5!:1<wd_fn)5!:0
erase wd_fn
end.
(but, beware email induced line wrap)
In other words:
[1] Give the user the opportunity to continue. Depending on details of
other parts of the system, this may or may not result in further
problems.
[2] If the user opts not to continue, set aside the definition of the
current event handler (which failed) and disable it. (Hypothetically
speaking, we might be able to skip the setting aside part, because the
definition should be in a script. However, in some cases it might not
be.)
Thoughts?
Thanks,
--
Raul
On Thu, May 19, 2016 at 11:59 PM, bill lam <bbill....@gmail.com> wrote:
> I checked agin, it is the local noun wd_fn inside wdhandler.
> so perhaps you can try
> ". wd_fn,'=:empty'
> or
> 4!:55 <wd_fn
> inside the catch block.
>
> Пт, 20 май 2016, bill lam написал(а):
>> the first few rows of wdq (global set inside wdhander) should provide that
>> info. see j user manual or jwiki for wd documentation.
>> On May 20, 2016 6:55 AM, "Raul Miller" <rauldmil...@gmail.com> wrote:
>>
>> > 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 <bbill....@gmail.com> 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" <rauldmil...@gmail.com> 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 <bbill....@gmail.com> 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" <rauldmil...@gmail.com> 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
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
