customDialogDictionary error

fairly frequently i get an error ‘Contents of variable [customDialogDictionary] have not been defined.’

when this happens, so far, i’ve just been able to run the procedure that caused the error again, and it works without an error.

any idea what’s happening here?

customDialogDictionary is a global variable that is set up by the CustomDialog statement. It can be used to customize the size and button names in the GetText, GetScrap and GetScrapOk dialogs. I’ve reviewed the code involved and it appears to me that the variable is always being defined before it is accessed, so you should never see that error. Has anyone else seen this error? Does the error seem to happen when you are using the GetText, GetScrap or GetScrapOk statements? At the moment, I am at a loss as to the possible cause of this.

I have assigned a BitBucket issue to this:

gettext has been involved every time.

i should also tell you that after the initial post on this topic, i discovered my hard drive was in the process of failing. this caused numerous anomalies. this error could be one of them. i’ve only had a new drive since late yesterday, but i haven’t gotten the error since.

Ok, keep us posted, and good luck with the new drive!

i’m still getting the error, despite a new drive and all new ram.
gettext is always involved.
simply running the proc again with no modification clears the error.

I was preparing to post a question about an error I am receiving, when I noted that samrutherford posted the exact same inquiry in Nov 2016 (“customDialogDictionary error”). With a gettext statement, the macro fails the first time, but runs successfully after that.

In his response, Jim mentioned a bucket list entry, and asked if anyone else has seen this problem. Now I have.

Is this still a bucket list item? Are we (forum users) able to access the bucket list to see what’s on it? Is there some sort of timeline or schedule to address the bucket list items?


Jim provided a link to it in his post above. Clicking on it would have shown you that the issue is still open. Once there, you can click on the issues link to see the index for all the issues.

I just tested this again, and the gettext statement works perfectly for me, both the first time and every time thereafter. It is nearly impossible to fix a problem that I cannot reproduce. On visual inspection the code appears correct.

I checked the records, and Sam Rutherford is one of the heaviest users of Panorama out there. So Sam, are you still having this problem?

With the help of an Apple engineer at WWDC, I did recently fix a frequently requested issue with the GetTextDialog – the fact that in recent versions of macOS, the text isn’t automatically highlighted when the dialog opens (so you have to click on it before typing). That fix will be in the next release.

No, there isn’t. It varies for every issue depending on how repeatable the problem is, how many users are affected, what the severity of the consequences are, and other factors. At the moment about 75% of all items that have ever been submitted have been resolved. That percentage is a bit lower than usual because I have been focusing on Panorama X Server rather than clearing items on the list. Some items on the list are suggestions, and some have not been confirmed, so the clearance rate is never going to be 100%. This is why almost no software companies make their bug list public.

By the way, the “bucket list” is really called an issue tracker. At the moment, the Panorama X issue tracker is hosted with a service called “BitBucket”, which is owned by Atlassian. Bitbucket is a competitor to GitHub, which you may have heard of (GitHub was purchased by Microsoft a while back).

Yes, Jim. I can certainly understand that. Maybe Sam can provide additional input.

Here is the window error I am getting. Does this help you at all? Running the macro (which has the gettext command) a second time works correctly. It makes no difference if I accept the default gettext value, or replace it with a different value. First time - NG. Second and succeeding times - OK.


Vic, I have an experiment to try (should you accept - I fell like Mission Impossible) that may help Jim with this problem. I can not test it myself since I have never had this problem surface personally. You can open the Open View… wizard from the View menu and then with the +Libraries option selected, type in Gettext. When you see it listed double click it and the GETTEXT procedure will open (the same one shown in the Error Wizard screen shot you included). In that procedure temporarily comment out the block of code I show below and replace it with the new code as also shown:


You can save the GETTEXT procedure at this point for further testing and you will, of course, be able go back and reset the original code at any time using the same method.

My thinking on this is that having the define statement doing the dictionary initializing might be what is occasionally upsetting the timing with the customDialogDictionary global variable. Just a thought but I have no way to check this myself since I never experience the problem at my end.

Hello Gary,

No. Made no difference. Here is the new error window. As you can see, your new code was successfully implemented.

As an aside, when I opened the View menu to see the GETTEXT procedure, one of the procedures listed there was

_Gary’s Additions1

Apparently I must have downloaded something from you in the past and included it in my library. I have absolutely no memory of having done that (not that that is so unusual these days!!)


Well, it was worth a shot. As for my GETTEXTSHEET statement, you must have downloaded my Gary’s Additions 1 file from the Panorama Database Exchange and run it. That would automatically install this special statement along with a few other items.