INDEX v2.9.4 |
509 Center Bay City, Michigan Sales (989) 892-9242             Support (989) 686-8860 |
Pictures and graphics are defined with the PICT specification:
{pict-name} PICT
DISCUSSION
We do lots of work with pictures, both on the screen and for printing.
For screen pictures we do not (usually) define PICT objects in the PLFORM. Rather we create them on the fly in the program.
On the other hand, there have been times when we want to use the designer to set the position of a picture; the designer lets us visually move the picture in relation to other objects on the form.
When we DO use the designer for positioning, we seldom use a PICT object. Rather we use a StatText or EditText. That's just because StatText and EditText objects are simple to deal with in the designer. What's more, we can write notes to ourselves in the text of the object and see them in the designer. We set the property of these objects to NOT VISIBLE so they exist but never actually show up on the screen.
At runtime we'll use GETPROP to get the coordinates of that invisible object. Then we create the picture at that position. Now if we want the picture to be in a different position we can use the designer to move the "anchor object" at will. Recompile the program and the picture moves to match.
To change the image at runtime we just CREATE the PICT object again. That's important in our real estate application. The user has a listview of all their homes. Click on a line in the listview and we show the details including the picture. So the picture changes with every click. (CREATE implicitely destroys the previous object, but sometimes we do the DESTROY within the program.)
About that Real Estate system...
Pictures are stored on the local computer. If we don't have the picture we go to the web and download it from our server.
If the picture is not available at all, we create an EditText the same size as the picture and insert text saying "Picture not Available".
Pictures on the local computer may become stale. The web contains the live pictures. We let the user CLICK on the picture to force the program to go to the web to get the current picture. We use the TOOLTIP property of the PICT to inform the user of the picture's date and to remind them of the CLICK TO REFRESH option.
We're doing two other things with pictures that may be of interest.
First, we have occassions to "float" a picture. In this case we use the designer to create a form with no objects. At run time we FORMLOAD that plform after the main form. It becomes an independent window on the desktop. We create a PICT object, scale the size to match the aspect ratio of the graphic, and adjust the window size to match. The user can move that picture form anywhere on the screen, bring it forward, minimize, sent it backwards, etc.
Second, we sometimes use a picture as a menu. I get our web graphics designer to make up an image including words, pictures and text. I put that image on the plform filling the entire window. When the user clicks anywhere on the picture I get the H:V coordinates of the click to decide what they clicked on. My program can then respond as approriate. Think of it as creating "hot spots" on the form.
MMCC TEST PROGRAMS:
These programs are for MMCC use locally. They are not on the web.
For printing, there is a test program in the Bargain Times system. It's on the BTI TEST button on the full menu.
For screen pictures use PIC-SIZE in the UTIL-PLB system. It tests sizes, properties, zooming and scrolling.
PLFORM RESOURCES
See the RESOURCE article and the RESOURCE program in the UTIL-PLB system for examples of storing a picture in the program as a resoucre and putting it on the screen.
Resources are a great way to distribute pictures which are used within a PL/B program. The pictures become part of the compiled program and you're set.QUICK NOTES:
There are a number of useful items that can be recovered after the picture is created. Some useful METHODS include:image.GetZTop Giving variable (May be in Plbwin 8.7) image.GetZbottom Giving variable image.GetZLeft Giving variable image.GetZRight Giving variableSome useful PROPERTIES include:GETPROP pictfile, TOP=PIC_TOP GETPROP pictfile, LEFT=PIC_LEFT GETPROP pictfile, WIDTH=PIC_WIDTH GETPROP pictfile, HEIGHT=PIC_HEIGHT GETPROP pictfile, PICTSIZEH=PIC_SIZEH GETPROP pictfile, PICTSIZEV=PIC_SIZEVSCREEN PICTURES
Pictures may be defined in the forms designer, but we find it works better to just define them in your program and handle them that way. If we want to place the picture in relation to other objects we'll get the top, left, width, height of some anchor object and then calculate the picture coordinates in relation to that anchor.
The standard code we use for putting a graphic on the screen is something like this:LOGOPIC PICT NWK_RIGHT FORM "1300" ;Right edge of picture MOVE NO, PICNIF TRAP PIC_OBJ_ERROR IF OBJECT CREATE {form_window};LOGOPIC=60:1200:40:NWK_RIGHT,"LOGO.GIF": BORDER=1 TRAPCLR OBJECT IF (PICNIF = NO) ACTIVATE LOGOPIC ENDIF ...... obj_error MOVE "X",PICNIF RETURNAll of the items in the above example can be variables. That's illustrated on the rectangle specifications where we use NWK_RIGHT for the last specification.
Note the following:
- {form_window} is the name of the window that you're going to create the picture in.
- The rectangle specifications are for TOP:BOTTOM:LEFT:RIGHT. As a general rule these are in pixels. Don't get confused with other objects which use HIGHT and WIDTH rather than BOTTOM and RIGHT. The picture is sized relative to the entire screen. Other objects are sized relative to their own top left corner.
Picture sizes are somewhat controlled by the characteristics of the pictures itself. Generally things will scale just fine and always respect the aspect ratio. We've not been able to stretch pictures in either dimension (which is fine since that would be rarely needed.)
We usually use automatic scaling. We'll typically decide on a controlling dimension (horizontal or vertical) and set the opposite dimension to a high number. The picture will scale to the SMALLER dimension. Therefore, if we want to be sure that the picture fits left to right we set the TOP, LEFT and RIGHT coordinates to what we want then set the BOTTOM to some really large number. The effect is that the bottom of the picture floats up and down as the picture is scaled. The width remains constant.
- The picture name can be a literal, as shown, or a variable. Valid pictures are TIF, GIF, JPG, BMP, PCX and maybe others as Visual PL/B evolves.
You can also use a RESOURCE for your picture. If the "picture name" is a number it refers to the resource. This is very helpful for logos and screen features because you can add pictures to a PLFORM as a resource from within the designer. Once the picture is a resource you don't have to distribute the pictures separately.
- BORDER can be turned on and off at will. Note that for PRINTED pictures the border property doesn't apply. See the notes below on printing pictures.
- RESIZE can be turned on and off at will but it's somewhat strange. When a picture is created the resize says to use the autoscale or not. Once the picture is displayed you can turn scaling on and off without changing resize.
- AUTOZOOM defaults to OFF. When it is ON the following is possible:
- Double LEFT CLICK to do incremental zooms.
- Double RIGHT CLICK reduces.
- You can drag a box in the middle of a picture and double click on that to zoom the box. But you must double click after the box is drawn. It doesn't zoom automatically.
- AUTOZOOM must be on to make scroll bars.
- SCROLLBAR defaults to OFF.
- You can set vertical, horizontal, both or none.
- AUTOZOOM must be ON for scroll bars to do anything. They can show but seem dead if AUTOZOOM is off.
- In some cases changing the scroolbar property after the picture is created shows the bars but they don't work. Sometimes they do. You are best served by setting the scroolbar at the time the picture is created.
- The picture must be ZOOMED to some degree for the scroll bars to work. Unless a picture is zoomed the entire picture fits the frame so there's nothing to zoom.
- AUTOSCALE defaults to OFF. But it acts like it's on since the pictures automatically fill the defined screen box.
- You can set best fit, horizontal, vertical or none.
- none and best fit seem to be the same since the pictures. It might be necessary to specify this property in the create if you want it off.
- This is somewhat dependent on the picture itself. Some will autoscale and others won't.
PRINTING PICTURES
We always define pictures for the printed page in the program.
Pictures need to be defined only once so you can actually define a picture for the screen then use that same object for printing.
To define a picture ONLY for printing on the page we do something like this:LOGOPIC PICT MOVE NO, PICNIF TRAP PIC_OBJ_ERROR IF OBJECT CREATE LOGOPIC=60:1200:40:NWK06,"LOGO.GIF" TRAPCLR OBJECT IF (PICNIF = NO) PRTPAGE {printer_file};*PICTRECT=*OFF: *PICT=100:200:400:600:LOGOPIC ENDIF ...... obj_error MOVE "X",PICNIF RETURNAll of the items in the above example can be variables. That's illustrated on the rectangle specifications where we use NWK06 for the last specification.
Note the following:
- {printer_file} is, obviously, the name of the printer you're using.
- The rectangle specifications are for TOP:BOTTOM:LEFT:RIGHT. These numbers match the *UNITS value set for the printer. Our practice is to use *HIENGLISH for thousandths of an inch.
- The picture coordinates can be changed within the PRTPAGE instruction. What you do in the create doesn't really matter. We routinely create our picture objects at a fixed size then manipulate the actual printed size within the PRTPAGE instruction.
Printed picture scaling is similar to what you see on the screen. Check the picture size notes for more information.
- You can NOT change the name of the picture file in the PRTPAGE. You set the name in the create and it stays in effect.
- The picture name can be a literal, as shown, or a variable. Valid pictures are TIF, GIF, JPG, BMP and maybe others as Visual PL/B evolves. We use VuePrint from Hamrick Software for quickly converting pictures from one format to any other.
- BORDER doesn't do what you expect when printing pictures. Instead you use the *PICTRECT=*ON/*OFF specification in the PRTPAGE instruction.
Here's an interesting idea from the Sunbelt web board written by Paul Fuh 4/27/2004:
"It is well known that in order to change the image of a PICT object, we have to CREATE the object again. But there is another option. By doing it this way, all events and properties of the original PICT object are kept.
Happy coding. "pictobj pict //background picture// mypict pict //picture to show// main mainwindow $mouseup equ 14 pictures dim 20(4),("c:\image1.jpg"),("c:\image2.jpg"): ("c:\image3.jpg"),("c:\image4.jpg") //picture resources. Please replace with your pictures or resource numbers.// t form 2 set t create mypict=1:30:1:60,10020 call change activate mypict eventreg mypict,$mouseup,change loop eventwait repeat change create pictobj=1:1:1:1,pictures(t) clipset pictobj clipget mypict main.refresh incr t if (t>4) set t endif return
INDEX |
Send e-mail to MMCC. |