It would be nice if we users could come up with a design for a task that acts as the keyboard/terminal interface for the J session. Code that calls smoutput could be modified to call a verb that sends to the task.
If we get a good design, we could ask Eric to have a switch that lets smoutput send its output to the interface task, and accept keystrokes passed through by the interface task. Henry Rich > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Eric Iverson > Sent: Wednesday, June 28, 2006 8:25 PM > To: Beta forum > Subject: Re: [Jbeta] Tardy graphics (again) > > You can't do that with wd'msgs'. But you couldn't do that in > J504 either > (polled message that triggered events were beeped and > discarded). To do > that you need to organize your app in two distinct parts: the > GUI task > and the Engine task and coordinate through sockets/shared > memory mapped > files/ whatever. > > ----- Original Message ----- > From: "Oleg Kobchenko" <[EMAIL PROTECTED]> > To: "Beta forum" <[email protected]> > Sent: Wednesday, June 28, 2006 7:20 PM > Subject: Re: [Jbeta] Tardy graphics (again) > > > > But wd 'msgs' only allows to process the FE internal > > events like the session view. How one can poll > > other events, such as the ones that would trigger > > wdhandler from a long-running sentence? > > > > For example, if user clicked an isigraph or pressed > > a button, we want to exit the sentence. > > (wd'q' returns the same two numbers regarless of > > actual user actions.) > > > > > > ----- Original Message ---- > > From: Eric Iverson <[EMAIL PROTECTED]> > > To: Beta forum <[email protected]> > > Sent: Wednesday, June 28, 2006 6:46:05 PM > > Subject: Re: [Jbeta] Tardy graphics (again) > > > > > > Your explanation is largely correct. Particularly the fact > that other > > language systems behave like J601 in this area unless significant > > design > > complications are used. J504 was anomolous and achieved its > effect of > > GUI updates by having the J Engine periodically poll the > front end and > > allow it to run messages (some doing updates and some beeping as > > events > > the busy J could not handle were discarded). This was very messy and > > trouble prone code that was compounded when it had to to be > duplicated > > in Java J504 with the J Engine running as a seperate task > connected to > > the GUI with sockets. With J601 the Java GUI used the J Engine as a > > dll > > (significant performance improvement and code > simplification) and the > > previous Java kludge no longer worked. In looking for a solution I > > decided the entire dogs breakfast should have been thrown out long > > ago. > > So did so. This change greatly simplifies the system, improves > > performance (the break polling by the J Engine was a measurable > > overhead), and makes break signalling easier and more > reliable (from > > an > > external task). The cost is that GUI no longer updates > during a 'long > > running sentence'. The workaround/solution is to have the > application > > explicitly do the polling that was previously done by the > engine. That > > is, use wd'msgs' as suggested by Dan for simpler situations and use > > separate GUI and Engine tasks for more complicated ones. > > > > ----- Original Message ----- > > From: "Oleg Kobchenko" <[EMAIL PROTECTED]> > > To: "Beta forum" <[email protected]> > > Sent: Wednesday, June 28, 2006 6:33 PM > > Subject: Re: [Jbeta] Tardy graphics (again) > > > > > >> 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 > > > > > ---------------------------------------------------------------------- > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
