mgardi@watserv1.waterloo.edu (Mutual Life) (01/12/90)
I would be interested in swapping some experiences with other Commonview people out there. First some background: We are using CommonView with Windows on a DOS platform. We are developing on 70's with 6Megs of memory. Using the 16M version has not created any compiling problems, but it will not compile anything on a machine with 1M or less. You have to use the !O switch to perform all the substeps separately. It was mentioned that someone thinks that one can control Name Mangling fairly well....Can anyone send me some information on this. I have already run into Naming problems, and the use of the !M4 switch has been discouraged by the Tech support people at ImageSoft. Is 32 character names now an ANSI standard? This is what I was told. Commonview is a neat package, but it should be noted from our experience that it is FAR from complete. To do real programming, we have had to deal with alot of memory managment techniques (because of Windows), and work arounds to implement some 'easy' windows constructs. We would appreciate any discussion that might be available from users re: Global/Local heap allocation : 256 segment restriction, declaration of classes as FAR to be able to pass them into other routines. DLL creation Subclassing. One main problem that we feel is important is the class heirarchy itself. Controls are separate entities than Windows. This creates alot of problems when you want to deal with controls as they are in MS_WINDOWS...simply a window type. ACTOR for instance subclasses both windows and controls from a class WindowObject. Again, I would appreciate any comments from users either by phone, or E-Mail. p. Peter DeVries Mutual Life of Canada c/o mgardi@watdcsu (519) 888-3523 (416) 972-0594
mgardi@watserv1.waterloo.edu (Mutual Life) (01/14/90)
In article <575@runxtsa.runx.oz.au> tom@runxtsa.runx.oz.au (Thomas Antalffy) writes: > >1. Assumed knowledge for understanding the CV is the MS Windows programming. >You cannot have the short cut way to learn the CV without learning the MS >Windows. The CV documentation is too condensed for the beginner. > Agreed. We attended the Microsoft Applications programming course as you need to know alot about MS_WINDOWS to do any real programming. ESPECIALLY when you start dealing with memory management issues such as when to declare classes as NEAR/FAR and how/when to lock the class when passing a reference to another function. We have had to create an ObjectReference object to hold a pointer to our objects along with a pointer to its associated heap. (This is important since as soon as a lock goes out of scope in the containers, the particular segment may move, ruining all references to this object. >2. The main problem I encounter with CV is the poor documentation > >Some Examples. > >2.1 All the Event Handlers in the Window classes have the return value (long). >It does not explain what it is used for. If you overload those Event Handlers, >you do not know what you should return. In the example programs, it usually >returns TRUE. Why ? > Agreed again...The next release is supposed to be shipped with Quick Help, and improved documentation. > >If we create the Controls in the Constructor, the GetText(), SetText() of the >Control classes, will not work. Why ? > This is because the window (and controls) handle was not being assigned until after the Show method was called. This has supposedly been fixed. >3. All CV examples are compiled and work perfectly. But we need some examples >like basic Input Output screen processing : A DialogWindow or AppWindow which >has some Controls (Title, Name, Address, etc.); Some postfuncs to validate each >individual Control right after the user finishes that Control Input (physical >validation), and logical validation before accepting all the input values when >the user finishes the whole input screen (press OK or Cancell button). > >3. If all Controls cannot fit in the window, we would like to have the Scroll >mechanism (HorizScrollBar or VertScrollBar). > >4. We also try to achieve the Dynamic Screen handling : the number of Controls >can be added, deleted, moved, to the Window on the fly, and the Window scrolls >if they cannot fit in. > We always assumed that we would have to write our own Window layer to work on top of commonview as this package only supplies the bare bones to do OO programming in Windows. We are designing our controls as Templates that interface with a template manager that controls placement, scrolling etc. The application should not need to know anything about the technical details in showing its pieces. >5. How does the CV application can call MS Windows functions directly ? In >the CV manual, it says that some CV classes provide the Handle, so that we >can communicate with MS Windows directly. But we do not know how. In one of >our CV program, we call ScrollWindow() of the MS Windows, but the Link4 cannot >find it. > This is because MS_C (or the linker?) DEMANDS that there be a function prototype declared before the function is called. Simply grab the function Prototype from Windows.h and include it in your files, and everything will link properly. Of course, we needed to also include all the associated typedefs, and #defines etc. We find it unnecessary to include windows.h in our files. We simply create our own header with all the appropriate function prototypes, #defines etc.. Hope this helps. p. Peter DeVries Mutual Life of Canada c/o mgardi@watdcsu (519) 888-3523 (416) 972-0594