Scripting with Portals

[teknetia]

Hi Guys,

I have attached an image showing the interface that I want to use to add new dates to a related table (this is part of a larger layout of information from a different table).

I am having two problems at the moment.

1) When you try to click on the fields in the "Add New Date" area, they are not selectable at all, stopping you from entering data. At the moment they point directly to their table (e.g. Dates::internal_id), should that be linked some other way to do this?

2) How do I learn about scripting the "Add New Date" button so that the details in the fields above are entered into the Dates table and then are displayed in the dates portal to the left?

Also, how do I set a script on the portal lines that will cause all their details to show up either in the form to the right or in a separate window with in a form for editing notes and so on? I have seen this done in some demo files and will keep on trying to deconstruct those, but I have not really been able to understand them so far.

Thanks very much

~Chris

[Ocean West]

Chris,

I have to give you props to a nicely designed layout, something seldom seen.

To your request you wish to add records to the portal on the left by clicking the + Add New Date button. Then requesting the user to enter the data? Or do you wish to allow the user to enter the data first then press the button?

The problem why they are not selectable or editable is because your relationship is not set up to allow for creation of related records. By turning that on in your graph you can create one related record however the fields will always only show one record (depending on your sort order of the relationship)

How do you intend the user to EDIT the data in the portal? By selecting it and having the data on the right populated?

You may need to use some globals for data entry. And script the creation of the related data.

There are several ways to achieve your goals, if you walk me thru your desired user interaction we can zone in on the more efficient approach.

[teknetia]

Hey,

Thanks for that. I decided that if I was going to be staring at my database all day then both myself and my staff will have anice interface!!

The desired user interaction is as so:

1) Entering new data (new records) into the dates table

- The user will enter the data into the fields on the right

- Click on 'Add New Date' which will then add the date to the Dates table and show it up in the Portal.

2) Editing existing records

- The user will click on the date in the portal (either the entire record or an edit icon under the delete icon - not seen in this because there are no records)

- The data will show up in the Add New Dates area and be editable.

- If possible, I would like the Add New Date button to change to an Edit Record button, simply for UI simplicity

- The date would be updated after button press

Cheers!

[Ocean West]

Ok i understand. I have attached a sample file that I stripped out of one of my projects. The concept will work for you however the content that this deals with is addresses.

Instead of allocating screen real estate to the fields on the right which mostly are empty except when adding data. I am using a set of tabs panels, thus to make your data entry focused on the task at hand.

The default panel is a portal of related records.

ADDING RELATED RECORD

When the user wishes to ADD a record they hit the + button. This via a script will navigate to the target table (capturing the needed ID fields) create a new record and populate the foreign keys. Grabbing the ID of the newly created related record. Returning you to your layout and then targeting the "EDIT" tab panel. Then setting a global field to relate to your newly created record. This is where you add the data.

EDITING RELATED RECORDS

When you wish to EDIT or see more detail from the portal clicking on the portal row sets the global field to the ID of the related records then targets the EDIT tab panel for you to review or edit the contents.

DELETING RELATED RECORDS

By clicking on the minus button in the portal will delete the related record you could employ some more validation or requirements for allowing deletion.

This technique will allow you to in effect HIDE the tab panels by assigning them to ZERO line weight and a fixed margin of zero. (Feature of FMP9) You need a script to target the desired tab panel.

This technique uses my concept of putting small graphics in global variables. You could substitute some other method to achieve the same goals.

related.fp7.zip

Edited December 30, 2007 by Guest
added file

[teknetia]

Hey,

I've been taking a look at this and I can't seem to follow it. when I enter layout mode, there is no add button, so how do I work this out?

Sorry, I'm a bit lost with this one.

Cheers

Chris

[David Jondreau]

....

Edited January 19, 2008 by Guest
ignore me

[Lee Smith]

What are you Trying to Add in Layout Mode?

[teknetia]

I have a set of fields that relate to a different table than the one the layout was made for (i.e. the dates fields are shown on the courses page).

I want it so that you can enter details into that set of fields, hit ADD and it adds it to the DATES table (which then makes it show up in the portal of the courses table).

So I need to work out how to make it all work.

