In Panorama X, any form object can contain arbitrary programming code. For most objects, this code is run when you click on the object. This example shows how to create and try out a push button in 15 seconds.

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.

Multi Line Code

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
if starPoints="" return endif
changeobject info("clickedobjectid"),"$StarCorners",starPoints

Self-Contained Code

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.

Using External Code

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).

Getting Information About the Clicked Object

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).

Setting and Getting the Object Name

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
    do the other thing

Note: You can also get the object name using: objectinfo("name",info("clickedobjectid"))

Trigger Value

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.Calculate Tax
Button.Show Chart

Note: You can also get the button name with this formula.


Deferred Display of Text Editor Object code

When the code triggered from a Text Editor Object is running, Panorama automatically defers display of any database changes until the code is completely finished. Normally you won’t even notice this, but to learn more, see the showlater statement.


10.0NewNew in this version.