I have been trying to convert one of my league schedules to Pan X. The display is matrixes which contain line items for the Time, Court, and Opponent for each week. For Time, as an example, this is simply a text display object which displays “Time” + str(Info(“matrixbox”)), evaluated twice. This updates in Pan 6 as I scroll through the teams, but in Pan X, scrolling does not change the value. Other text boxes, not text display, do update. I am not certain whether this is a bug or I am doing something which is not supported.
I attempted to duplicate this, starting in Panorama 6, but I could not. First of all, there is no info("matrixbox") statement. I thought you might have meant info("matrixcell"), and that worked ok, but if I enabled the “evaluate twice” option it failed. Hmm, perhaps you have fields or variables with the names Time1, Time2, Time3? In any case, I don’t think your example is as simple as you are saying, perhaps you could supply additional detail, or perhaps even a sample file?
I don’t understand what you are trying to describe here. Is the Text Display object in the matrix frame, and displayed inside the matrix? Or is it outside the matrix and updates as you scroll.
By the way, in Panorama X an alternate in this case to using evaluate twice would be to use the fieldvalue( function (which used to be called grabdata(.) However, evaluate twice should work.
fieldvalue("Time"+info("matrixcell"))
Notice also that str( is no longer required in this situation, though you can use it if you want to.
Yes, the database is as you say, line items where the number is the week in the season. One of the problems is that to print the entire season, I have been using view-as-list forms, and they are painfully slow. In fact, so slow that since I have tried to get one of them to open, unsuccessfully, I might add, I think I have managed to save the database with that form trying to open, which has munged everything.
It is info(“matrixcell”) as you said.
I will send you the file. There is nothing private about them, and there are a lot of things which are not converting properly.
Bruce, I’ve got your database, and I still have some questions about it that I will probably get into later. However, I think I have gotten to the heart of the problems you are encountering. You are using matrix objects on the data tile in a View-As-List form. That is very clever, very cool – I applaud your ingenuity. I suspect you are the only Panorama user to ever do that, and I can see that it works very well in your application. Actually, I’m a bit surprised that works in Panorama 6, knowing how the code works internally, I would never have thought to try that myself! However, Panorama X isn’t going to support that. I’ll need to change the code so it doesn’t hang up when you try it, but it isn’t going to work correctly.
A top goal of Panorama X was to use native Cocoa code for all user interface elements, instead of “home-made” code like Panorama 6 used. However, it turns out that the way that Panorama 6 implemented matrixes required “home-made” code for UI elements, so the way matrixes are implemented is actually quite different in Panorama X vs. Panorama 6 so that native Cocoa code can be accommodated. For most applications this makes no difference and actually has a lot of advantages, but there are specialized cases that simply cannot be done, and this is one of them. I know this is disappointing, but I have tried from the start (several years ago) to be clear that Panorama X was never going to be able to exactly duplicate every single capability of previous versions of Panorama. There was a discussion about this on the QNA list around 2010 or 11, and I was encouraged to go ahead even though it would mean some advanced databases would need significant rework. Of course I can’t remember what your position was in that discussion. In any case, I’ve never heard of anyone that has managed to pull off a 100% compatible rewrite of a major application – look at OS X vs. OS 9, Final Cut X vs. Final Cut 7, or Photos vs. iPhoto.
I’m not sure how I would re-do your application – one possibility might be to create an HTML table and use a web object. Since you are using matrixes with a fixed number of rows (in some cases 1 row), you could also use individual objects instead of using a matrix. If I was doing that I would probably automate the process by creating a program to create the objects.
Actually, the view-as-list forms are not important. I could rewrite those as individual pages. The Small Schedule, which should be the default view, is the one that is not working properly. As I scroll though the records, which are for each team, the team number in the heading scrolls, but not the time, opponent or court in the matrix in Pan X.
I was never quite certain what would work or not work each time I opened it. It seemed to change all the time.
I tried the fieldvalue( function, and it did not work, either. Then Pan X would not let the window close.
Ok, well what do you mean by “scroll thru the records”? There is no scroll bar on that form. Or are you saying that you scroll using the data sheet window? Your mention of scrolling left me confused, so I started looking at the other forms, thinking I was missing something.
I did notice last night that there is some sort of problem with the matrix objects on the Small Schedule form – I can’t select them. It was 2 am, so I gave up for the night, but I’ll come back to it. I am wondering if they were created with an early Panorama V beta and might be in a special format that Panorama X doesn’t currently understand. I know there was an intermediate form that was only used for a couple of months. More investigation needed.
There is also a long standing bug that sometimes causes text objects to fail to update. I don’t think that is what is happening here, because that is normally corrected by closing then re-opening the window, but I can’t rule it out yet.
I scroll through the records by using the up and down record buttons, or first and last record buttons. I do not keep the data sheet open, except when I initially set up the schedule, but moving from record to record there should also change the matrix.
This database is designed for printing, mostly.
The problem was that Panorama X matrix objects did not support the little used Sync Up/Down option. I have fixed this, and your Small Schedule form now updates properly both with the up/down arrows and if you click on a row in the data sheet.
I also fixed another minor bug I noticed related to importing matrixes from Panorama 6, but I don’t think that was affecting you.
The next thing you are going to run into is that matrix objects currently don’t print at all.
This is on my to-do list, and I’ll see if I can get to it sooner rather than later.
Well, I’ve got some egg on my face now, but in kind of a good way. After my big speech a couple about how some “classic” features aren’t going to ever work in Panorama X, it turns out that the specific feature I was talking about, matrix objects in a View-As-List form, is something I was able to get working fairly quickly. Here is Bruce’s clever form, with a view-as-list data tile that contains not one, but two matrix objects.
I also got printing of matrix objects working.
I am planning to fix a few more bugs and then release a new version in the next few days.
The odd thing is that I never thought of this as anything particularly clever. Maybe I need to learn how to think about matrixes as others do!
For those of you who might be confused, the dates on the header across the top are one matrix, and the rows of boxes underneath them are another. Both are 17 boxes wide and one box tall.
That particular view is a miniature schedule that I use as a reference. It prints out too small for us old bocce players to read. The one that I print for league use is printed on four sheets of paper, half of the teams on each vertical sheet, and half of the season on each horizontal sheet. That takes two forms, one for each half of the season, each printing pages until it runs out of teams. If there were more teams, it could print more pages, and if the season were longer, I would need additional forms for more weeks across the pages.
Of course, the scrolling feature would be handy for a “week at a glance” calendar. SMTWTFS on the header, and the dates would scroll. Using them as a button could bring up each day’s appointments, if you want to get really clever.