Order of Events
Now, compile the program and launch it with the Windows "Run" command. Resize it several ways. Watch the shape of the rectangle as you do the resizing. Careful observation reveals that if the form only shrinks, the shape of the rectangle does not change. If the form enlarges either horizontally or vertically or both, the shape of the rectangle changes appropriately. An expected event is not firing. This calls for further investigation.
In the variable declaration section add:
EventFile: TextFile;
So that an "Event.Log" text file opens for writing at program start, and closes at program end, make the end of the unit look like this:
initialization assignFile(EventFile,'Event.Log'); rewrite(EventFile); finalization closeFile(EventFile); end.
To record each firing of the OnPaint event, at the beginning of FormPaint add the following:
writeln(EventFile, 'Paint '+IntToStr(TimeGetTime));
TimeGetTime is a Windows API call that returns the number of milliseconds since Windows last loaded. To access it the unit needs MMSystem in the uses clause. Now, to log each firing of the OnResize event, at the beginning of FormResize add this line:
writeln(EventFile, 'Resize '+IntToStr(TimeGetTime));
Now compile and run as before. Wait about one second. Shrink the form from the right side. Wait another second. Shrink the form from the bottom. Wait another second. Enlarge the form a little at the bottom. Now close the form. Examine the contents of the Event.Log file in the current (project) directory. At the top of the file are "Resize" and "Paint" with nearly identical time stamps, only l0 or 20 milliseconds apart. They fired at program start. About 1000 milliseconds later (depending on the accuracy of the "one second" wait) is another "Resize" line. That fired when the form shrank from the right side. Another 1000 milliseconds later is another "Resize" entry, which fired when the form shrank from the bottom. Still 1000 millisconds later is another "Resize" followed shortly by a "Paint."
After careful consideration, this makes sense. When the form shrinks, Windows only sends a Resize message. Why should Windows send a Paint message just for the covering of some already painted territory? Only form enlargement in one or both directions exposes new area that needs painting. Windows does not know about the special need to adjust the interior of the form. Since the Windows Resize and Paint messages are what trigger the Delphi OnResize and OnPaint events, a form shrinkage does not trigger the necessary adjustment of the rectangle.
The way to remedy this little problem is to call FormPaint on those occasions when it would otherwise be neglected. FormResize is called for every OnResize event, so that is a good place to check whether either dimension enlarged. If not, then no OnPaint event happens, so you must call FormPaint directly. After cleaning out the text file code, add these fields to the private section of the form type declaration:
oldw, oldh: integer;
The fields preserve the previous width and height for comparison with new values. Initialize them at the end of the FormCreate method:
yldw := ClientWidth; oldh := ClientHeight;
Finally, this code at the end of FormResize insures the FormPaint method always fires when needed:
if (ClientWidth<=oldw) and (ClientHeight<=oldh) then
FormPaint(Sender); oldh := ClientHeight; oldw := ClientWidth;
Save, compile and run (from Windows). Resize to your heart's content. Matrices and Command Placement
At this point the program is ready for a little experimentation with glOrtho. Change left from -1.0 to 0.0, then save, compile and run as before.
Remember that the values given to the vertices of the rectangle are relative to the clipping volume. Since the range of horizontal numbers in the call to glOrtho is half the former range, the rectangle should be twice as wide as before. Program execution shows that to be the case. Now, resize the form exactly one time. Something is wrong! The rectangle jumps to the left side. Resize the form again. The rectangle is gone, never to be seen again!
This experience exposes another important concept. OpenGL relies heavily on matrices. A matrix is a two-dimensional array of numbers for which a special set of mathematical operations apply. For every call to glOrtho, OpenGL creates a matrix from the parameters and multiplies it by the projection matrix. Each successive call changes the projection matrix. The symmetrical numbers passed to glOrtho just masked the potential strange behavior, but the unbalanced numbers for this version exposed the problem. One solution is to move the call to glOrtho to the last line of the FormCreate method. Save, compile and run. Resize the form a few times. Now the expected behavior manifests itself.
|
Previous |
Table of Contents |
Next |
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.
® O Q Ö @
search riv itkhowleme faq sitemap comtact iis
^ search tTKHOWLCDGE
|
Keyword | |
- Brief O Full
- Brief O Full
- Advanced Search
- a href="http://www.itknowledge.com/search/search-tips.html"> Search Tips
- Advanced Search
- a href="http://www.itknowledge.com/search/search-tips.html"> Search Tips
|
tu browse ÖY TOPIC | ||
To access the contents, click the chapter and section titles.
Delphi Developer's Guide to OpenGL
(Publisher: Wordware Publishing, Inc.) Author(s): Jon Jacobs ISBN: 1556226578 Publication Date: 08/01/99
- Search this book:
|
Previous |
Table of Contents |
Next |
Go ahead and experiment some more with passing different values to glOrtho, leaving everything else the same. These variations should give a sense of the relationship between the values in the projection matrix and the values of the vertices.
Average user rating: 5 stars out of 2 votes
Post a comment