=====================================
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
