Hi Ray, >1. I will need to create a circular buffer. Data coming in, say >continuously, will get put into a buffer but it will not get larger >than a certain amount -- the oldest input drops off the top end. I am >not sure of the best way to do this. Can I make it larger than 32k? >Will I have problems putting this into a text field? If my input >stops I'd like to be able to scroll back to see some of the data that >scrolled out of view, up to the limit of the buffer. > >To form a relative address into the buffer, I can mask the address so >that high bits are chopped off, making it a modulo-32768 number, for >example. I think 32k is enough buffer space, but allowing it to be >more or less is better yet. I don't see why 64K or 128k, or even 256k wouldn't work just as smoothly. >2. In that sense, I see that a text field, using EDIT$(id) = >&ZTEXTHandle& can only handle a maximum of 32k char. Is it possible >to go above the 32k limit? Is this the best way to get the >continuously arriving data to be visible in a scrolling window? > >Note that the actual serial data is not what I will show, but a >decimal or hexadecimal representation of it (or some other >translation, if perhaps a known proprietary protocol is somewhat >decoded). I may also tag it with an occasional inserted count of >ticks or seconds since capture began. If the long-text functions aren't quite what you need, you might end up writing your own printing routine to scroll text to a window from anywhere in a handle of any size. Since it doesn't have to be editable (I presume), it would be much simpler than completely rewriting TEXTEDIT to use long fields, but still presents some challenges. If you decide to try this, take a look at the fields of the TEHANDLE to decide which ones you will need for grabbing a chunk of data with constantly shifting boundaries and slapping it onto the screen. Will you store the raw data coming in, or the formatted output? There could be advantages either way. Building a line-start table could be a slippery proposition, but not impossible. Or you can just calc starts as you grab the data. My fear would be a refresh of the window when it holds data that has exited the buffer. Maybe you'll have to move display text into a second buffer, but that could be a time-grabber. >3. Even though I happen to like to use PG (since I don't program all >the time, so wish to keep my complicated life simpler), I am >wondering if this task isn't going to take too much PG runtime >overhead, that maybe I have to code it without benefit of PG. Any >practical suggestions? From monitoring this list for a week since >joining, I get the feeling that few people here use PG, that "it is >not for the _real_ programmers." Maybe I am wrong. I dunno. I may not be a real programmer (I haven't sold a program since the Commodore 64 expired), but I wouldn't even try to write a full application without PG. If I were really concerned about overhead, I would probably write the program in PG, then start finding ways to reduce overhead. You're going to have to do most of what PG does anyway, and if it does things that are superfluous to your needs, they can easily be removed. PG helps me make sure I've covered all the bases. There are things I would never think of or figure out how to do if PG didn't give me the structure. My 2¢. 0"0 =J= a y "