I have an equipment database that uses a view-as-list form; every record has the Account number of its owner and the equipment’s serial number. The usual way to use this database is to push a button on a customer’s record in the customer database which selects all the equipment associated with that customer’s account number, and displays same in the Equipment form. The form also contains a Header tile that shows the Account number of the currently displayed record, and the Company name associated with that Account using a lookup( into the customer database. This worked flawlessly and quickly in Pan 6; it’s working almost correctly in Pan X (but not at all quickly) with one exception: the Header tile does not update. It still shows the Account number and Company Name of whatever it had before. If I go to Graphics mode and then back to Data mode it updates correctly, but I have not found any other way to make this happen. I wondered if putting a showvariables command at the end of the procedure that selects and displays this information would force the issue, but the key value, Account number, is a field, not a variable, and its value should be coming straight from the record that is current (the Account number does display correctly in the data lines). I’m stumped.
Try using the showfields statement. Here is a quote from the Help file:
“This statement tells Panorama to redisplay specified fields in the current record in every open window of the current database.”
Nice idea Gary, no joy. The help file suggests that this would only be necessary if you had been working in a noshow condition, which I’m not. And as I mentioned, the data lines on the form all show all the info they should, including the Account number; it’s only the Header tile that won’t update without help. OTOH, Pan X runs so s-l-o-w that maybe I just have to be patient for 10 minutes (not a solution).
I’m really, really, really surprised that this worked in Panorama 6. But since it did, I have filed a bug report for this:
It worked great from day one. Why wouldn’t you expect it to work in Pan 6?
I know for sure that you couldn’t put a Text Editor or Data Cell in the header. In general there have always been a lot of restrictions and caveats in regard to View-As-List forms.
You could have a form that has a text list on one side with a customer list, and the equipment list on the right for the customer selected (showing data in a second data file). I created a simple example showing this. See attached screen shot. I don’t know if this can be done in Pan 6 (I didn’t know how) but it’s fairly easy in PanX once you learn how to set up a text list. Based on my own experience, I would expect good performance with several thousand records, but I do not know how it would perform if you had substantially larger number of records. I have largely abandoned view-as-list forms in favor of text lists.
They are both Auto-Wrap Text objects, in Pan6-speak; in the converted PanX file they are TextDisplay objects - is there a better object type for this? Consistently, if I go to Graphics Mode, then back to Data, it force-updates these fields correctly, but simply moving to a different record makes no difference.
CooperT, that’s an interesting idea and I’ll give it some thought. I think I have too much data to make this practical for this purpose, but it could apply several other places.
No, Text Display objects are the way to go there. My comment wasn’t so much about the type of object, but rather that there have unfortunately always been a lot of limitations on the operation of View-As-List forms.
I have filed this update issue as a bug and hopefully it can be resolved at some point.
I’m not sure I understand what that means – you can do searches on Text Lists though Tom didn’t show that.
Like Tom, I only use Text Lists and Matrixes is new designs. They are much more flexible than View-As-List forms.
What I meant was a customer might have none or one or 100 items to go in that list, and 100 might be difficult to display well. What’s more relevant is that many of my views of Equipment are not merely what does this customer own, but maybe a list of all of one type, or some other subset that might not lend itself to that format. The standalone database handles that very well. But I need to look into it better and it’s not the most pressing thing on my plate right now.
Just for amusement, I added some fake data (25 customers and 1000 pieces of equipment), search gadgets for each, and a counter showing the number of rows found. Still a small database, but the searches by either gadget are practically instantaneous. If I understood your original post, this does what you were describing.
