appologies if I misunderstand, If your js paint event took the full list of commands, then you wouldn't have these problems, IMO, and would solve the issue of general repaints being sometimes required for other reasons.
If I understand your design, if the jhrajax received a list, updated the js list, and then called paint (which could have no args, and use a global js turtlecommand list), then that would also work. ----- Original Message ----- From: Brian Schott <[email protected]> To: Programming forum <[email protected]> Cc: Sent: Saturday, March 22, 2014 5:48:07 PM Subject: Re: [Jprogramming] jhs webgl array_buffer Joe, As it is, J processes all the paints, but the client JS only gets the **first** paint -- the only paint JS expects --because that first paint contains the jhrajax, like all paints do. J produces a paint for every simulated move, but does not know how to batch them together. I am assuming that JS has to initiate a request and only expects one response for each of its requests. That's right isn't it? On Sat, Mar 22, 2014 at 5:33 PM, Joe Bogner <[email protected]> wrote: > On Sat, Mar 22, 2014 at 4:53 PM, Brian Schott <[email protected]> > wrote: > > > > The big question is, how does J know that the last paint operation has > been > > completed? For example, is there some way to detect an idle status in J? > I > > seem to recall something like sysevent that could do that. No luck with > > this search: > > > > Why does J need to know when the last paint operation is completed? > Using my simple example, I enter a Number and get back a list of > factors. J shouldn't care what the Client (JS) does with the results. > The same goes for your example. It just sends back a bunch of array > results. > > > So I guess your "Client" is my JS, and your "Server" is my J. Right? > > Yes > > > But I don't know how to tell when Server is finished thinking. > > Per above, it shouldn't matter. The AJAX call is asynchronous, so it > doesn't block. It waits for the result of the Server call. The Server > (JHS) should send all results. It's conceptually similar to how your > previous version sent all the history. It shouldn't send the history > any more, but should just send the necessary rows for the 1-N results > from J's evaluation. Hope that helps. I can mock up something in a few > days if it's still unclear or happy to answer more questions on here > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- (B=) ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
