Jump to content

1 Script, 1 Print Dialog, Multiple Print Settings


This topic is 5643 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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.

:D 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!!!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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... :D

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

Edited by Guest
clarification
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. :P

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!!!

Link to comment
Share on other sites

This topic is 5643 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.