Do you remember, why COM has the appartment
threading model?
A proper way to achieve a long-running task (not necessarily process)
with GUI status updates is to run the task on a separate thread
with a callback for updates, which is sync'd on the main thread.
Alternatively it could be a separate process and some
kind of asynchronous communication like pipes or sockets.
In addition, the alternative to callbacks would be polling the
communication end for data ready hooked on timer or so.
As a quick solution, you could draw your status in a
window with isigraph, which supports forced updates.
There is no magic here, if you do the same without the above
in any C++ or Java application, it would behave the same as J 601.
(It did not in j504 because, I believe it used a separate thread
for the interpreter, hence Ctrl+Break vs break icon, which
allowed to updates the session view in the main loop).
----- Original Message ----
From: Jose Mario Quintana <[EMAIL PROTECTED]>
To: Beta forum <[email protected]>
Sent: Wednesday, June 28, 2006 5:35:10 PM
Subject: RE: [Jbeta] Tardy graphics (again)
The following illustrates the tardy display problem:
countdown=. ''"_@:(<"0@:|.@:i.@:[ >@:((1!:2&2@:[ ]
6!:3@:])&.>/@:(|.@:[ ,
<@:])) ])
10 countdown 1
While it is counting down click outside the window and try to refocus
(e.g.,
by dragging the window), this will trigger the frustrating behavior.
Making
the offending window "top", in this example the ijx window, does not
help at
all (besides, one might need to have the status of several
applications
available simultaneously). J5 does not exhibit this irritating
behavior so
it is hard to believe that the OS is responsible; in any case,
telling
users
that it is the OS's fault does not solve the problem.
We have applications that gather, process and monitor information in
real
time. We do not want to revert back to J5 just because of this
issue.
Is
there any workaround to solve this problem? Do we have to switch to
a
C GUI
just because of it?
Behalf Of Oleg Kobchenko
Sent: Saturday, January 21, 2006 9:30 PM
To: Beta forum
Subject: Re: [Jbeta] Tardy graphics
I have a little experiment, which shows that it's not
the OS as it was tested on same XP, but a strange behavior
in j601 that causes a window to stop responding after
it has been deactivated: the title bar became blurred.
It is seen as it updates it's title in task bar for a few
seconds after loosing focus and before deactivation.
Below is a script that works perfectly in j504, but has
the above problem in j601. It even can interrupt itself,
but only until deactivation.
I would check if WM_ACTIVATE is always sent to DefWindowProc,
and/or returns non-zero from WindowProc. Or there may be
logic: if inactive then ignore messages, but there is no
chance to re-activate. Something along
these line may have been affected in j601.
NB. =========================================================
require 'gl2 dll winapi'
coinsert 'jgl2'
keypressed=: 3 : 0
0~:0{::'user32 GetQueueStatus i i' cd 0 1{::winconst'QS_KEY'
)
F=: 0 : 0
pc f;
xywh 0 0 200 20;cc g isigraph;
pas 0 0;pcenter;
rem form end;
)
f_run=: 3 : 0
wd F
show 'Click me!'
wd 'pshow;'
)
f_close=: 3 : 0
wd'pclose'
)
f_g_mblup=: 3 : 0
MAX=. 20
show 'Press any key to stop'
for_i. >:i.MAX do.
6!:3]1
B=: (2*i=MAX)+.keypressed''
wd 'pn *',(3":100*i%MAX),'% ',":{:t=. 6!:0''
show B{::('Status ',":t);'Break';'Done'
if. B do. break. end.
end.
)
show=: 3 : 0
glsel 'g'
glclear''
glmap MM_RAW
glfont 'Arial 20 bold italic'
glrgb 0 0 255
gltextcolor ''
gltextxy 20 4
gltext y.
glshow^:(6>".1{9!:14'')''
glpaint''
)
f_run''
NB. =========================================================
--- Eric Iverson <[EMAIL PROTECTED]> wrote:
> To my surprise it is not possible to get an uncovered window to
> repaint.
> Win2000 and XP are different in this respect from earlier versions
> of
> windows. I tried all the tricks suggested by Oleg and Raul
> (invalidate
rect,
> validate rect, updatewindow, isgraph, etc.). The OS is doing its
> best to
> preserve its idea of the image of the uncovered window until the
> task
> processes its GUI messages. This is unfortunate and a tighter rule
> than
I
> had expected. However, it doesn't change my mind that the favored
behaviour
> should be on J sentences that are directly in the message loop
> (same
task,
> same thread, same call stack). A search doesn't give any clues of
> an API
> call that would avoid this strange behavior after being uncovered.
>
> If all you care about is the visibility of your status line then
> you
have a
> simple workaround (stated before) as follows: Move the status line
> to
its
> own form and mark it ptop and that way you'll see the updates and
> don't
have
> the problem of being uncovered. I can't think of a simpler
> workaround
and
> wonder why you have rejected it. Note that trying to move this
> ptop
> form
or
> minimize/resize again gets you into the nasty 'uncovered' state.
>
> A better solution at only a little more work (given that I don't
> know
> anything about your application or the problem you are trying to
solve :) )
> would be to have your long running task write its status info to a
> file.
And
> have a separate J task that has a status form that displays the
> info
from
> that file. That gives you the two threads of execution that you
> need: 1
to
> drive the user interface and 1 to do the long execution.
>
> ----- Original Message -----
> From: "Henry Rich" <[EMAIL PROTECTED]>
> To: "'Beta forum'" <[email protected]>
> Sent: Friday, January 20, 2006 4:05 PM
> Subject: RE: [Jbeta] Tardy graphics
>
>
> >I don't need a fundamental redesign - I just want to see my
> >status
> > line. It sounds like the event that changes the clipping window
> > is not being processed because my J program is running.
> > Couldn't
> > I have a wd call that tells J to go out & update its clipping
> > window (either to the correct current shape or to the maximum
> > size)?
> > That couldn't hurt anything that I can see, and it would allow
programs
> > to work without major redesign.
> >
> > Henry Rich
> >
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Miller, Raul D
> >> Sent: Friday, January 20, 2006 4:02 PM
> >> To: Beta forum
> >> Subject: RE: [Jbeta] Tardy graphics
> >>
> >> Oleg Kobchenko wrote:
> >> > However, with sockets, pipes or two threads, it
> >> > would have been possible not to wait until engine
> >> > handler finishes and return immediately, whereas
> >> > J commands from within the handler be processed
> >> > as events from the main event loop.
> >>
> >> This kind of fundamental re-design of the system isn't
> >> the sort of thing to do to a release that's in beta.
> >>
> >> Maybe some people will find they need to stay at
> >> 5.04 for some of their work until some future
> >> release.
> >>
> >> --
> >> 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
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
countdown=. ''"_@:(<"0@:|.@:i.@:[ >@:((1!:2&2@:[ ]
6!:3@:])&.>/@:(|.@:[ , <@:])) ])
10 countdown 1
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
