Unfortunately all operating systems do not position windows on the display using the same coordinate system. In the Windows and Motif operating systems, you position a window relative to the upper-left corner of the window it is contained in. Under OS/2, you position a window relative to the lower-left corner of its containing window.
To facilitate developing cross platform applications, the Open Class Library provides you with the ICoordinateSystem class. This class allows you to develop your application based on one of the two coordinate systems, and provides functions to assist you in porting it to a platform with a different orientation. The ICoordinateSystem::EOrientation enum has two values, kOriginUpperLeft and kOriginLowerLeft.
To develop a portable application, we recommend that you pick one of the two orientations and code all of your windows using this orientation. By default, all coordinates are interpreted by the Open Class Library in the operating system's native coordinate system. To change the way the Open Class Library interprets coordinates you must call the ICoordinateSystem function setApplicationOrientation function, passing the EOrientation you wish to use. This will cause the Open Class Library to interpret all input parameters, and return objects based on this orientation. For example, to code all coordinates based on the upper-left corner as in Windows, you would need the following line of code to run the program on Presentation Manager:
ICoordinateSystem::setApplicationOrientation(ICoordinateSystem::originUpperLeft);
You must make this call prior to calling any Open Class Library function that uses the window coordinates.
| Note: | Calling this function after IWindow objects have been created may cause unpredictable results. If your design calls for using an orientation other than the Open Class Library default of native orientation, you should set the orientation early in your program. |
This function does not affect the processing of dialog templates loaded from resource files. The coordinates in resource files are always interpreted in native system coordinates when the dialog is being loaded.
There may be situations where you will need to deal with the native coordinate system. For example, if you develop your own control and make the calls to the operating system to create the control or to move and size it, you must specify the window's position and size in native coordinates. The Open Class Library also contains functions to help you with these conversions.
If you are extending the library by writing classes for custom controls or providing other reusable classes based on Open Class Library, then you should consider using this class to provide coordinate mapping for your users. Coordinate conversion is needed when you make calls to system routines which accept points or rectangles. It also may be needed if you rely on a specific orientation to perform layout of windows or graphics.
You can determine the native and application orientations by calling the ICoordinateSystem functions nativeOrientation and applicationOrientation respectively. When they return different values you need to convert the coordinates of objects that are passed to and returned by you. The ICoordinateSystem function isConversionNeeded is the best way to determine if you must make conversions. It returns true if the native and application orientations are different.
When developing cross-platform applications, you may need to use the following member functions to manipulate the orientation of your application objects:
This function returns a point or rectangle in application coordinates. This is computed from a point or rectangle expressed in native orientation and a reference size (the size of the coordinate space in which the native point coordinate is expressed).
Various graphics and windowing classes, as well as their member functions, use rectangles so when porting applications, you need to understand the different coordinate system mappings.
Objects of the IRectangle class represent a rectangular area defined by two points that form opposite corners of the rectangle. These two points are referred to as the minimum and maximum points. IRectangle objects are designed to be usable independently of the coordinate system in use. The minimum, or origin, is defined as the point with the lowest coordinate values. Therefore, in a coordinate space where 0,0 is the upper left and increasing a point's coordinate value moves it to the right and down, the minimum point of an IRectangle is the top-left corner and the maximum corner is the lower-right corner. Conversely, in a coordinate space where 0,0 is the lower-left corner and increasing a point's coordinate value moves it to the right and up, the minimum corner of an IRectangle is the lower left, and the maximum corner is the top right.
The original functions provided in IRectangle to return points and coordinates had names like lowerLeft and upperRight. So, to get the origin of a rectangle on Presentation Manager you would call lowerLeft(). Unfortunately this is not the origin on Windows or Motif. IRectangle now has new functions that allow you to get information in an orientation aware manner. For instance there are now functions named minXMinY, minXCenterY, and minXMaxY. To write portable applications you should use these new functions exclusively.
You use the IWindow member functions for window positioning to set and query the size and position of windows. Unless otherwise noted, the orientation of the coordinates accepted and returned by these members is the application orientation.
| Note: | IWindow::mapPoint for ITitle::handle
mapping to the desktop returns the wrong data. This
appears to return native coordinates relative to the
application when the default is the PM coordinate system.
These problems arise since on Windows, the following is
true: frame->handle() = title->handle() |
![]()
Transitioning 2D Graphics to IBM Open Class