<html><head>
<TITLE>Windows screen design</TITLE>
</head>
<body background = "..\images\wmarble.gif" text="000000" linkcolor="FF0000">

<center><h1>Windows screen design</h1></center>

<strong>Warning: Part of the following is not yet implemented. This document is partly done as a
"document before you code" excercise and to provide as much information to developers in as early a
stage as possible; feedback is welcome</strong><p>

<strong>ADDITIONAL INFORMATION: I have made significant enhancements/changes to the way we propose
to handle the not auto-activated zooms/subsystems. This is a VERY DRAMATIC change compared to the
convential Classify UI, but we feel it is more compliant to the usual Windows way of working. See
the header "Non FAAZ"<p>

Please note that this part is NOT IMPLEMENTED, not will it be for beta 1, but it is what we now
feel is the best option we have come up with YET. Feedback please: is this it, or did we loose
our mind?</strong><p>


Known unfinished parts:
<ul>
<li>Subsystem offset
<li>Saving & retrieving locations and stuff (keep an empty HDSZM for testing!!)
<li>Saving auto activate in regular views
</ul>

<hr>
<p>

<h2>Table of contents</h2>
<ul>
<li><a href="#Intro">Introduction</a>
<li><a href="#DPSBS">Dynpress on the subsystemlevel</a>
<li><a href="#NONFAAZ3x">Not fully-auto-activated-zooms (Non-FAAZ), Windows 3.x</a>
<li><a href="#NONFAAZ95">Not fully-auto-activated-zooms (Non-FAAZ), Windows 95</a>
<li><a href="#Locations">Saving locations and auto activate</a>
<li><a href="#Overview">Quick overview</a>
</ul>

<A NAME="Intro"><h2>Introduction</h2>

When it comes to designing screen in Windows, using a visual drawing tool is the most popular
method. However, when you have to deal with massive numbers of screens, various resolutions, custom
fonts and end-user configuration drawing images by hand is no longer all that attractive. This is
why Calvin Consultancy developed DYNPRESS (<b>Dyn</b>amic <b>Pres</b>entation <b>S</b>pecification).
This is a screen design method that works on two major assumptions:
<ul>
<li>You do not want data or screen texts to be truncated.
<li>You will want fields and descriptions to allign as much as possible.
</ul><p>
The primary use for the DYNPRESS logic was to be able to specify zooms without a visual designer.
This is discussed in the appendix "Windows consideration" in the Classify handbook (and is a good
introduction to DYNPRESS). However, DYNPRESS is a technique written to be used for any "formatting"
task. This has allowed us to reuse the DYNPRESS class to generate the character mode screens in the
WorkBench zoom definition and in the generation of HTML pages.<P>

<hr><A NAME="DPSBS"><h2>Dynpress on the subsystemlevel</h2>

For our Windows environments, we have now added DYNPRESS support to subsystems, so that you can use
dynpress logic to position entire zooms inside a subsystem. In this class, zoom objects that are
"fully auto activated" are represented without their own border and hence should be
positioned very carefully. Since the DYNPRESS logic on the zoom level automatically calculates the
required size of the object, specifying a location in the traditonal sense would be almost
impossable.<p>

So we allow you to specify dynpress locations in the subsystem definition for a given zoom. This
should realy only be done for "fully auto activated zooms" (FAAZs) because setting a dynpress
location for any other object will automatically disrupt the layout of the entire view. We might
even prevent setting dynpress locations in non-FAAZs in the future. Likewise, NOT setting a dynpress
location for a FAAZ will produce unpredictable results.<p>

A zoom is a FAAZ if not only the zoom itself is auto-activated, but also the subsystem it is
contained in, and if that subsystem is nested, the all parents must be aut activated as well.<P>

When you use Classify for Windows 3.x (DF305x), you must use the cView_Panel class to enable these features.
In Classify for Windows 95 (Visual DataFlex), the DYNPRESS for zooms is handled automatically by the subsystem
class. In both cases, a single panel can display information about multiple subsystems though.<p>

