A READER ASKS: Last Row Isn’t A New One

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

APPENDIX 1: A Reader Asks

A READER ASKS
In my own solution I set up the relation between two tables without allowing the creation of records in the child table. Via a script I make a new record. The problem I encounter is that the script step 'Go to portal row - last' selects the last row, but I want it to select a new row where I can fill in the new data.

I hope you understand my problem and perhaps you can give me a clue to solve it.

-------
DWAYNE RESPONDS
You cannot create new records via a portal without having the “allow the creation of new records” option active in the relationship. So if you create a new record via a script, you will need to make sure the related record has the primary key data. So the script will likely ...

- put the parent records primary key field data into a variable
- go to the related table layout and create the new record
- set the foreign key data using the variable / commit the record
- go back to the parent table (possibly refresh the screen)
- go to the last portal row and the appropriate field for data entry
- enter in the new data

NOTE: If the relationship or the portal has sorting in place, the target row may not be the last portal. Chances are that it is either the first row or the last one. You will want to make sure and perform a number of tests.

Now if the problem persists, here are some possible culprits ...

- the key id from the parent table isn't coming over properly
- the fields in the portal are not from the same relationship as the portal
- the fields behavior setting does not allow you to click into the field
- the fields security settings do not allow editing
- the foreign key field cannot accept new data (calculation field)
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2009 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.

FILEMAKER: Same Portal - Different Tab

From Dwayne Wright PMP
Certified FileMaker Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

Please Note: If you are viewing this page in a news feeder, the images may get munged up a bit or other formatting of the posting may fail. For the best experience, please visit the journal directly by clicking (here).

Multiple portals that are very similar can be paginated by using FileMaker tab panels. You can have one portal that is sorted by date ascending in one tab panel and the same portal sorted by date descending in another tab panel. You can even create buttons that look like they are sorting the portal but are actually going to the tab panel that holds the corresponding portal. You can have a portal that shows the first 20 rows of a relationship in one tab and another tab panel that has the same portal but it starts at row 21.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2009 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.

FILEMAKER: Portal Sorting (but not really) Using Tabs

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 02: Portal Sorting

So I came across a client database that had a rather odd way of sorting a portal. The portal was located in a products table and was designed to show sales history. The columns in the portal were order id, date, company, quantity and order status. The portal had buttons to sort the row by date, company and qty. The customer wanted to add the ability to sort by order status.

The default sort for the portal was by the sales order date and the company on the sales order. The buttons on the three sort options were all tied to Go To Object script steps. This was very odd to me and I needed to research this technique. The buttons themselves were broken down into ...

DATE COLUMN BUTTON
Let( $$date = Choose( $$date; 1; 0);
Choose( $$date; "Date"; "Date D")
)

COMPANY COLUMN BUTTON
Let( $$company = Choose( $$company; 1; 0);
Choose( $$company; "Company"; "Company D")
)

QTY COLUMN BUTTON
Let( $$qty = Choose( $$qty; 1; 0);
Choose( $$qty; "Total"; "Total D")
)

Looking at the sort fields themselves, nothing remarkable. The company field was a placebo calculation field that was equal to related company name on the sales order. The date field was a lookup field from the sales order. I didn't see any hidden tabs but I thought I'd investigate. Sure enough, the darn thing is a layered hidden tab configuration. The tab have the same portal but with a different default sort order and the sort buttons do not sort but simply go to the correct tab with the corresponding default sort order portal.

This required me to take a closer look at the calculations that drive the Go To Object and I'm certainly glad I did. What the developer is doing is doing is toggling between an ascending sort for the portal and a descending sort. I don't use the Let or Choose function that often and this is a marvelous way to use them. So I went ahead and deconstructed the tabs and add a couple tabs of my own for the status sort. One tab to hold the portal for the ascending sort and one for the descending sort.

Needed to add a placebo order status field in the sales order line item table. This is because the portal is linked to the sales order line items and the status is linked to the order itself. I added my own sort button for status and attached my revised version of the Go To Object step ...

Let( $$status = Choose( $$status; 1; 0);
Choose( $$status; "Status"; "Status D")
)

I then wired everything back up and it worked like a charm!
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2009 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html

FILEMAKER: Constant Relationship Portals And Tab Panels

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 09: Tricks and Techniques

This article is a piece of a larger collection of articles on a proof of concept file I'm doing with the 360Works email plug-in. I'll include some links below for the other articles. As I was building this part of the example file, I knew I'd be doing some portal work that some folks might not have seen before. So I thought I'd document it here in the FileMaker Portals Explored Blog. Here are the previous links ...

External Functions Registering Your Plug-in
A Friday Afternoon With The 360Works Email Plug-In

In my proof of concept file, I'm going to have a tab panels called "Emails By Account" and then have a sub-tab panel within it for the accounting, sales, support, management and information tech related emails. Within each of these tab panels will be a portal showing just those emails that account that have a status of unread.

So first we are going to create relationships that match with our possible account options listed above. So we will create some calculate global fields for the parent matching key fields for our dashboard. Then we will set up the relationships for each account, using the Anchor / Buoy design method.

Here you can see the primary match fields that I'll be using in the relationships.

Here you can see the anchor/buoy relationship graph design to allow me to setup a portal per account that is viewed via a tab panel.

Next we take our portal that we defined for the Emails (all) tab, copy it, paste it off to the side and shrink it just a little bit to fit into our Emails (by account) sub-tab. We also do not need the To Account field in the nested portal because those portals only show the emails for that account.

Here you can see the Emails All tab.

Here you can see the Emails By Account Tab, the nested tab panel within it, the chosen Accounting tab selected and the portal within it.

I decided that I would put a tooltip in place so you can see the to address on the email, just to be sure it is too the correct account.

Here you can see the portal is showing you that an email was sent to multiple addresses but was included in the tab for this account.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.

FILEMAKER: Don’t Forget You Can Start Your Portal At A Row Other The The First

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 01: The Basics

As you know, a portal is designed to give you a mini list view of records related to the current record you are browsing. You can add a vertical scroll bar to view an almost unlimited number of related records. In some cases, you might have a limited amount of horizontal data to show the user and in a case like this, you can setup dueling portals. For example, one portal can show you related records 1 through 18 and the second portal (using the same relationship and fields can show you records 19 through 36.

Here you can see the dialog box setup for the second portal row.

Here you can see the staff layout from my InBizness product and we are looking at the portals that show the media file records that are associated with that staff member record.

Now the FileMaker 9 feature of auto resizing can goof you up a little here. If you have portal auto resizing setup, your first portal will dynamically show you more than the 18 records when the window is expanded. So you will see duplicate records in the second portals and unfortunately, I don’t have a resolution for that.

If you have any ideas or comments, please feel free to send them my way and I’ll update this blog post accordingly!
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.