Creating New Records in a Form

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.

Much thanks.

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.

A luta continua…

… and your hundred replications would still only show the contents of the active row in your data sheet.

Instead you need to put your 24 objects — I doubt that Text Editor objects are the best choice — in a Data tile on a View-As-List form.

Here are some references to the Pan X documentation:


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:

And here’s what I’ve achieved in Panorama so far:

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).

Does all this make sense to attempt in Panorama?

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.

Example 1:

Example 2:

Example 3:

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.