Thanks, Eric. I've coded round my immediate problem, in precisely the way you suggest. You could say I've "thrown code at it".
> I think most of the time for most applications the setting of J nouns to > reflect changes done by the program are unnecessary. If they are nothing but caches, I couldn't agree more. The whole of functional (and tacit) programming is a battle against cached values -- which underlie many time-consuming bugs during development. But _were_ the J nouns reliably to track the screen and vice-versa, as with Causeway, APLomb, ActiveX and Dyalog... that would be different. Originally I thought they did (or were supposed to). That led me astray. Now, fine-tuning controls to pander to customer demands is a painful waste of development resources, as I know to my cost on several commercial projects. Dyalog will tell you war stories about their Grid Object. You're wise to stay aloof from it. But as for "thinking through my requirements"... (!) I guess I just want to recruit techniques I've used professionally over the years in Pascal/Lightspeed/THINK C/C++, APLomb and Hypercard on the Mac, VB, Dyalog, Causeway and APL+Win on Windows -- all event-driven and object-based -- and so be in a position to port some old APL+Win apps to J. I reckon I've spent over 30 years "thinking through my requirements". (No hope for me now.) GUI programming can be easy and elegant. Provided the gui supports it. Otherwise... well... it's a rats' nest. Or you can just stay with a late 1970's WIMP interface: modal dialogs for all but trivial interactions. That works a treat. TABULA (essentially ported from APL+Win) is a sombre case-study of the whole area. Ian On Mon, Nov 29, 2010 at 5:22 PM, Eric Iverson <[email protected]> wrote: > I think most of the time for most applications the setting of J nouns to > reflect changes done by the program are unnecessary. > > I suggest you think through your requirement. Perhaps there is an easier and > simpler way. > > If not (and that may well be the case), I suggest you code in a style where > your wd'set...' calls are done in a cover that does the set of the J noun as > well as the set of the control. Something along the lines of the following > hand waving: > > NB. x name and y value > mysetter=: 3 : 0 > ".x,'=:y' > wd'set ',x,' *',y > ) > > On Mon, Nov 29, 2010 at 10:46 AM, Ian Clark <[email protected]> wrote: > >> Thanks, Bill. >> >> Yes, I did take a close look at wdhandler before I asked my question. >> And I think I see how that works. whandler calls wd 'q' from which it >> populates what I've been calling the buffer nouns. >> >> But calling: wdhandler'' doesn't simulate the effect of a button-click >> (say), as I'd hoped -- which would solve my problem. >> >> So what do I call to get back the value of what's actually showing on >> the screen in control: 'id'? -- i.e. the reverse of wd 'set id ...'? >> >> I imagine you're going to say: wd 'q', or wd 'qd'. But that only gets >> back a table of cached values, which can go out-of-date. No matter how >> many times I call it. >> >> I take it from what you're saying (or not saying) that there's no way >> I can post an event by means of a call from within the code of my >> event-handler? >> >> Ian >> >> >> >> On Mon, Nov 29, 2010 at 8:39 AM, bill lam <[email protected]> wrote: >> > The short answer is wd has zero knowledge of content in "buffer". This >> > should also hold for most gui libraries. For example the content inside a >> > c# text widget is unrelated to the variable with the same name. Whenever >> > the content of a widget is needed, one has to get the 'value' or 'text' >> > property of that widget (I assumed c# works like vb). >> > >> > type inisde ide >> > wdhandler >> > and examine the first few lines to see how and why "buffer" are set. >> > >> > Пнд, 29 Ноя 2010, Ian Clark писал(а): >> >> Because my code is often rewriting the contents of input fields as a >> >> result of user interactions with other fields, and controls. When this >> >> happens, the end-user frequently finds unanticipated ways to fool it. >> >> >> >> IME these instances would arise less often if: >> >> wd 'set myfield *',newstring >> >> simultaneously performed the equivalent of: myfield=: newstring >> >> ...which it doesn't. >> >> >> >> I can't really understand why not. Surely no logical purpose is served >> >> by permitting the noun: myfield ever to get out-of-step with what's >> >> showing on the screen? I'd guess it's just to save processor cycles. >> >> But whatever the reason, it's a bug-farm. >> >> >> >> (Of course one can always remember to perform the assignment oneself >> >> religiously after every use of wd 'set...' -which is what I find I'm >> >> having to do.) >> >> >> >> Moreover I disagree that "It would be unusual to require the value of >> >> a control before an event occurs." Or else I frequently need to do >> >> "unusual" things. Like requiring to know what's actually showing in a >> >> given edit field (which can get there from a variety of causes) in >> >> order to handle some event correctly. As with the app I'm coding now. >> >> >> >> Ian >> >> >> >> >> >> On Mon, Nov 29, 2010 at 4:50 AM, chris burke <[email protected]> >> wrote: >> >> > On Mon, Nov 29, 2010 at 7:33 AM, Ian Clark <[email protected]> >> wrote: >> >> >> Is there a system verb I can call which simulates a button event? Or >> a >> >> >> call I can make from my code to post a keyDown or mouseclick event? >> >> >> >> >> >> I've often met the need to do this, but most recently as one possible >> >> >> solution to the following problem: >> >> > >> >> > ... >> >> > >> >> > Just curious - why do you often feel the need to do this? >> >> > >> >> > Typically, your program will respond to events, and these trigger read >> >> > of the controls. It would be unusual to require the value of a control >> >> > before an event occurs. >> >> > >> >> > Chris >> >> > ---------------------------------------------------------------------- >> >> > For information about J forums see >> http://www.jsoftware.com/forums.htm >> >> > >> >> ---------------------------------------------------------------------- >> >> For information about J forums see http://www.jsoftware.com/forums.htm >> > >> > -- >> > regards, >> > ==================================================== >> > GPG key 1024D/4434BAB3 2008-08-24 >> > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 >> > ---------------------------------------------------------------------- >> > 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
