ChrisO
Registered User.
- Local time
- Tomorrow, 05:02
- Joined
- Apr 30, 2003
- Messages
- 3,202
A demonstration of drawing on Forms and Reports.
Note:
This demo replies heavily for display on Stephen Lebans Image Class found here.
It is worth going to his site to have a browse; you never really know what you might find, both interesting and useful.
References required:
None
Tested with Language Packs:
English by ChrisO
Tested with Regional Settings:
English (Australia)
English (United States)
French (Switzerland)
Germany (Germany)
Tested with screen resolutions:
1024 x 768 to 1680 x 1050
Tested with Access Versions:
A2003 by ChrisO
A2007 by John Big Booty
A2010 by Bob Larson
General description of the method of Object use:
A Class Module is an Object and it is important to know that we can have a single pointer to an Object.
For better or worse this demo uses class (object) inheritance to build drawing objects from foundation classes.
The class objects start by defining data types as objects and proceed to be inherited by all subsequent levels through to the top level drawing object. Public constants are also handled the same way, as objects. As required, each drawing object uses constants as objects.
Once the top level drawing object is instantiated it has a single pointer to*, not only itself but, by inheritance, all the objects involved it its build, be they drawing objects or constant objects. As required, each class object has the ability to both document its members and draw itself.
Method of passing the Object build to the Display (Form or Report).
Once a single pointer to* the drawing object has been created it can be passed to the display Form or Report via Open Args. Normally a pointer to an object can not be passed via Open Args but it can be if it is first converted to a data type of Long. In essence then, what we are passing is not the pointer to the object but the value of the pointer to the object. In a 32 bit system the value of the pointer is a 32 bit Long. In a 64 bit system the value of the pointer is likely to be a 64 bit value and this demo does not account for 64 bit systems.
So we convert the value of the pointer to the object to a Long data type and pass that Long value through Open Args. That works fine but it has a restriction; we can only pass one value through Open Args. This is the same for all Open Args values, only one value is passed. We can jump through hoops and pipe delimit a concatenation but, in the end, we are still only passing one value.
The Access Collection:
A Collection in Access is an Object and hence, it too, has a single pointer to* itself.
The Collection object can be filled with other object pointers and that is the method used in this demo. Once a drawing object is instantiated its pointer is added to a Collection. It may only be one object pointer or, as in this demo, it may be up to 24 object pointers. Once the Collection object is filled, the single pointer to* to the Collection is converted to data type Long and passed through Open Args as one single 32 bit Long value.
At the receiving end, Form or Report, the value of the pointer to the Collection is converted back to a pointer to the Collection. When that is done the pointer to the Collection exposes the Collection’s Count property. An index to the Collection then runs from 1 to the Count property and each index retrieves the pointer to the top most drawing object contained in the Collection Item property. The draw method of that top most drawing object is then called which draws it and its entire sub objects as well.
In essence then, we stuff object pointers into a Collection and pass the single pointer to that Collection. When received by the Form of Report we pull the object pointers out of the Collection and draw the objects.
How the pointer is used at the receiving end (Form or Report):
On the Form:
The .ShowMembers() function is called to display the values used to create the objects.
The .Draw method is called to display all the objects it contains.
On the Report:
.Descriptor.Name.Text is passed to a progress Form to display the draw name of the object being drawn.
The .Draw method is called to display all the objects it contains.
The drawings.
There are two sets of drawings available.
Stephen Lebans:
His drawing methods are maintained as per his PictureBoxA97 demo available from the link in Notes above. The only drawing method by Stephen used in this demo is his DrawLine method which is used to draw the grid on the Form.
Mine:
I’ve added three drawing methods, DrawEllipse, DrawPie and DrawPolygon.
DrawEllipse handles both circles and ellipse based on aspect ratio.
DrawPie, at this stage, only draws in an aspect ratio of 1.
DrawPolygon differs from Stephen’s DrawPolygon in that it is only a regular polygon. As such it does not require Stephen’s clsVertices class because the sides are calculated from the number of sides selected. It does, however, have an aspect ratio and a start angle for rotation. They too are included in the calculation and rotation starts at 0 degrees, which is 3 o’clock, and runs counter-clockwise.
Therefore, if you require a regular or irregular polygon please use Stephen’s DrawPolygon method. If you only require a regular polygon with aspect and rotation then mine may be simpler to setup the data.
Flood fill of drawings:
Very problematic.
I can not cover all drawing situations and so if you get unexpected results please try the multiple drawings in a different way.
Dimensions of drawings in general:
We can not trust our eye when looking at drawings on the screen.
Stephen’s and my drawings are both done in pixels and that’s the way the API calls work. So the ratio of screen resolution X and Y can change the symmetry of what we see. Also, if we work with a wide screen then the pixels may not be laid out symmetrically. Therefore, if we want to draw a round circle the only way to determine if it is round is to measure it on the screen. You may be surprised what you get when the drawing is measured. Likewise Reports may not print symmetrically and so, if it is required for the Reports objects to be symmetrical then they too should be measured.
Memory Usage:
Forms:
They behave as expected.
This demo includes a non-destructive testing facility whereby object displays can be cycled continuously. Memory creep is non-existent and can be verified by viewing the Commit Charge in Task Manager. A check box is included to display Task Manager but it may or may not work in your situation.
Reports:
Please be careful when sending multiple drawings to a Report.
Reports do not seem to release memory in the same way as do Forms. Therefore the Commit Charge, as shown in Task Manager, will continue to increase as the drawings are processed. The result can be an out of memory error if too many drawings are processed on any single Report opening. It all depends on your system memory configuration and that I can not test.
Error handling:
None; you may be on a run to crash.
If you have any questions please ask them in the appropriate forum.
Regards,
Chris.
Note:
This demo replies heavily for display on Stephen Lebans Image Class found here.
It is worth going to his site to have a browse; you never really know what you might find, both interesting and useful.
References required:
None
Tested with Language Packs:
English by ChrisO
Tested with Regional Settings:
English (Australia)
English (United States)
French (Switzerland)
Germany (Germany)
Tested with screen resolutions:
1024 x 768 to 1680 x 1050
Tested with Access Versions:
A2003 by ChrisO
A2007 by John Big Booty
A2010 by Bob Larson
General description of the method of Object use:
A Class Module is an Object and it is important to know that we can have a single pointer to an Object.
For better or worse this demo uses class (object) inheritance to build drawing objects from foundation classes.
The class objects start by defining data types as objects and proceed to be inherited by all subsequent levels through to the top level drawing object. Public constants are also handled the same way, as objects. As required, each drawing object uses constants as objects.
Once the top level drawing object is instantiated it has a single pointer to*, not only itself but, by inheritance, all the objects involved it its build, be they drawing objects or constant objects. As required, each class object has the ability to both document its members and draw itself.
Method of passing the Object build to the Display (Form or Report).
Once a single pointer to* the drawing object has been created it can be passed to the display Form or Report via Open Args. Normally a pointer to an object can not be passed via Open Args but it can be if it is first converted to a data type of Long. In essence then, what we are passing is not the pointer to the object but the value of the pointer to the object. In a 32 bit system the value of the pointer is a 32 bit Long. In a 64 bit system the value of the pointer is likely to be a 64 bit value and this demo does not account for 64 bit systems.
So we convert the value of the pointer to the object to a Long data type and pass that Long value through Open Args. That works fine but it has a restriction; we can only pass one value through Open Args. This is the same for all Open Args values, only one value is passed. We can jump through hoops and pipe delimit a concatenation but, in the end, we are still only passing one value.
The Access Collection:
A Collection in Access is an Object and hence, it too, has a single pointer to* itself.
The Collection object can be filled with other object pointers and that is the method used in this demo. Once a drawing object is instantiated its pointer is added to a Collection. It may only be one object pointer or, as in this demo, it may be up to 24 object pointers. Once the Collection object is filled, the single pointer to* to the Collection is converted to data type Long and passed through Open Args as one single 32 bit Long value.
At the receiving end, Form or Report, the value of the pointer to the Collection is converted back to a pointer to the Collection. When that is done the pointer to the Collection exposes the Collection’s Count property. An index to the Collection then runs from 1 to the Count property and each index retrieves the pointer to the top most drawing object contained in the Collection Item property. The draw method of that top most drawing object is then called which draws it and its entire sub objects as well.
In essence then, we stuff object pointers into a Collection and pass the single pointer to that Collection. When received by the Form of Report we pull the object pointers out of the Collection and draw the objects.
How the pointer is used at the receiving end (Form or Report):
On the Form:
The .ShowMembers() function is called to display the values used to create the objects.
The .Draw method is called to display all the objects it contains.
On the Report:
.Descriptor.Name.Text is passed to a progress Form to display the draw name of the object being drawn.
The .Draw method is called to display all the objects it contains.
The drawings.
There are two sets of drawings available.
Stephen Lebans:
His drawing methods are maintained as per his PictureBoxA97 demo available from the link in Notes above. The only drawing method by Stephen used in this demo is his DrawLine method which is used to draw the grid on the Form.
Mine:
I’ve added three drawing methods, DrawEllipse, DrawPie and DrawPolygon.
DrawEllipse handles both circles and ellipse based on aspect ratio.
DrawPie, at this stage, only draws in an aspect ratio of 1.
DrawPolygon differs from Stephen’s DrawPolygon in that it is only a regular polygon. As such it does not require Stephen’s clsVertices class because the sides are calculated from the number of sides selected. It does, however, have an aspect ratio and a start angle for rotation. They too are included in the calculation and rotation starts at 0 degrees, which is 3 o’clock, and runs counter-clockwise.
Therefore, if you require a regular or irregular polygon please use Stephen’s DrawPolygon method. If you only require a regular polygon with aspect and rotation then mine may be simpler to setup the data.
Flood fill of drawings:
Very problematic.
I can not cover all drawing situations and so if you get unexpected results please try the multiple drawings in a different way.
Dimensions of drawings in general:
We can not trust our eye when looking at drawings on the screen.
Stephen’s and my drawings are both done in pixels and that’s the way the API calls work. So the ratio of screen resolution X and Y can change the symmetry of what we see. Also, if we work with a wide screen then the pixels may not be laid out symmetrically. Therefore, if we want to draw a round circle the only way to determine if it is round is to measure it on the screen. You may be surprised what you get when the drawing is measured. Likewise Reports may not print symmetrically and so, if it is required for the Reports objects to be symmetrical then they too should be measured.
Memory Usage:
Forms:
They behave as expected.
This demo includes a non-destructive testing facility whereby object displays can be cycled continuously. Memory creep is non-existent and can be verified by viewing the Commit Charge in Task Manager. A check box is included to display Task Manager but it may or may not work in your situation.
Reports:
Please be careful when sending multiple drawings to a Report.
Reports do not seem to release memory in the same way as do Forms. Therefore the Commit Charge, as shown in Task Manager, will continue to increase as the drawings are processed. The result can be an out of memory error if too many drawings are processed on any single Report opening. It all depends on your system memory configuration and that I can not test.
Error handling:
None; you may be on a run to crash.
If you have any questions please ask them in the appropriate forum.
Regards,
Chris.
Attachments
Last edited:
