Text List query doesn't update

This is further developments of a Text List that I’ve been discussing recently. This is a Sales Tax report that I run every month for the previous month’s sales. I build a query string from user input about which month/year he wants the report for. The Text List is the main part of the report; I do some additional calculations with arraybuild statements, using the same query string MyQuery. The last 2 lines of my procedure are:

changeobject "TaxList","$TextListQueryFormula",MyQuery
openform "WA Tax Form"

This all works fine except that the $TextListQueryFormula is not updated, it contains whatever query text was in there before. So I get a report with header text indicating the month I asked for, and totals from the arraybuilds that correspond to the right month, but the data in the list is from the previous query. I have had to manually edit the query in the Text List Options pane to get what I want. I tried adding a line “showvariables MyQuery” at the end and even before it but it does nothing. “TaxList” is indeed the name of the Text List object. Would I get an error if my changeobject code referenced a non-existent object? What can I do to make this work? Other Text Lists I’ve made don’t have this problem, but maybe I’m leaving something out.

If the TaxList object is on the WA Tax Form then it probably can not be changed until that form is actually open. Try reversing the order of the two statements so that the changeobject is after the openform.

Gary’s answer is probably correct. Another approach would be to do without the query in the text list. Build an array, using your query, and have the list display the array.

Gary and Dave’s answers are both correct.

More generally, the changeobject statement always refers to objects in the current window. The only exception would be if you used the magicwindow or magicformwindow statements. Other than that you can’t change objects in any window except the current window, and you definitely can’t change objects in forms that aren’t currently open.

Also, the changeobject statement does NOT cause an error if the specified object doesn’t exist in the current window. In that case it simply does nothing. Looking at the code it would be pretty easy to add an error message if the object doesn’t exist, perhaps I should consider doing that.

Well, Gary and David’s advice didn’t actually work in my case, I’ve been leaving the form with the Text List open as I run the procedure and life is no different. However, your comment " the changeobject statement always refers to objects in the current window" provides a clue. My procedure runs in a procedure window separate from all of this. And as I think about it, my other Text Lists are populated by a procedure called within the form itself, and that most likely is the critical difference. I can migrate my user input and procedure code into the form itself and I’d expect it to work.

An error message indicating one has asked for something impossible would be helpful. I’m pretty sure I would have seen that error the way I have this set up.

Check out the magicwindow and magicformwindow statements. They allow you to do graphics work in an open form that is not the currently active form.

The “current window” is the window that is currently in front, at any given moment. Procedures run in whatever window is current at any given moment. That can change during the course of the procedure as windows are opened or closed or brought to the front, but it is rarely ever a procedure window.

To elaborate on that, it will never be a procedure window unless you go well out of your way to make that happen, either by using a window statement or the openprocedure statement. If you have a procedure window open and press the Run button, Panorama will first find the topmost data window in the database (either the data sheet or a form) and make that active, then run the code. If there is no data window open, Panorama will complain and refuse to run the code.

If you do purposely make a procedure window active in your code, most normal database related statements won’t work. You can’t sort, select, add records, etc. None of those operations are valid when a procedure window is frontmost. In fact there are only a few statements that you can use – setproceduretext, proceduresetselection, procedureinserttext, etc.