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
