Path: utzoo!utgpu!watserv1!mgardi
From: mgardi@watserv1.waterloo.edu (Mutual Life)
Newsgroups: comp.lang.c++
Subject: commonview
Keywords: commonview,windows
Message-ID: <600@watserv1.waterloo.edu>
Date: 13 Jan 90 16:54:14 GMT
Distribution: comp
Organization: U of Waterloo, Ontario
Lines: 82


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