Objectinfo( issues

Converting a procedure that worked fine in 6 and is giving me fits in X. I have a little collection of 6 buttons, each of which is designed to take you to a particular record in a customer database. Each user can customize these for his own needs. Each button has a “title” that is the account number (key value) of the desired record, and an overlaid Text object that contains the company name associated with the record, so the user knows what he is pushing. Each Push Button Superobject (in 6) has “Hide Title” checked, so that the company name serves as the visible “title” on the button rather than its own object title, but when clicking it the objectinfo( of that button contains the invisible title to use to select the right record. To set up a button initially (or modify one that was already set up) the user goes to the record of the desired company, then Command-clicks the button he wants to associate it with, and Voila the button now is set up with all of those characteristics. I had a lot of help from either David or Gary, can’t remember, in setting up objectinfo( parameters, and it works very nicely. I haven’t tried the “write” part of the code since I can’t get the “read” stuff going, but the buttons are already set up with proper titles and names from the transition from 6.

In X it isn’t working at all, and stepping through it is fraught with the same peril that stepping can invoke (another thread). But I have determined where it first fails, which makes the rest of it fail. Each button has the object name “UsrBtn” with a sequential digit appended to the end (e.g. “UsrBtn3”) which is retrieved into the “indx” value.

local MyBtnLoc, indx, ThisBtn, MyAcct
MyBtnLoc = xytoxy(info("buttonrectangle"),"S","F")
Selectobjects objectinfo("rectangle")=MyBtnLoc

The failure point is the ThisBtn= step; it retrieves “” as the name, and thus 0 for the indx. Consequently, the MyAcct= line doesn’t even execute (this is where if I Step, the highlight jumps back to the first line of the procedure) and there is no error message of any kind.

I’m wondering if the “buttonrectangle” step is doing anything, I don’t know how to evaluate it.

I’m unclear whether I have the right argument value for the last line; my Pan 6 code uses “#BUTTON_TITLE” which I gather isn’t supported in X; I have used “title” as the likely successor, but of course neither does anything at this point. Since X doesn’t have a “Hide Title” option for Push Button Options, I have checked “Rich Text” and set the title color to white, works fine.

If I’m understanding you correctly, in Panorama X your procedure can be rewritten in two lines:

local MyAcct
MyAcct = objectinfo("title",info("clickedobjectid"))

This code was taken verbatim from this help page.

How would you know to look for that? This exact topic was covered in the classes, you can find it in the 290 Form Programming PDF file starting on page 102.


Of course I’m also going to strongly push the video, this is an area where Panorama X has made huge changes, but also makes things much simpler and more powerful once you learn it, as you can see from this example.

Well. “Clickedobjectid” sure takes the place of a lot of messing around! Yes, that works, except that since I’m trying to “hide” the titles with some fancy RichText stuff, I get my color:... stuff along with it as the title, but that’s easy enough to deal with.

“How would you know to look for that?” I didn’t take the classes, and I have no idea what PDF file you are talking about - where are they? Videos present problems for me, my job is to answer the phone when it rings and trying to concentrate on a video when I might be interrupted at any moment is next to impossible. It’s hard enough finding opportunities to work with programming in this environment. Written docs are going to work much better for me.

While I have your attention, the part of my code that modifies a button may not work. This is the key line from Pan 6:

changeobjects "#BUTTON TITLE", str(«Acct.#»)

which assigns the string value of the current Account to the title of the chosen button. Will this still work? Is there a better way? I realize I’ll need to append the "color:... stuff to the front of the title to maintain invisibility.

A few weeks ago I posted all of the slides from the classes for free. I wrote a post about doing that but I suspect that almost no one noticed it – I don’t think there was any response from anyone. Here is the page with all of the links.


This is the key line

No, that won’t work. It needs to be

changeobjects "Title",str(«Acct.#»)

If you ever have a question about how to modify a form object attribute, just make an object of the type in question, then right click on it and choose “Blueprint”. In fact, you can just copy and paste attributes out of this dialog.

Also, I’ll bet you might want to change the code to use changeobject instead of changeobjects, using the objectid you got from info(“clickedobjectid”).

Written docs are going to work much better for me

Well, written docs for all of these commands and functions are already available. You may want to invest some time in systematically pouring over these. The video class helps tie things together, I think it would ultimately save you time, even if you had to watch on evenings or weekends, but there are already around 3,000 pages of reference documentation.

I think I can answer that last question, it should be “title”, etc. as long as I have first selectobject-ed it. But I now have a bigger issue.

I have been testing this without the text overlays on the buttons that contain the company names for the assigned buttons just to keep things simple, but now I’m putting them in place. In Pan 6 I used simple text objects for this, which always act transparent to a click. Now they are TextDisplayObjects, and the click does not reach the button below it. If I assign my procedure to the text overlay so that it will cause the procedure to execute, it fails because my button is not the “clickedobject”, my text label is. It is vital that I have both the internally relevant lookup info (Acct Number) as well as the user-friendly info (company name) associated with the button. Is there another type of text object that would let me do this, or another way to approach it?

All objects are clickable in Panorama X. I don’t think there is anyway to make your scheme work.

I’m not sure I understand what you are trying to do. Is the account number hidden by the text object that contains the company name? If that is the case, I would probably set the button title to the company name, and put the account number in the object name, or the object tag. Then you’ll only need one object, which would be cleaner anyway.

I’m going to explore this, I think I started down the path I’m on when many of these abilities didn’t exist. But I’m lost when you say “object tag.” If there is in fact a third parameter (in addition to name and title) for each of these objects I think it will be a snap.

In graphics mode right-click the object and open the object’s Blueprint. You will see one of the options is “Tags” and you can enter a value next to that and click the Update Form button.

Adding to Gary’s comments, you can also read the tag value with objectinfo( and set it with changeobject or changeobjects.

That’s the missing link, thank you. Because of the way I need to keep it updated, I need an identifier independent of the title and name. I’ll see if I can break it, and get back to you.

I thought I knew what I was doing, but I’ve hit a snag. My original code went like this:

local ThisBtn, MyAcct
ThisBtn = objectinfo("Tags",info("clickedobjectid"))
MyAcct = objectinfo("name",info("clickedobjectid"))

and both items returned the correct value. But it was very slow to execute, and I thought maybe the repeated references to “clickedobjectid” was the culprit. So I made this change:

ThisBtn = objectinfo("Tags",info("clickedobjectid"))
selectobjects objectinfo("Tags") = ThisBtn
    MyAcct = objectinfo("Name")

now MyAcct returns blank. Easy enough to go back to my previous code, but I must be misunderstanding something that is causing this not to work. On the subject of slow execution, will this always be an artifact of retrieving object info? Should my change (if it worked) make it perform better? Finally, do you expect performance to be improved through optimization that has not yet been performed? Pan 6 did this right away.

Your original code was fine. When the button is clicked, Panorama caches the value for info(“clickedobjectid”). So that function is pretty much instantaneous. It’s probably faster than accessing a variable.

Your second example is definitely going to be slower – selectobjects has to scan all the objects.

You say that the original code is slow to execute – there must be more to the story. Clearly there must be more to the code than what you have presented, since the code you have given us doesn’t actually do anything. So I can’t really comment on the slowness – except to say that I have code that does a bunch of accesses of info(“clickedobjectid”) and runs instantaneously. In fact, I wrote an example for the documentation last night. So whatever the performance problem is, I think it is in some other part of your code.

By the way, there is an info("clickedobjectname") function. But it should be pretty much the same speed as what you have done above.

do you expect performance to be improved through optimization that has not yet been performed?

That is possible. But as I said, I don’t think that is the story here.

If I’m understanding your needs correctly I’m wondering why you don’t have the clicked button itself set the variables directly in the Procedure Panel code for each button. You could set the variables and then call the other procedure. This would all happen whenever the button was clicked. Simple code like:

Call myProcedure

You would substitute for the values you need to use to assign the variables and the procedure name to be called. You would set each button code to the values you need for that individual button click. Or am I missing something?

Also you can do a call with parameters, like this

call myProcedure,"tag","name"

then grab the parameters within the procedure. I’ve done that a lot.

Panorama X gives you so many more options than Panorama 6, where all you could do was specify a procedure name.

I have so far left out the part of my procedure that might explain why I am doing it this way. When I have the inevitable difficulties with that I will be back with more issues. This is a set of 6 buttons (I’m expanding it to 10) that bypass any need to search for a particular customer, the most common customers have their own button, press it and you go straight to their account. Each user is able to set up his buttons the way he wants them, which is done by CMD-clicking the button he wants to assign to the account that is currently selected. I maintain the setups for each user in his own record in a User Preferences database. This supports the fact that when I make changes to this particular database and distribute it to my users, my own setups, if I did it the way you suggest, would supersede whatever each user had set up for himself, and he would have to reprogram his own buttons again. Instead, the .Initialize procedure reads that user’s preference record and sets his buttons up automatically no matter how I have my own set up. This has worked flawlessly in Pan 6, and I’m just trying to make the same things happen in X. X allows some much more streamlined coding for this, as we have seen, but it’s not without its issues, as we have seen.

You might be interested in the results of a search in the Help for preferencevalue.

This eliminates the need for a User Preference database – Panorama X can access the built in OS X preference system. It’s a lot easier to use than fiddling with a secret database.

I think you could just assign the preference name as the object name, and the code would practically write itself.

I’m hesitant to mention it, but in Panorama X even the code in a button is itself programmable. In other words, your program can change the code in a button on the fly. For that matter, you can create new buttons on the fly (the Find/Select dialog does this when you press the + button, for example). I don’t think you need that for your application, but just thought I’d point that out.

Thats very interesting and I’ll take a good look at it. I don’t think this method will address a situation that has actually come up a few times - a user has to use another Pan user’s computer to work with these databases, and as presently configured all he would have to do is tell Panorama he is who he is, and right away these buttons are set to use his preferences. The OSX preferences would be tied to the computer he is using, not how he set up Panorama. This temporary user would not be logging into the “foreign” computer as himself, but as the owner of the computer. Which raises the question: when OSX stores Pan preferences like this, are they maintained separately for whichever account might have logged in? Which means if the “temporary” user has an account on that computer, that he could log in as himself and retrieve his specific preferences and not the ones set up by the regular owner of the computer?

Yes, the preferences are stored for each account.

if the “temporary” user has an account on that computer, that he could log in as himself and retrieve his specific preferences and not the ones set up by the regular owner of the computer?

Correct. It’s not so much “retrieve”, the preferences would just be there when he or she logged in.

I don’t think you are both using the same definition of “account.” I think Scott is talking about his account with Provue, rather than his account on the local computer. I think what he is asking would require that his preferences be stored on a Provue server.

Terminology tag underway. In my set of databases, every user has his own set of “settings”, i.e., his name and initials mainly, that will tag certain things. For example, there is a field for notes, and when the user presses the “Note” button it starts a new line at the top of the field with the date and this user’s initials so it is clear who wrote the note. There are other preferences about what sort order for certain things you prefer, what gets displayed by default, etc. The setup of the buttons I’ve been describing is another. These items are stored in the Preferences database, one record for each user, and I call each of these records an “account” in the present context. The login info for OSX is also an account, but in an entirely different way. For a temporary user to set up his own login on the other person’s computer just so he can get his own preferences is not likely. In any case, I have gotten this to work correctly and quickly, both reading and writing the preferences, so this is getting academic. info(“clickedobjectid”) turns out to be a very useful function. But the OSX preferences angle deserves more exploration.