Maybe I am mistaken about the use of jbreak and it's purpose but this does not break:
(]^:9e9) 1 Nor does the script I have to run that takes about 5 minutes to complete. >From: Eric Iverson <[EMAIL PROTECTED]> >Date: Thu May 11 17:12:42 CDT 2006 >To: Beta forum <[email protected]> >Subject: Re: [Jbeta] RE: Tardy graphics >How is jbreak 601 not working? Have you studied the doc in the User Manual >on 'Interrupt Execution'? Verify with some very simple tests that the basic >mechanism works in simple cases. For example, create a script with a verb >that does a while loop that will run for 10 seconds or so and then test >whether clicking the yellow J icon interrupts execution or not. Most J >programs can be interrupted fairly promptly. There are some long running >executions that are very localized and don't check for break, but I would be >surprised if that were the case for the general problem you report. > >----- Original Message ----- >From: "Thomas Costigliola" <[EMAIL PROTECTED]> >To: <[email protected]> >Sent: Thursday, May 11, 2006 1:20 PM >Subject: [Jbeta] RE: Tardy graphics > > >> Regarding the thread "Tardy graphics" (Pasted below). >> >> I am having the same problems and am looking into solutions. Eric suggests >> to put the execution and UI in seperate threads. Any chance of a J >> threading library in the future? >> >> Also, I read that these changes have to do with the new jbreak facility. I >> must say that frankly the new jbreak facility does not work for me. The >> documention says to send the signal twice to break execution immediately. >> However, it takes between 30 seconds and 1.5 minute for the first instance >> to execute when I click the jbreak icon in my 'quick launch'. And when I >> am finally able to click it again my J window does not repaint itself and >> breaks only after 3 to 5 minutes of waiting (if at all). It seems like >> there is a lot more work to break in J6 where in J5 all I had to do was >> hit ctrl+break. >> >> >> >>> >>> >>>===================================== >>> >>> >>>There are significant changes in the area of windows message handling in >>>601. These change were enabled by the change to how break is handled but >>>were driven by a desire to simplify the front end and make it more >>>portable. >>> >>>In 504 the J Engine when running periodically and frequently polled the >>>front end with a callback. The callback dispatched windows messages in the >>>front end. The main purpose of dispatching the messages was to enable >>>detection of break signals (Ctrl+break etc in windows forms). The >>>secondary >>>effect was that messages such as requesting a repaint of a window that was >>>uncovered were also handled. But messages that could cause important state >>>change or require signalling J events were filitered out and discarded. >>>This >>>code was very messy and complicated, was quite against the spirit of the >>>windows api, and has been a continual source of subtle and nasty bugs. >>> >>>Trying to provide this same behavior with the Java based front end in Unix >>>was a serious complication and combined with early problems with the Java >>>use of shared libraries drove the decision to have the Java front end >>>communicate with a separate J Engine through sockets. With 601 we wanted >>>to >>>move the Java front end to use the more direct and far more efficient J >>>Engine as a shared library, but this was far easier if the dispatch of >>>messages while J was in execution was abandoned. >>> >>>These changes mean that the more common GUI applications where the J >>>Engine >>>runs for only a short time (several seconds) are simpler, faster, more >>>reliable, and more portable. >>> >>>But those benefits have the drawback that applications like yours (where >>>there is GUI combined wth very long running J Engine sentences) suffer. >>> >>>Possibly an acceptable crude workaround for your current situation is to >>>mark the form with the status line with ptop so that it can't get >>>covered/uncovered (which won't get repainted properly until the J Engine >>>goes idle). >>> >>>If that doesn't work because the form is big and takes up too much screen >>>space with ptop, then you could move the status line to another form and >>>make it ptop. >>> >>>The long term solution is to move the long running computation to a >>>separate >>>thread or process. Starting from scratch this is probably the better and >>>easier way to build the app. But as a conversion it can be very nasty. The >>>idea is to break the app in two parts with clean lines between them. One >>>part does the computation and has very little user interface. The other >>>part >>>has all the GUI and stays responsive. >>> >>>----- Original Message ----- >>>From: "Henry Rich" <HenryHRich at nc.rr.com> >>>To: "'Beta forum'" <beta at jsoftware.com> >>>Sent: Thursday, January 19, 2006 6:23 PM >>>Subject: [Jbeta] Tardy graphics >>> >>> >>>>I have an application that keeps a big form displayed, the last line >>>> of which is a static control that I use as a status line. When the >>>> program goes into a long computation, every few seconds it updates the >>>> status line. I use wd 'tnomsgs 1'. >>>> >>>> In 5.04, the status line was drawn whenever I wrote to it. In 6.01, >>>> the behavior is more complex and less satisfactory: >>>> >>>> Generally, I don't see the status lines as they are written by the >>>> program. >>>> The program writes the form first thing, and then immediately launches >>>> an Internet Explorer window that covers the form. I immediately >>>> minimize the IE windows (by hand), exposing the form; but the form is >>>> all white, as if it has not been drawn. Meanwhile the program is >>>> displaying >>>> status, but I don't see it. >>>> >>>> In one case I had the form partially covered by another window, and when >>>> I minimized the covering window the underlying form appeared; but then >>>> in a moment the uncovered pixels vanished, replaced by white, just where >>>> the >>>> previously-covering window had been. >>>> >>>> >>>> >>>> Anyway, what I want is to have my status show up, something that used to >>>> happen automatically. Is there somthing like pshow'' that I can do, or >>>> does the J code need to change? >>>> >>>> Henry Rich >>>> >> >> ---------------------------------------------------------------------- >> 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
