I’m setting up a Form which has pretty much the same information as its Data Sheet, but with fields arranged differently in a custom layout. Everything looks good, and I’m ready to enter information, but when I hit “Add” in the menu bar while in Data Mode, a new record appears but replaces the original one. The result is that the Data Sheet contains the original record and the new record, but the Form only shows one record at a time.
Using Fields and Variables in the Construct menu I’ve entered a whole line of Text Editor objects in the Form to enter information. (This is after trying Text List and Matrix objects which were not taking me where I wanted to go.)
The idea is to have the Form display multiple records in alternating rows. I’d do this in the Data Sheet, but other than changing column sizes and rearranging fields, there’s not much in the way of layout changes available, unless I’m missing something.
Can anyone offer any enlightenment? I hope the solution doesn’t involve formulas or procedures; I’m still getting up to speed with the other aspects of Panorama and haven’t yet gained proficiency with buttons 5 and 6 in the Property Inspector.
Just an update: after coming up with several different workarounds, I tried simply duplicating the entire row of Text Editor objects (there are around 24 of them, one for each column in the Data Sheet) about one hundred times (the number of rows I figure I’ll need for a year’s worth of entries), then repositioning the rows so they align vertically to appear like a standard spreadsheet. Again, I’m doing this in a form instead of simply using the Data Sheet because there are graphic elements I want to incorporate that can’t be added to the Data Sheet.
What I’m experiencing is a massive slowdown in working with the form, caused, I suppose, by the necessity of either my computer or Panorama having to adjust, calculate, etc. several hundred objects. I don’t think this is going to work.
KJM, much thanks for pointing me to Report Tiles; this is an object that I haven’t yet looked at but will be useful for another project I’ll be tackling once I get this form and its information up and running. The problem for me in this particular scenario is that it takes records from the Data Sheet and plugs them into the form in a way that is viewable only—I can’t enter new records in the Report Tile.
I did find that all the Text Editor objects indeed showed the contents of the active row. To get around this, I set up an index field to relate each row in the form to a row in the Data Sheet. This calls for establishing a whole bunch of dummy records—in both the form and Data Sheet—that are ready to be populated as needed.
It’s all very inelegant, but it’s the best I’ve come up with—so far.
Pandew,
I have a small database illustrating the use of a text list and text editor objects in the same form. You can see a list of all the objects, or selected objects. The data for the active row appears in the text editor objects on the right. You can Add a record from here, but note, you have to refresh the text list before the changes made in the text editor object will appear in the list. I can send you the entire database if you like. Is this the sort of thing you were looking for?
Thanks CooperT for the database suggestion; it’s getting closer to what I’m trying to do.
Since the word:picture ratio is around 1000:1, I’ll post two screenshots. The first is what I’m trying to achieve—it’s a standard format accounting book for recording monthly activity:
In this work in progress, my current idea is to—somehow—use this form (and its database) as the front-facing view to enter records, just as one would do into an accounting ledger. The entries would be relationally connected to another database (or databases, if more than one proves to be needed as this project develops); this—or these— would, in effect, be the Data Sheet(s) where the records would “live”.
This is all a workaround to accommodate the basic principle in Panorama that repositioning records or adding graphics Data Sheet may not be made—which I understood and accepted when I bought the 12-month pricing plan this week.
I’m looking to move away from FileMaker, where I’ve been using a similar setup for years (it’s become too expensive and they’re moving more towards enterprise users, continually adding features that I don’t need).
That will certainly work Dewey but it looks a bit like a big Excel spreadsheet where it’s just too easy to enter data in the wrong row or column.
I have always used a form (displaying a single record at a time) for creating and accessing records with lots of fields. A couple of examples from a system I’m currently writing are below. You will see that you can have a host of options available for manipulating your data that aren’t possible in a data sheet. The Display a listing button moves the form to one side and places a Text List Object beside it, listing all or just the selected records in a data-sheet-type format so you have both methods of access to your data. If you click on a record in the text list form, that record is immediately selected in the first form, as shown in the third image.
The first example is also interesting in that it’s one of about a dozen forms in a database with some 50 fields but each form displays and uses only a relatively small subset of those fields.
Thanks, Michael, for the examples. Like that offered by CooperT—but much more extensively—it has given me clear avenues to develop in other aspects of my transition to Panorama.
You’re 100 percent correct that this is like a big Excel spreadsheet—that’s exactly what it is (although I’m currently doing it in Apple’s Numbers after FileMaker 12 started becoming wonky several years back). The document is basically a double-entry accounting ledger. Although I’ve built in controls to prevent erroneous data entry in incorrect columns, I still have to respect the basic form since it will be handed off to accountants who will have to enter the details into spreadsheet programs adhering to the classic format.
The reason why I used FileMaker—and am looking to make Panorama work—is for the relational aspect which Excel (or Numbers) lacks. For example, under Receipts, when a payment is received and entered into the database, it will connect with the related record elsewhere which indicates that that account or client is fully paid up. (That other record is in turn related to the form which produced the original invoice.)
In any event, once again much thanks for the examples which I’ll be studying to get a better understanding of Panorama’s potential.
I created a view-as-a-list form in a database that has13 fields. Twelve of those fields appear in a data tile, which lies below a header tile that contains Text Display and Push Button objects. Three of the Text Display objects contain variables related to three fields that may change from record to record. Once I establish the data in these variables, the fields to which they relate will not change from record to new record. On occasion, however, I will want the data in these three variables to change for a new record. I have procedures that do that, which are activated by Push Buttons next to the respective Text Displays.
After making changes in any of the three variables, the respective Text Display will continue to show the old data. The Displays will not refresh with the new data until I enter the Graphics Mode and immediately return to the Data Mode. However, the new records will show the new data even though the Displays show the old variable data.
I know that the recommendation is not to use a view-as-a-list form to enter data. But I enjoy entering data this way because the Push Buttons in the header tile are quickly available, as is the other information in the Text Displays. And trying to program around the difficulties on this method is challenging and rewarding. It is just an annoyance not being able to see the changes in the variables, but all the other procedures work fine and new records are created correctly.
But I have not succeeded in finding a way to refresh the three Text Displays, short of toggling back and forth from Graphic Mode to Data Mode. I have tried a variety of procedural commands such as “showvariables”, “showfields”, “showpage”, “show”, and made a procedure using “graphicsmode” followed by “datamode”, but nothing works to refresh the Displays short of the toggling.
I did a little experimenting on a View-as-List form to see if I could force a variable in a Text Display Object to update after changing its value. I tried a brute force approach to close and then reopen the form and was surprised to see that visually the form never closed but went in and out of focus with the variable actually updating after a little latency. The simple code I used is:
Gary, I think your code assumes that there is some other window open in this database, and that that window is the next visible window.
If the View-as-List form is the only window open in the database, then the closewindow statement will close the entire database. In that case, of course the openform statement will fail.
If a window from some other database is the second database, that window will become the current window after the closewindow statement. Now a different database is current, and again the openform statement will fail.
I’m guessing you had only one database open with two windows, the View-As-List form window and your procedure. In that situation, your code would correctly close and open the form.
It could be possible to fix all these problems I’ve identified, but the code would get quite a bit more complicated. You would probably need to use makesecret, but only if there is only one window open in the database. Then you would also want to add a database parameter to the openform statement.
If you want to try another brute force approach, a possibility would be to create a blank form, then use goform to switch to the blank form and then back to the view-as-list form. I haven’t tried this, but it might work.
Of course my real recommendation is to use a Text List or Matrix. Then you can update variables outside the list or matrix to your heart’s desire.
And you are correct, also, Jim. There must be another window open for this to work. But keeping another window open, even if it is just a procedure window, is no trouble. I also use the Data Entry form, and switch to the Data Sheet when I want to see all the records in a list. But I enjoyed the challenge of the view-as-a-list form, which is now complete for me.
