Hi David! On Fri, Nov 15, 2002 at 12:25:37AM +0100, David Ayers wrote: > But the point is... > > The way test system mechanics work, it's not really meant for an > NSTextField to be it's own delegate.
If I understand it right, this is from the "theoretical design", "philosophical" point of view, but from a "pragmatic" view, it should work nonetheless, right? (I don't understand the meaning of the first part, "The way test system mechanics work") > The Model-View-Controller paradigm > [explanation...] It can see that separating these roles can help in designing clearer architectures that are easier to understand and maintain. Didn't know that there's a formulated "paradigm" that explains this. Is this written down somewhere in the Openstep spec or something else by Apple or is it a (maybe even well-known) CS-"theory"? > wiki.gnustep.com Oh! I wasn't aware this existed! (But it's .org IIRC, checked this morning) > > Secondly it seems ... hmm unusual? to me, to change the contents of an > NSTextField while it is processing becomeFirstResponder. But maybe you > have a good reason for it. Maybe you can explain a bit more what "User > Effect" you are aiming at. Well, as I already wrote, this is for a database GUI. The text fields part of "blocks", which represent a database table. In a block, there may be several records representing table rows. The text fields can show the column values in these records. When a block doesn't contain a record and the user wants to create a record, he clicks in a text field of the block to enter some value. At this point, the record gets instantiated and filled with default values (maybe a "create record" trigger is called that modifies the values). Thus, if the user clicks into one text field, this field and others must get their values modified. The problem is that when the user edits text in an item (i.e., text field), the record state is modified from "clean" to "changed" so the system knows it must be written into the database later. The fresh record (with its default values) is supposed to have state "clean", however, and I was surprised why it hadn't. I used a nasty, evil hack to solve the problem :-} before changing the value via setStringValue, I moved the first responder away to another, innocent text field via makeFirstResponder. Really! That's true! Right in the middle of the text system's desperate efforts to change the first responder! Cruel, but it works (I am aware that this might not be by design). After all event processing is done, the input focus is automatically in the text field the user clicked. > Is NSTextField A > some type of "inspector" of the current First Responder?) I can't tell not in the above case, but I have two text fields showing the current block and item (text field) name, too. Thanks for having answered & explained! Greetings, Dirk Lattermann _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
