In Panorama 6 and earlier only push buttons could trigger a program, but in Panorama X it can be anything – including shapes, images, or even text (which can be very useful when combined with icon fonts, see Font Awesome Icons). Here is an example of a button created with a star object.
The ability to add code to any type of object greatly reduces the need for transparent buttons. In previous versions of Panorama putting a transparent button on top some other sort of object was a common technique. You can still do that, but it’s generally simpler to simply add the code to the visible object.
The code in an object isn’t limited to a single line – you can include a complete program right inside the object, like this:
If you’re wondering what this code does, it actually pops up a menu that changes the number of points on the star. Probably not something you’ll want to do a lot in a database, but it provides a good demonstration of the ability to include a complete, self-contained, program in an object.
Some of the techniques used in this example code will be discussed below. If you’d like to try this example yourself, here’s the code so you can copy it.
local starPoints starPoints=str(objectinfo("$StarCorners",info("clickedobjectid"))) popupclick commatocr("5,6,7,8,9,10,11,12,15,20"),starPoints,starPoints if starPoints="" return endif changeobject info("clickedobjectid"),"$StarCorners",starPoints
In the examples covered so far, the object and its code have been completely self-contained. Because of this, you can even copy the object to a form in another database and it will work right out of the box, even if the original database is closed. This is quite different than older versions of Panorama (6 and earlier) where any code associated with an object was external, so you had to be sure to also copy the separate procedure when you copied the object.
The code in an object doesn’t have to be self-contained. It can use the call, callwithin, or farcall statements to call a standard procedure. If the program is complex, it’s a lot easier to work with it in a separate procedure window instead of inside the form object. Here is the same pop-up menu example as above, but with the code moved into a separate procedure named pickStarPoints.
With the code in a separate procedure, it’s easier to make changes on-the-fly since you don’t have to go into Graphics Mode to make each change.
You don’t have to pick just one technique. You can make some objects self contained, and others that call external code. The code is the same either way, and you can even switch an object from one to the other (in fact that is what I did for the examples above).
When the code in an object is triggered, there are several info( functions that the code can use to find out about the object that was clicked, including info(“clickedobjectid”), info(“trigger”), info(“clickedobjectname”) and info(“buttonrectangle”).
The info(“clickedobjectid”) function is the most powerful and flexible of these functions; it returns the object ID of the clicked object. With this ID, you can use the objectinfo( function to get any information you want about the clicked object. Here are some of the properties you can find out about the clicked object.
objectinfo("title",info("clickedobjectid")) ☞ Button Title objectinfo("name",info("clickedobjectid")) ☞ Name of Object objectinfo("rectangle",info("clickedobjectid")) ☞ Object Coordinates
To see a list of all of an objects properties that can be accessed, open the Form Object Blueprint. Different types of objects have different properties, and new properties may be added in new versions of Panorama, but the blueprint will always list all of them.
Using the info(“clickedobjectid”) function allows several objects to share the same code. Here is a revision of the previous example, but with four stars instead of one. All four of them call the same pickStarPoints procedure.
Since the procedure uses the info(“clickedobjectid”) function to find out what star has been clicked, all four stars work correctly and independently even though they share the same code.
Important: The object ID is not a fixed number, it may change whenever the form is edited. So don’t check to see if an object ID is a fixed number.
if info("clickedobjectedid")=12 <-- DON'T DO THIS!!!
But you can use the ID number to uniquely identify the object right now, it will remain valid for the duration of the procedure (unless the procedure deletes objects or changes the layering of objects).
You can assign each object a name, and then find out that name when the object is clicked.
If you do use a name, it is completely up to you. You can even have two or more objects with the same name, if you want. Unlike the object ID, the name is permanent unless you change it, so it’s ok to have code something like:
if info("clickedobjectname") = "this" do this elseif info("clickedobjectname") = "that" do that else do the other thing endif
Note: You can also get the object name using:
Use the info(“trigger”) function to get the trigger value. If the procedure was triggered by a button, the function will return the word
Button followed by a period and then the name of the button, for example:
Button.Save Button.Calculate Tax Button.Show Chart
Note: You can also get the button name with this formula.
|10.0||New||New in this version.|