Path: utzoo!utgpu!attcan!uunet!husc6!rutgers!mailrus!ames!pacbell!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.sys.amiga Subject: Re: S/W Installation methodology Message-ID: <10235@well.UUCP> Date: 5 Jan 89 21:17:33 GMT References: <2071@van-bc.UUCP> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Organization: The Blue Planet Lines: 72 +-- Mike Robinson writes: | I want to see programs and subroutines coming out on Fish disks to help | me write Amiga programs more easily. For example, think about how much | work you have to go through to create menus and dialog boxes in | Intuition. I come not to bury Caesar, but there are better ways to | approach this than to code all those data structures by hand. Agreed. I gave up on trying to hard-code Intuition structures long ago. | How about a program that will allow you to construct a menu, or a dialog | box, or a control panel... interactively? There are some. PowerWindowsII is the only one I've tried. I don't use it for two reasons: 1) It's horribly under-documented. The "manual" is a tiny stapled together pamphlet like one you might get with your new toaster, and the program clearly has features that are not even mentioned. 2) There's a bug which makes gadget hitboxes slightly smaller than their surrounding borders so that the gadget has annoying little gaps when highlighted. I do use it for converting brushes to Images, however. | (If an interactive program is too ambitious, then a simpler design which | uses a flat file prepared with a text editor would a good alternative.) This is what I did for designing all the Requesters in Modeler 3D. I wrote a simple "compiler" that takes a description of a requester layout and generates code. It also lets you preview the result in a little window. Although interactive methods are nice, there are some advantages to the "flat file" method. The "compiler" program can be called from a makefile, so that the Requester description file becomes just like another source file in your program. Also, the description file contains almost no numbers, so that the positions and sizes of things are computed relative to each other. This means that if I ask for a gadget to be centered, I know it will be exactly centered, rather than centered as well as I could guess using my eye. And, if I change other parts of the Requester, that gadget will *stay* centered, even if it changes absolute position. There's a version of my requester generater on some Fish disk (shame on me, I can't remember the number -- 130-something?) with some examples. I have a newer version which supports a full "C"-style pre-processor (which the old one sorely needs). The new one has the added advantage that I can create macros for commonly used structures -- something that few interactive construction sets will let you do. | Instead of coding all those menu statements by hand, how about this? | | MAKEMENU(WINDOW,"\001Project\002About...\002Quit\001File\002Open") | | This subroutine would read the string, and build standard control blocks | in memory at runtime. Otherwise they would be a black box. I did something like this for the menus in Modeler as well. The structures constructed by the programmer are more complex than the above, but not much, and the menus are constructed at run-time. I needed this for Modeler since it can have multiple copies of the same class of window, and each needs its own copy of the menu structure so that the checkmark items can be different for each window. Another advantage to the run-time construction is that the menus can adapt to different sized fonts, screen resolutions, etc. I'm currently stripping that section out of the Modeler code and packaging it up as a general tool. Once I can work out the tricker details I ignored before, I'll send it to Fred and perhaps the "sources" group. | You get the idea. Arguably, these convenience tools would not do | anything that you could not do by hand, nor everything that you might | want to do. But that is the case with any compiler, and we do not | question the usefulness of those. They would give us a head start in | writing "most" "typical" applications, and that is enough. Yes, tools are a wonderful thing. You almost never have "too many" tools. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC