@bill: I agree it's reasonable behavior to show the error repeatedly... What's not reasonable is that the window showing the message is modal and prevents you from fixing anything.
Ian's solution has the advantage that the message just goes to the terminal, so at least the system is responsive. (Although I can imagine there might still be times when the terminal becomes unusable and you'd have to do your fix in an editor window and run the lines.) I also think Don is right that the correct place to trap this is the try/catch block in wdhandler. I do still get an infinite loop with a bug in paint. (However, I can now kill J from his abort button rather than having to start the task manager, so that's an improvement.) What if we added a new non-modal window to the IDE that was specifically for logging in wd? It would be a grid with the following columns: locale | window | handler | severity | message | count Each line would represent a new message... Duplicates would just increase the count for the relevant line. Since the line tells you the offending function, you could click a line to select it, and then have a button or menu to do something about it: - debug the handler - delete / disable the handler - pop up a temp with the handler's definition, inside an assignment ( window_handler_locale_ := 3 : 0 .... ) There'd be a verb called 'wdlog' or something that took a severity and a message, and added to the list. Anything above a certain severity would trigger the window to pop up. Maybe you could also have a severity that meant "watch" or something, which would give you a place to monitor the current value of something (say mouse coordinates or a timer or the value of some variable you're calculating over and over) and keep it on one line in the grid, without spamming the window with zillions of slightly different message lines. Thoughts? If this seems like a sensible idea to people, I'd be willing to take a crack at implementing this. On Sat, Dec 21, 2019 at 8:29 PM bill lam <bbill....@gmail.com> wrote: > the behavior is reasonable in that when modal dialog is closed the form > beneath got repainting and this raised another paint event and the same bug > brought up modal dialog again. > > Will running with gui debug be fine? IIRC gui debugger saved events > somewhere during suspension. > > however j602 seemed worked differently and didn't fall into infinite loop, > not sure how it was done. > > On Sun, Dec 22, 2019, 2:11 AM Michal Wallace <michal.wall...@gmail.com> > wrote: > > > Here's a little jqt program with a bug in it. > > > > When I accidentally run something like this, I get a modal dialog with an > > error message. > > > > Closing the message box triggers the error again. > > > > Once that happens, the only way I know to recover is kill my whole J > > session. > > > > Is there a better way? If not, could we maybe add a button to these > > messages that would destroy the offending window? > > > > wd 'pc win0 closeok; pn "debug me"' > > wd 'cc img isigraph' > > wd 'pshow' > > win0_img_paint =: verb define > > this is a bug > > ) > > ---------------------------------------------------------------------- > > 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
