Updating View without changing focus

Michael Gersten michael at stb.info.com
Thu Oct 5 23:56:00 PDT 1995


Again, the disclaimer: I haven't done this myself, but the docs seem  
straightforward.

Begin forwarded message:

Date: Thu, 5 Oct 95 14:36:52 -0700
From: Sean Willson <willson at handset.laa.com>
Subject: Re: Updating View without changing focus

Michael,

> 1. When the user is typing, the textfield is running a modal  

loop. > When the user pauses, the modal loop releases, and the  

appkit main > loop can run.

Would this be done by overriding the textWillChange and  

TextDidChange methods? An if so after the textobject updates how  

will it return focus to where the user was typing, i.e. I have  

entered 'Sean M. Wi' and the trigger goes off, how do I insert the  

I-Bar after the text I have already typed........
----
You don't need to worry about that at all. The textfield or text object knows  
how to display an I-beam while the user is typing, and a flashing I-beam  
when the user stops. You don't worry about it at all. The above behavior is  
straight out of the appkit.
-----------

> 2. When the appkit main loop runs, the socket, which was  

registered > to the DPS system (DPSAddFD), can trigger, calling the  

routine that > reads from the file and stores it into a buffer.

Which socket are we speaking of and why do I need a socket, sorry  

if this is obvious?
----
OmniWeb is downloading the HTML data from the remote; it has a socket.

In general, the idea is this: You have data being generated that you want to  
display. One routine has to generate the data; it is triggered by either  
DPSAddFD, or by a timer, or by something else that the appkit reads  
(maybe a DO connection that ahs been runFromAppkit'd.)

Then a second routine takes that generated data and displays it.
--------

> 3. After that, a timer can fire, and the buffer parsed for  

display. > Anything that was not displayed before is added. This is  

done by
> setting the insertion point to the end of the displayed text, and
> then modifying it (select an empty space at the end, and
> then replace the selection). It's not a NeXT Text object (at  

least, > I've never seen a text object that can have a popup list  

inside
> it), so I have no idea of the details.

How would I grab only what was changed in a file, thread a system  

tail function or something like that? Since the file can get large  

am I still going to experience some trouble with the typing being  

delayed?
---
Ok, now I understand what you are asking.

The method is as follows:
1. The file is opened for reading. You seek to the end, and then register it  
with DPSAddFD.
2. If you want to update the display as soon as data arrives, you have the  
routine registered with DSPAddFD take the new data (do a large read into a  
large buffer; see how many bytes came back from the read call), and  
display it at the end of the display Text object.
3. If the updating the display as described above occurs too often, then you  
will want to limit it to once every second or so. To do this, you register a  
timer event, rather than using DPSAddFD. When the timer goes off, you  
examine the file, grab whatever's new, and display it.
4. If your input is either a pipe, or a socket, then there is a limited backlog  
that can be stored in the kernel. In this case, you need to have DPSAddFD,  
and a routine that takes the data from the file (which has a limited,  
kernel-maintained buffer) and store it into memory (which is a program  
maintained, large buffer). Then, a timer routine can move it from that  
buffer into the display.

Note that this whole approach is designed for non-multitasking, i.e., I'm  
making the assumption that only one of (add to buffer, display from buffer)  
can occur at one time. Since the appkit is non-thread safe, this is a safe  
assumption, that only one thread can be in the appkit run loop at any time,  
so only one thread can be in only one of (user types in the textfield,  
DPSAddFD calls reading routine, timer triggers display updating) at a time.
---------
> The secret? The user pausing in the typing ends the modal loop,
> which lets everything else run. Just like while you type, the
> cursor doesn't flash, but when you stop, it does.

What are you refering to as the modal loop here? And when would I  

create this loop, after the textDidChange: delegate method is called  

by the textField?
---
The modal loop being refered to here is the modal loop running inside the  
textfield code that NeXT has written. You don't write a line of it.
--------

I am unfamilure with Real-Time GUI applications but would like to  

get more into it..........Any help would be great.....

Sean Willson
---
Hope this helps.

		Michael
---------
--
Sean M. Willson.   Lynn-Arthur Associates, Inc.    +1 313 995 5590
willson at laa.com     Operations Support Systems     +1 313 995 5989 (fax)
2350 Green Road            Suite 160            Ann Arbor, MI, 48105 USA

--
Michael Gersten     michael at stb.info.com      http://www.stb.info.com/~michael
NeXT Registered Developer (NeRD) # 3860 -- Hire me! (Great at design/coding)
Without Prejudice, UCC 1-207		(I can't stand fixing other's bugs)
Want $$$? Check http://www.stb.info.com/~michael/TrulySpecial.html. Serious.


More information about the OmniWeb-l mailing list