Cheers

Chris

[Lee Smith]

Okay, if I understanding you correctly now, you are not wanting to modify the layout by adding a new field, but are instead wanting to have a date show from a related record.

You can change your Relationship to allow the creation of the related record in your current file, is that what you are needing?

Lee

[teknetia]

I figure the easiest way to explain is with a screen cap of the layout that I'm working with so I have attached one (please excuse the crude black boxes, but it was easier than blurring/etc, although in retrospect I could have just created a blank record)

This is pretty typical of the situation that I want to deal with throughout the database. In this example, I am looking at the contact manager. The CONTACTS table is the main table here, however the data in the 'Activity History' tab at the bottom is all drawn form a related database called HISTORY.

I am not 100% sure why the first record is showing up in the 'Add/Edit Activity' area, it just appeared there when I added the fields. However it is useful to explain the point.

As you can see, there is a list of records in the portal to the left. When a portal record is clicked on, I want the information to show up in the fields to the right. That way it can be edited and then saved. I also want the user to be able to begin typing in these fields and when they hit 'Add New Activity' it will add the new record to the HISTORY table, showing it in the portal and recording it.

The delete option is the little red x next to the portal row. This one is working, just not the rest.

Cheers!

Chris

P.S. Does anyone know how to make a text box transparent? I can't seem to remove the white that I added accidentally, not even by creating new text areas.

[Fenton]

Stephen's file may be a little over your head. But it solves the problem in probably the best way. Which is that it reuses the space where the many rows appear, switching to a single-record view of the clicked-on row. It is much the same as your layout, except it reuses the space, rather than having to have the "1-record form view" off to the side. There is another side effect of having the record on the side, in that it will always have the last one you clicked on; unless you script reseting it to the 1st every time you come to the layout. Of course, his could leave a record in form view, unless you reset it to the portal view whenever you come to the layout (which he likely does).

His uses 2 tabs to hold the 2 different views, so they can effectively occupy the same space. He then hides the tabs themselves by making them real small (0 width in FileMaker 9) and hiding them under a graphic.

All methods to view and edit a single related record on the same layout as the portal, ie., the parent layout, rely on the same principle. Set a unique ID of the child into a local field in the parent table. Then use that to target the related table via a relationship. It's only going to match 1 record. So you don't need a "portal", you can just put the related fields on the layout.

To add a related record, you click an Add button (his is in the portal, in the last empty row,* serving double-time as a delete button). But you could go simpler and put the "Add" button above the portal. It wouldn't be either as good or cute however :-]

*The relationship has [x] Allow creation of related records. This makes for the blank row, and is the reason for the dual add/delete (+/-) button. If yours is truly a "history", with old records which do not need to be viewed in the portal, then you could turn off [x] Allow creation, sort the portal by Date/Time (or Timestamp) descending, then put the Add button above the portal. Either way, different methods for different things.

To add a record, then edit it, both on the parent layout, you've got to go create it, in the child table, set its foreign ID field to the parent's ID, capture the child ID, return to the parent, and set it into the field to establish the 1-child-record view; same as you'd do when you click on a row.

You really should look over his file again. He made a copy of the tab object over to the side, so you can see how it is set up. And yeah, you're right, the assigning of the graphics to global variables is kind of over the top for a beginner; though interesting. As he said, it's from one of his files, and he's obviously put a lot of thought into how to populate these little icons. You could create a calculation to just produce the graphic globals. Or just put the Add button above the portal.

Edited January 20, 2008 by Guest

[teknetia]

Hi Fenton,

Sorry, I'm even more confused now. I have absolutely no idea how to follow his file or what you just said >_<

I am a complete beginner with filemaker, so his layouts are really making me confused. I do not understand how all the layouts work together to create a single layout, nor how exactly all the calls work. The reason I am using a separate add area is for simplicity to my users (more comfortable this way than with a changing layout). Also, I do want it to reset to empty, so I assume I need to write some kind of script for this to run when the layout is opened?

I'm sorry but I'm more confused after reading your article, although I'm pretty sure that it probably makes perfect sense to others here.

Cheers

Chris

[Lee Smith]

Where did you download the file from?

Lee