Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!hao!oddjob!gargoyle!ihnp4!laidbak!daveb From: daveb@laidbak.UUCP (Dave Burton) Newsgroups: comp.lang.c Subject: Re: Screen Design Packages for the PC Message-ID: <1123@laidbak.UUCP> Date: Fri, 28-Aug-87 13:06:48 EDT Article-I.D.: laidbak.1123 Posted: Fri Aug 28 13:06:48 1987 Date-Received: Sun, 30-Aug-87 02:10:34 EDT References: <8988@brl-adm.ARPA> Reply-To: daveb@laidbak.UUCP (Dave Burton) Organization: is pretty bad/My methods of Lines: 116 Your question is not complete, or the answer you seek is quite comprehensive. Several points need to be addressed before you decide on (or specify) a screen management system. Some of the questions you need to identify are: - monitor type: MGA, CGA, EGA or any - text or graphics based - interactive or batch (more later) - memory model desired - ease of design/change of the application screens - screen based or program based screen generation There are other points to address, but these are the questions which will most dominate your decision. Because of these ambiguities, I will describe our environment and the options we considered. "We" defines a company I quit very recently and definitely NOT my net host. The system under development was mainly oriented towards user data entry. Our computing environment was: IBM-PC/XT's and IBM-PC/AT's, IBM CGA monitors all 100% "True Blue". Our compiler was Microsoft 4.0. All data entry was text mode, with a medium resolution graphics screen as the introduction. Data entry was VERY interactive (this means that data was to be checked/verified AS the operator typed, including file lookups, range checking, data format enforcement, field-per-field help, etc.). All programming was small model. Screens had to be relatively easy to design and modify (we fudged a little on this requirement). And screens were to be stored in the data segment -- we operated on the IBM notwork; data access is too slow for highly inter- active multi-screen operation. ***** ADMS ****** Our earlier systems were based on IBM's Advanced Display Management System (ADMS). ADMS was strictly text based, using only the first page of the IBM-PC CGA. It is now a defunct product, although I have heard rumors of ADMS II. Disadvantages: required a TSR (terminate-stay-resident) driver disk based screen files no source code batch screen validation (for the most part anyway - very primitive) Advantages: IBM (our company thought so anyway) handled normal, shifted, control and alt function keys relatively easy screen updates w/no impact on program code ***** Blaise C-View ****** FLAME-FLAME-FLAME-FLAME DO NOT USE THIS SEVERLY BRAIN-DAMAGED PRODUCT! The company makes claims that, while *barely* true, are very misleading. If anybody wants, I could probably drag this one out a long ways. Disadvantages: converted Pascal product - not even a good port at that! wasteful of disk space horrible screen editor S-L-O-W, especially over a network cheap data validation routines Advantages: has source code (excellent style, but data structures are Pascalian) relatively easy screen updates w/little impact on program code ***** Vitamin C ***** This product has lots going for it. It follows C philosophy extremely well, is very well documented, has excellent functionality (very similar to DBase screen stuff) and has a decent screen editor available - separately. This could be a good choice, it is definitely a candidate. Advantages: WINDOWING capability data entry routines for most every purpose data validation routines for most every purpose, easy extensible screens built by program code - you do the work can handle text and graphics screens good keyboard handling expertly designed internally source code available Disadvantages: screens built by program code - you do the work memory pig - small model programs will be difficult ***** C Spot Run ***** I did not use this product, but did look at its documentation and run some sample programs. I think it is shareware, about $50 WITH source code. The product LOOKS well rounded and the demo programs were efficient. You should look for this one on some of the PC BBS systems. At $50, you can't go wrong! Advantages: WINDOWING capability source code available can handle text and graphics screens sound capability good keyboard handling screens built by program code - you do the work Disadvantages: screens built by program code - you do the work not backed by an IBM We reviewed several other packages as well, but I don't remember much about them. After we finished specifying the functionality of our system and the desired level of user control, we "rolled our own". Admittedly, this is no minor task, but none of the products we looked at could meet our requirements. We probably would have used Vitamin C had we not been limited to the small model. I probably would have used C Spot Run -- it is very similar to the screen manager I developed (no back-patting here :-)). Another good source for information is Computer Language magazine. Not long ago, June, July or August issues, CL ran a comparison of several systems. Doctor Dobb's Journal is another good source, but their last coverage is further back. One last thing. You might seriously consider using a DBMS product to base your system on, then write some C code to do the difficult things. The better DBMS products (filePro, Unify, Informix) have excellent facilities to get most of the work done - especially the data entry/validation. -- --------------------"Well, it looked good when I wrote it"--------------------- Verbal: Dave Burton Net: ihnp4!laidbak!daveb V-MAIL: (312) 505-9100 x325 USSnail: 1901 N. Naper Blvd. #include Naperville, IL 60540