hartquis@batcomputer.tn.cornell.edu (E. Eugene Hartquist) (04/23/88)
This is one persons opinion of Activision's Reports (tm) (long) My application is a directory stack (name, title, company, address, phone, e-mail address, etc) with the ability to categorize entries (personal, business, club member, Chrismas Card, etc.) It has facilities for producing mailing labels, mail merge files and directory listings. The problems come in producing a nicely formatted directory. I tried using a mail merge file in much the same way as the XREF stack does it, but MS Word is very fragile here and it breaks when I try to list more than 100 or so addresses. It is also very good at hiding problems when you try to debug a document/mail merge file combination. You often get some meaningless message and no information about where in your merge to look for the problem. (Take note Mr. Gates, here is an excellent area to target for improving Word.) Reports sounded like the best thing since slice bread for this application. Nope. The problems: 1) Reports has a bug that crashes your machine with an ID=5 error if you try to use the select feature. That's not so bad. There is a fix on Activision's BBS (and other places -- call them). I tried for two days to call into their BBS. No answer, so the bug hasn't been fixed in my copy. 2) You can put information from card fields into little boxes in your report, each box is able to handle one font. Hmmm...that is a problem if you are trying to put together first name, last name, and professional title, with the last name in bold, so that it looks like something. The solution is to write a script -on DetailSection- to format the name and the put it into one box, forgetting about the fancy bold stuff. Carry this to the extreme, where you format whole addresses using a script and put the whole thing into one box. Now the smallest address take up as much room on the page as the biggest one. I began to wonder, where is the gain in using Reports. 3) Along the same lines, Report provides these nice rulers to aligning things -- but there are no little reference lines in the ruler to tell you where you are. You just have to eyeball it. And, I never did figure out what the default margins were or how to measure from the edge of the paper to where I wanted something. You simple fiddle with things and print again until you have something that looks presentable. The preview feature isn't always helpful. 4) To use Reports you MUST put a ReportCard into your stack. Do you have any idea the havoc this causes in an otherwise smoothly functioning stack? Suppose you land on the ReportCard and ask for information from a field that isn't there? Also, it subverts things that you set up in your stack. E.g. the idle handler I used failed, I set UserLevel to 2, it set it to 5, etc. When I got the stack sort of functional again, scripts began to looked like haywire (a reference to the method of programming computers with a plug board). I began with the ReportCard at the back of my stack (I wanted it out of the way until it was needed.) When the stack is sorted the ReportCard works its way toward the front of the stack and finally becomes the second card in the stack, which is not where I wanted it. Now, Reports began to look like more effort than its worth. 5) Trying to move my stack from a Mac II to a Mac Plus proved to be the final frustration. I wanted to find out how you move a stack that uses reports. Well, I could not get it to work without or with Reports installed on the Mac Plus. (Okay, you don't necessarily want to move your stack to another machine anyway because it will cost some hundreds of dollars, roughly the cost of 10 copies of Reports to distribute a stack as shareware with the Reports function in it. I checked.) If you want a RIGIDLY formated report, perhaps with graphics, you can tolerate a foreign card in your pristine stack, you have lots of patients with getting little boxes aligned correctly and you have no plans to share your stack (or you plan to sell it at a good price) then Report is for you. (And, you can have it.) Least you think I am a grinch let me tell you about this delightful little DA called Word Finder. The posing will be in comp.sys.mac. -- Gene
barad@tulane.tulane.edu (Herb Barad) (04/24/88)
In article <4536@batcomputer.tn.cornell.edu> hartquis@tcgould.tn.cornell.edu (E. Eugene Hartquist) writes: >I tried using a mail merge file in much the same way as the >XREF stack does it, but MS Word is very fragile here and it >breaks when I try to list more than 100 or so addresses. It >is also very good at hiding problems when you try to debug a >document/mail merge file combination. You often get some >meaningless message and no information about where in your >merge to look for the problem. (Take note Mr. Gates, here is >an excellent area to target for improving Word.) Yup. I have to agree. Ever since I wrote Xref, I have been extremely frustrated for the same reason. MS Word chokes on any document that is big. I wrote and tested Xref with small documents (~10 pages), and then I tried it on my thesis - BINGO! Well, it's for this reason that I have no longer tried to improve Xref. I had a lot of things in mind: more options to format bibliographies and cross-references the way others might like it (not just the way I needed it), XCMDs and XFCNs to speed things up, etc. Maybe someday Microsoft will fix Word. I'm not going to wait. I have seen a demo of FullWrite. It doesn't handle bibliographies quite the way I want, but maybe I can adapt Xref for FullWrite in particular... Hmm, just a thought for now. -- Herb Barad Electrical Engineering Dept., Tulane Univ. USENET: barad@tulane.uucp INTERNET: barad@tulane.edu
halff@nprdc.arpa (Henry Halff) (04/27/88)
> There is a fix on Activision's BBS (and other places -- > call them). I tried for two days to call into their BBS. No > answer, so the bug hasn't been fixed in my copy. The fix is also on GEnie and CompuServe. And, I understand that Activision is sending it out free to registered users. If you're not using V1.1 of Hypercard, you'd be better advised to upgrade Hypercard. > 2) You can put information from card fields into little boxes > in your report, each box is able to handle one font. The restriction to one font is more of a Hypercard limitation than a Reports limitation. > Hmmm...that is a problem if you are trying to put together > first name, last name, and professional title, with the last > name in bold, so that it looks like something. The solution > is to write a script -on DetailSection- to format the name > and the put it into one box, forgetting about the fancy bold > stuff. Carry this to the extreme, where you format whole > addresses using a script and put the whole thing into one > box. Now the smallest address take up as much room on the > page as the biggest one. Make your address field scrolling (under the Field menu). That way, it will take up only the space needed. > I began to wonder, where is the > gain in using Reports. I begin to wonder, how would you have designed Reports (without redesigning Hypercard) to meet your needs? > 3) Along the same lines, Report provides these nice rulers > to aligning things -- but there are no little reference lines > in the ruler to tell you where you are. You just have to > eyeball it. And, I never did figure out what the default > margins were or how to measure from the edge of the paper to > where I wanted something. You simple fiddle with things and > print again until you have something that looks presentable. > The preview feature isn't always helpful. Things aren't all that bad. Reports has a grid facility and the capability to align selected fields with each other. > 4) To use Reports you MUST put a ReportCard into your stack. > Do you have any idea the havoc this causes in an otherwise > smoothly functioning stack? Suppose you land on the > ReportCard and ask for information from a field that isn't > there? Unnecessary and awkward, I agree. I put checks in my script for the right background. > Also, it subverts things that you set up in your > stack. E.g. the idle handler I used failed, I set UserLevel > to 2, it set it to 5, etc. When I got the stack sort of > functional again, scripts began to looked like haywire (a > reference to the method of programming computers with a plug > board). I began with the ReportCard at the back of my stack > (I wanted it out of the way until it was needed.) When the > stack is sorted the ReportCard works its way toward the front > of the stack and finally becomes the second card in the > stack, which is not where I wanted it. Now, Reports began to > look like more effort than its worth. Keep a copy of your stack without a report card. > 5) Trying to move my stack from a Mac II to a Mac Plus proved > to be the final frustration. I wanted to find out how you > move a stack that uses reports. Well, I could not get it to > work without or with Reports installed on the Mac Plus. Bad news. Activision should at least offer a de-install facility. > (Okay, you don't necessarily want to move your stack to > another machine anyway because it will cost some hundreds of > dollars, roughly the cost of 10 copies of Reports to > distribute a stack as shareware with the Reports function in > it. I checked.) Bundle a report-card-free copy of the stack along with any Reports documents that it uses. Shareware users with Reports can install a report card in the stack and then install your Reports formats in the report card. People without Reports couldn't use your Reports formats, but, then again, you can't use shareware Excel templates without Excel either. > If you want a RIGIDLY formated report, perhaps with graphics, > you can tolerate a foreign card in your pristine stack, you > have lots of patients with getting little boxes aligned > correctly and you have no plans to share your stack (or you > plan to sell it at a good price) then Report is for you. > (And, you can have it.) I think you're giving a good program a bad rap. It's got some problems and some bugs, but it also has some pretty sophisticated features, like escapes to hypertalk in mid report. hh
hartquis@batcomputer.tn.cornell.edu (E. Eugene Hartquist) (04/30/88)
To Henry Halff: Thanks for your comments re. my "bad rap" aimed at Reports. You, and others, have taught me a thing or three more about Reports than I knew when I posted my comments. Guess that is how we learn. Wade Blomgren, in a private mail writes; Might it be possible to leave the "report card" in another otherwise empty (separate) stack until it is actually needed to produce a report in your main stack, then have your stack go get the "report card" and paste it into itself, deleting it when the the report process is complete? I think so, but didn't think of it and haven't tried it. Does someone have an answer? Sorry, I am not ready to retract my bad opion of Reports. At very least developers of other HyperCard utilities ought to be aware that one Reports user found that a foriegn card in a stack can be very troublesome and might avoid that technique. At best Activision or a competitor may come up with a better product. Why would I spend time on this if I don't like Reports? Well, I need a better report generator of some sort. I am open to suggestions that will make Reports more palatable. It is a good thing there are people like Wade and Henry to offer them. Really :-) -- Gene
halff@nprdc.arpa (Henry Halff) (05/04/88)
> Wade Blomgren, in a private mail writes; Might it be possible to leave > the "report card" in another otherwise empty (separate) stack until it > is actually needed to produce a report in your main stack, then have > your stack go get the "report card" and paste it into itself, deleting > it when the the report process is complete? Or have the report card paste itself into your main stack; see below. > > I think so, but didn't think of it and haven't tried it. Does someone > have an answer? I might. Make a stack (say "Reports Master") with one or more report cards in it. Design layouts for these cards that generate reports for any of the backgrounds in any of your data stacks. (You needn't install a report card in any of your data stacks to do this.) Then add a button to the ReportCard background. The button (call it "External Print") should have the following script. on mouseUp put "Report on what stack?" get sfgetfile("STAK") if it is empty then hide message exit mouseUp end if push this card domenu "Copy Card" go to it domenu "Paste Card" send mouseUp to background button Print domenu "Delete Card" pop card end mouseUp To use the beast, first select a layout (as usual). Then push the External Print button with the above script. You will be asked to choose a stack, and can choose any data stack that has a background for the selected layout. The script will paste a report card into the target stack, print the report, delete the report card from the target stack, and return to the original stack. You'll never need to install a report card in any other stacks. All layouts can be designed in the Master Reports stack as long as their backgrounds are set to the appropriate data stacks. Thanks to Wade & Eugene for coming up with this idea.