amir@pro-generic.cts.com (Amir Michail) (07/13/89)
I would like to thank all those answering my queries about the University of
Waterloo modem policies, etc... I've also learned that this is not the place
to ask those kinds of questions (i.e. Amiga tech...)
I am currently working on some general Amiga scroll box routines. So
far, I use a structure very similar to the Gadget structure which allows
linked scroll boxes on the screen which are checked for input all in one go
(i.e. CheckScrollBox(&First,IntuiMessage). However, I have a problem as to
what kind of lists I should allow. For example, I am thinking of supporting
arrays and exec linked lists; I would like a more elegant and generalized
approach! With the current system, not only is memory wasted (i.e. on double
links), but the user must use a special UserData structure containing pointers
to PlainText, IntuiText, and Image structures. This wastes a lot of memory on
each entry (at least 8 bytes) since the user may wish to only have plain text
without the other two. Any advice on this problem (or recommendations) would
be welcome as I would like to make this code public domain in the near future.
Amir Michail
UUCP: crash!pro-generic!amir
ARPA: crash!pro-generic!amir@nosc.mil
INET: amir@pro-generic.cts.comrosenber@ra.abo.fi (Robin Rosenberg INF) (07/14/89)
In article <4603@crash.cts.com>, amir@pro-generic.cts.com (Amir Michail) writes: > I am currently working on some general Amiga scroll box routines. So > far, I use a structure very similar to the Gadget structure which allows > linked scroll boxes on the screen which are checked for input all in one go > (i.e. CheckScrollBox(&First,IntuiMessage). However, I have a problem as to > what kind of lists I should allow. For example, I am thinking of supporting > arrays and exec linked lists; I would like a more elegant and generalized > approach! With the current system, not only is memory wasted (i.e. on double > links), but the user must use a special UserData structure containing pointers > to PlainText, IntuiText, and Image structures. This wastes a lot of memory on > each entry (at least 8 bytes) since the user may wish to only have plain text > without the other two. Any advice on this problem (or recommendations) would > be welcome as I would like to make this code public domain in the near future. Wasting four bytes to get a doubly linked list instead of a sigly linked list is not a waste. Especially since it is much easier to handle, Remember you don't have to use the Node structure. Instead use the MinNode, i.e. just the link fields. Waste memory on the structure and have the overhead only when the object exists or have some hard-to-manage thing that required a lot more code that is allways there. If you can use ROM routines you save code space. Every instruction is at least two bytes. Think 'bout it. And now for some competition (or maybe cooperation) I have written a scrollbox (called it a scrollmenu) to use it in a file requester. It has a vertical scrolling list of items. Each item in the list has an a pointer to an intuitext and an image structure. Thus the box can contain both text and images. I have used it in a file requester to display simple icons depending on whether the entry is a disk, a directory or a file (no icon). It was my intent to release the routines for pd use (file requester, scrollbox and often used gadgets: scrollbars, buttons, checkboxes) but haven't had the time to document the routines. Or do you want them without docs?. The include files are commented and served the purpose as a kind of documentation? If there is an interest I might even send the files 'as is' to Bob. "Real programmers don't document. Documentation is for simps who can't read the object code or the listings." --- Robin Rosenberg, FINLAND
amir@pro-generic.cts.com (Amir Michail) (07/17/89)
Network Comment: to #1230 by rosenber@ra.abo.fi I would like to see those routines! Do they allow multiple scroll boxes on requesters or windows? If so, I may stop developing my own... UUCP: crash!pro-generic!amir ARPA: crash!pro-generic!amir@nosc.mil INET: amir@pro-generic.cts.com