The size of the panel be adjusted automatically to contain all the FAAZs. The FAAZs will not be
seperated by any borders, so the entire view will look as a single object to the user. If you want
to provide some visual "border" around the objects, you can set the pEffect property of a zoom
(we recommend you do this at the SBS definition level as well).<P>

This brings out another problem. Suppose you have two zooms next to eachother. One is 6" high, the
other 5", both showing a border. You would like to show these borders at the same height. This means
you should increase the height of the second object. But DYNPRESS determines this size. And even
worse, the same object could be re-used in another subsystem next to a an object that is 5" high as
well!<P>

To help you in this area, we added two properties. pHeight_Allign and pWidth_Allign. If you set
these, we will increase the hight/width of the object to occupy the full column, as calculated by
DYNPRESS. For "forms", nothing changes except the 3d border (using these properties on a
form-based zoom without pEffect set has no visable effect). If you use these properties in an edit
object however, the size of the edit area will grow to match the object size. This allows you to
neatly size the edit object to allign with the 3d borders.<P>

<h3>Subsystem offset</h3>
Since you might want to reuse the same subsystem in multiple locations, we have added a Dynpress
Offset to the subsystem. This allows you to specify a location of the entire subsystem within a
view. The row/column you specify in this property will be ADDED to the dynpress locations specified
for the zoom.<p>

We recommend you put these settings in the view definitions. In Classify for Windows 95, these settings
are ignored for every subsystem that has its own panel.<p>


<hr><A NAME="NONFAAZ3x"><h2>Not fully-auto-activated-zooms (Non-FAAZ), Windows 3.x</h2>

For Classify For Windows 3.1, non-FAAZ's will appear in the option pull down and when activated, they will
show up in the view-panel with their own panel. They can be dragged around and deactivate much like in
character mode. However, contrary to character mode, we do not encourage this since the visual effect could be
considered "un windows like). No other windows application support this sort of data entry.<p>

<hr><h2>Not fully-auto-activated-zooms (Non-FAAZ), Windows 95</h2>

In Classify for Windows 95, we adopted another strategy. All non-FAAZ zooms are automatically grouped
into a single tab-dialog (which is always automatically activated). The size of the tab-dialog
is based on the size of the biggest zoom contained in it, it's position is set by the pTab_Location
property on the subsystem level (subsystem offset is taken in account for this). You can also
specify pTab_Height_Allign and pTab_Width_Allign, telling the tab dialog to "grow" in order to fit the
other zoom borders.<p>

Obviously, this means that the option pull down will cease to exist in windows. 95<p>

Now the trick is nested subsystemns that are <strong>not</strong> auto-activated. Obviously, it would
be pretty hard to put them in a single tab, because of the amount of information. Before you know it,
you are looking at a "picture in a picture in a ....". So for every not fully auto activated subsystem,
we create a single button. This button can either be located in the final tab of the tab-dialog (labelled
"Links", text changeable using STRING.INC) or at the bottom of the panel. This is controlled by the
pLinks_In_Tab property of the main subsystem.<p>

When the user activates a subsystem thorugh one of these buttons, this results in a new panel containing
the selected subsystem. This panel is build just like the previous panel (so FAAZs, all non-FAAZs in a tab,
all non-FAAZ subsystems as buttons) <strongand</strong> it is non-modal within the view. This means you
cannot access the previous level without exiting this level. Selecting another level of subsystem means
another level of non-modalness.<p>

Other views remain accessable at their current level. Each "subsystem panel" can be dragged over the
entire DataFlex desktop.<p>

<A NAME="Locations"><hr><h2>Saving locations and auto activate</h2>


<h3>Auto activate</h3>

When we designed Classify, we tried to provide as much flexability in the user interface as
possible. We anticipated this would put us in a good position to move to Windows. However, it turns
out that in Windows, monolithic screens are more popular than windows and screen space is actually
harder to come by than in character mode.<P>

