1 Script, 1 Print Dialog, Multiple Print Settings

[xmoose]

Is there a way, within one script, to have the Print Dialog box appear only once (so the user can choose which printer to print to), and yet to bounce back and forth between printing only the current record and printing all records being browsed? Given that I have to switch how many records to print, it appears to me that I can't do it without restoring print options, which negate's the user's original printer choice.

Let me spell out the script:

...Bunch of script steps...

GoToLayout (Table A)

Print Setup [Restore, no dialog]

Print [Restore] [color:orange](with dialog to allow user to choose printer - restore chooses "current record only")

...Bunch of script steps...

GoToLayout (Table B )

Print Setup [Restore, no dialog]

Print [Restore, no dialog] [color:orange](I want this to print "all records being browsed", but to respect the user's choice of printer above)

...Bunch of script steps...

GoToLayout (Table A)

Print Setup [Restore, no dialog]

Print [Restore, no dialog] [color:orange](restore chooses "current record only", but respects the user's choice of printer above)

...Bunch of script steps...

GoToLayout (Table B )

Print Setup [Restore, no dialog]

Print [Restore, no dialog] [color:orange](I want this to print "all records being browsed", but to respect the user's choice of printer above)

...Repeat Many Times...

It appears to me that my only two choices are to:

a) Print all of the single records from Table A first. Then print all of the records from Table B. The end user would only have to select his printer twice, but then he'd have to collate by hand.

Print as above but make the print dialog show between each and every print. While less work for the end user than my first option, most users would find this unacceptable.

Anyone have a good way to bounce back and forth between "current record only" and "all records being browsed" without wiping out the user's choice of printer?

Any help would be greatly appreciated. I'm so glad I found FMForums. I plan to return the help I get here. Thanks in advance!!!

[Ender]

I can't test it right now, but it appears your script as written should do what you need. As I recall, FM7&8 on OS X uses the last printer set within the print dialog (or whatever was the default when FileMaker opened.) Changing the Print options (without dialog) shouldn't reset the printer choice.

[xmoose]

What happens when I test (I'm actually working cross-platform, btw), is that all prints AFTER the first one (which the user selects manually) go to the printer that was selected while the script was being created - where I selected if the current or all should print.

So, when in the script (editing it), it's set for my personal office printer. However, in running the test, I select any other printer in the building. The first page goes where it is supposed to, and the rest print up in my office.

Perhaps it won't be an issue to those who don't have access to the printer in use during scriptwriting, but as my printer is networked...

If you do get time to test it out, it would be greatly appreciated!!!

Edited April 6, 2006 by Guest
clarification

[Ender]

I guess I don't use a multi-part Print[] steps like this, my Print[] steps are in a subscript. Hmm, try putting the first or subsequent Print[] steps in a subscript. Maybe there's some memory about the default printer in the script, like in prior versions.

[xmoose]

Thanks for the tip. I'll give it a try tomorrow (I only have one printer at home, so it's not a fair test here.)

I actually considered it for a few seconds earlier today, but it almost seemed like it would make it worse (the goal was to remember the user's first choice - going to a subscript should make that less likely, if anything.)

I wish the Print[] step didn't require you to choose a printer. "Last Used" would be a good option to have. But, they probably don't have control over that, using the system's print dialog.

I'll give it a whirl and let you know how it goes. Thanks!

[xmoose]

Update

Well, I tried to avoid the entire problem by wimping out and doing the multi-record parts as printable portals. The obvious downside being that I can only go up to 225 matching records (before I hit the 10-page limit on the layout (though I guess I can make another 10 pages to expand this if the need shows itself.)

Anywho - a new problem has now appeared. It seems FM Server 8.0v2 isn't doing searches for date ranges correctly! So, while the new solution works on my desktop, it's worthless on the server. (Which shows no matching records when I know that they are there.) I'm about to look around the forums to see if others have run into this problem. Worst-case, I guess I just loop "new requests" through the date range.

Just wanted to rant. I hope 8.0v3 fixes some bugs (as well as adds Universal code). :P

[Ender]

Finds on unstored calcs with Server 8v2 and clients prior to 8v2 no longer work. If this is your situation, then upgrade your clients or develop a workaround for those finds.

[xmoose]

No longer work on purpose? Or are broken?

The script is searching for either the start date or the end date (per user selection) of a workshop. The start date and end date are both calculated based on the min or max "session" (calendar event) associated with it (related to it).

Clients and server are all on 8.0v2, so it sounds like the hangup is on the server search end.

Here I was thinking it might just be the date range search broken, so I was going to attempt replacing the range search with a <= find and >= constrain or, failing that, looping multiple requests for each date. But, it sounds like that isn't going to help, as it would still be searching on the unstored calculation.

Are we expecting to see a fix, or is it meant to be this way?

I'm really sad now. I can't migrate my office to a new registration database if I can't run bills for the registrants. :P

[xmoose]

Further research (now that I know to look for problems related to searching calculations rather than looking for problems searching date ranges) shows that FileMaker expects to have the problem fixed in 8.0v3.

However, interestingly enough, they say the problem shouldn't be happening with the clients updated (as they are). And that the faulty result should be that all records are returned. In my case, no matching records are found.

Very interesting!!!

I'm thinking a daily maintenance routine that enters a stored and indexed "Start Date" and "End Date" based on the current calendar entries may be the way to go. As long as noone changes the calendar on the same day that that period is going to be billed, it should be fine. It's just kind of sloppy.

Ender, you have been a saint! Thank you so much for the patience and helpfulness you show both to me and to others in this forum. What a great place!!!