> From: Raul Miller > > On Thu, Dec 10, 2009 at 11:48 AM, Dan Bron <[email protected]> wrote: > > Given that J is single-threaded, is there ever a time a J programmer > > would need to implement a paint event handler, assuming he > > already painted his picture once, and didn't intend to change it? > > Maybe someone else can weigh in here. > > I know that in the context of OpenGL, I have always needed to > implement paint event handlers. However, in the context > of non-OpenGL wd, perhaps the image is buffered and J > handles this issue itself? >
I imagine things such as resizing the isigraph control would/should call the paint event handler? However in this case because the form/isigraph control cannot be resized (and because the control is being re-painted every 1/2 a second, it isn't a big deal. However this does raise again the issue of what the object of the code should be? There is a nebulous happy medium between the tersest, most minimalistic script possible that fulfils the task specification and a "good" example of J code that doesn't look like gobbledy gook to the uninitiated. Dan's initial solution was great (bar some minor changes and cleaning up the comments/whitespace). It gave a good solid foundation and some nice clues about how the code might be extended. I wonder if perhaps some of the changes (including a number that I made) while they increase the terseness are actually decreasing the quality and clarity of the solution? Perhaps the paint handler should be left in? The ( verb def 'code here' ) form of verb definition looks like an improvement to me for short clear sentences that don't include strings. For the ( wd ) verbs I think I would prefer to use the ( verb define ) form to limit the use of doubled apostrophes. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