Allowing the users to enable/disable auto-activate would mean that we would have to give them also
the ability to specify dynpress locations and allign options for their zooms as well. Whereas this
might provid a nice feature, it is not currently available. So we have disabled the toggle
auto-activate from the menu for all zooms in view panel based views and we ignore any saved values in
the file when we build the panel view.<P>

For regular views, the auta-activate option remains valid.<p>

<h3>Locations</h3>


When saving zooms, we differentiate between zooms in regular views and in zoom panels:
<UL>
<li><strong>In view panels</strong><br>
Obviously, locations are not saved for FAAZs. For any non-FAAZ zoom, we will store the location in
screen units, as an offset to the view location. This means the zoom will reappear in the same
location within the view, but not necessarily on the same location on the screen.
<li><strong>In regular views</strong><br>
The locations are all stored in screen units relative to the DataFlex desktop.
</ul>
<P>

Per view panel, we store the location in screen units relative to the DataFlex desktop.<P>

The location of the desktop is saved in screen units as an absolute location.<p>

Please keep in mind that whereas screen units provide the highest accuracy in positioning, they
might translate badly when moving back and forth between different resolutions.<P>

<h3>Sizes</h3>

We store the size of:

<ul>
<li>View panels
<li>Non FAAZ edit/bitmap objects in view panels
<li>Edit/bitmap objects in regular views
</ul><p>

The size is stored in screen-units.<P>

<A NAME="Overview"><hr><h2>Quick overview</h2>
<table border=2>
<th>Property<th>Class<th>Specify where<th>Action<tr>
<td nowrap>pCreate_Dynpress_Item</td>
<td nowrap>Zoom</td>
<td nowrap>Zoom definition</td>
<td>Create an item in the zoom at a specific row/column</td><tr>
<td nowrap>pDynpress_Location</td>
<td nowrap>Zoom</td>
<td nowrap>Subsystem definition</td>
<td>Specify a row/column for the entire zoom inside the view</td><tr>
<td nowrap>pHeight_Allign</td>
<td nowrap>Zoom</td>
<td nowrap>Subsystem definition</td>
<td>Force the height of the object to full row height</td><tr>
<td nowrap>pWidth_Allign</td>
<td nowrap>Zoom</td>
<td nowrap>Subsystem definition</td>
<td>Force the width of the object to full column width</td><tr>
<td nowrap>pEffect</td>
<td nowrap>Zoom</td>
<td nowrap>Zoom or subsystem definition</td>
<td>Draw a 3d border around the object</td><tr>
<td nowrap>pDynpress_Offset</td>
<td nowrap>Subsystem</td>
<td nowrap>View definition</td>
<td>Offset all zooms in the subsystem with the given values</td><tr>
<td nowrap>pTab_Location</td>
<td nowrap>Subsystem</td>
<td nowrap>Subsystem definition</td>
<td>Specify the dynpress location of the tab-dialog</td><tr>
<td nowrap>pTab_Height_Allign</td>
<td nowrap>Subsystem</td>
<td nowrap>Subsystem definition</td>
<td>Force the height of the tab dialog to full row height</td><tr>
<td nowrap>pTab_Width_Allign</td>
<td nowrap>Subsystem</td>
<td nowrap>Subsystem definition</td>
<td>Force the width of the tab dialog to full column width</td><tr>
<td nowrap>pLinks_In_Tab</td>
<td nowrap>Subsystem</td>
<td nowrap>View definition</td>
<td>Put the links to other subsystems in a tab or at the end of the panel</td><tr>
</table>


<p><hr>
<a href=..\homepage.html>
<img src="/..\images\home.gif" alt="Home" align=left></a>
<center><ADDRESS>&copy Copyright 1995, 1996, Calvin Consultancy</ADDRESS></center>
<hr>