It's not an uncommon error. Go to Related Record will take you to *all* the related records for the current record. The checkbox option expands this to taking you to *all* the related records for *all* the records. Personally, I think GTRR is more trouble than it's worth. If you want to isolate a single related record, your best choice is to pass the unique primary ID of that related record as a parameter through the button. Then take that parameter (using Get ( ScriptParameter ) ) and do a find on your certificate layout to isolate the record. Also, your screenshots are a little confusing. Shouldn't the Certificate layout referenced in your "Email certificate" be based on Join Contacts Events table?
Do you have more than one tab control on the layout? There can be many "frontmost" tabs. FileMaker can't know which tab a user is actually looking at! A custom function like this is probably a better choice: https://www.briandunning.com/cf/694
You could make the portal as big as the longest invoice, put the text at the bottom and set the portal to "slide up". But you really should based the print layout on the line items table, not the invoice table so you're printing a bunch of records instead of one. Put your invoice-related information in the header or footer.
I won't do a demo, but I'll offer a couple more pieces. Create a table, Spec Index. Each record has a field for Job Type (or Job Type ID) and Specification. This will be a table you fill out once and rarely update. It will follow the same logic as your 41 hidden field calculation. Create another table, Job Specification Join. This table will have several records (one for each actual specification) for each Job. Write a script. When you create a Job and set it's "type", the script finds on the Spec Index for that type and finds the, say 5 Spec Index records for that Type, then goes to Job Spec Join and creates 5 records, setting the Job ID and the Specification. Now you'll have a Job record with 5 related specification records.
Snozzles, You should probably start a new thread for this. It looks like unusual behavior. Do you have other windows open? Do you have an OnModeExit script? You can get this dialog if portals are sorting, but that shouldn't happen in Find Mode. Are you sure you're in find mode when this dialog pops up? LaRetta, I must have missed the continuation of this thread somehow...I would certainly add that a script running in the script debugger does not 100% match the performance of that script without the debugger. Freeze Window is definitely one issue (it doesn't actually work in the debugger) but also Pause/Resume, and some other steps I've bumped into over the years. I'm not sure of a better test to see if local data is loaded when Freeze Window is followed by a layout switch, except using Wireshark or eyeballing the layout load speed for a table with big records. *I posted this as two replies, but the forum combined them...is that expected behavior?
First you need to grab the content of the web viewer. Use GetLayoutObjectAttribute() for that. You'll also want to check that the page has finished loading by ensuring the </html> tag is present. Then you'll want to find the position of both the onload=" string the the subsequent close brackets. There are several functions that you'll probably want to use: Let(), PatternCount(), Position(), and Middle().
I'd say eliminate the versions entirely. I don't see much utility between posting in FM 14 vs FM 13. If that's too drastic a change, what about reducing it to just file formats. FM 12+, 7-11, 3-6, pre-3?
Sounds like there are two issues...Allowing users to enter old contract IDs and not having gaps. You can solve the first by having three fields total. Auto-enter serial, OldID, and a calculation that displays the Old if present otherwise shows the Auto-enter. How do not have gaps is another issue completely. One possibility would be to create a few hundred records that represent the old contract with a blank serial ID, and then start the serial ID at the highest old contract number.
Why do this? There are two elements to what you're asking. One is storing different elements of a name. In general, I don't store middle names in a field in a table without a good reason. I sometimes don't even have a separate first and last name (rather than a single name field). Why nickname and alternate? Why all these different attributes? How will this help your users? The second issue is that you're also saying you want to store each name element in a separate record. Why would you do that??
I see what you mean, you don't have control over the new table structure. Some systems will do the migration for you. "If a 3-employee mom-and-pop store wants an inventory system, it takes just as much code as it does for a 5,000-employee manufacturer. " I'm going to have to disagree here.
Paying someone to review the work is probably worthwhile. I've done that for clients before. Both times my recommendation was to start over. With respect to migration...If the data is properly normalized then it should be no problem moving it into another system, no? And if it's not, you've got to migrate again anyway. I've done dozens of migrations, from Excel, from Access, from Lotus, and they're usually equal 50%-100% of the actual base development time of the alpha version. Even Joel has a caveat in his article about not starting over: "...when applied to large scale commercial applications."
Thank you. You can test to see if adding a pause between each send helps. I like to use a random pause, between .1 and 1 second long because I use Gmail and those guys are smart. They might catch on if I was using the same length pause each time.
If you'd like to pay back, this is the link to donate to this site:
The Modular FileMaker file you're referring to is script-based account management. It's not "layout-based". If you have a limited number of combinations of layouts/layout objects you want to hide, say a dozen, go ahead and create separate privilege sets for those, limiting layout access. Then for the objects, you can put a simple get ( AccountPrivilegeSetName) for the Hide calculation. Also, take a look at Extended Privileges. That may be a better way to conditionally hide objects than the Privilege Set Name. If you got hundreds of possible combinations (new user, PM abuser, accountant, etc etc etc etc) that would required hundreds of privilege sets...then you may want to look at another solution.