FileMaker deals with printing by either manual user selections as per any application or by scripting.
When manually choosing printsetup and print options, FileMaker should choose the printer last used or the default set when opening the file until another selection is made.
When scripted, FileMaker will save printer settings current at the time of creating the script or when modifying the script step. If you don't want all these settings, you ensure the dialog(s) is(are) shown during the script so that a different printer can be selected on-the-fly.
I find myself wonder why you would need to be changing the default printer selection all the time. If the environment is that dynamic, surely an on-the-fly selection is the go. If you have a range of printers and settings, perhaps you should script them all and allow the user to select printer by button or custom dialog.
If I were working in your environments with Macs and wanted to check the current default settings of the printer for use in FileMaker, I would probably use Applescript.
Perhaps your solution to check out the WM_Settings is for your .net developers to set you up a web page that enquires of your WM_Settings and use it in a web viewer in FIleMaker. The data could be captured and interpreted and perhaps be used for a choosing between printer scripts.
I guess since you have ruled out plugins you wouldn't want to hear how much better a plugin solution could make your life, huh? If you change your mind, I can share how I do it in a medical practice with multiple printers AND a fax printer driver.
I ruled out plugins for years... fearing the problem with version compatibility of the early days.
These days I have no problems reaching for a plugin. There are some excellent plugins which add some real grunt to FIleMaker !!
Funny... I have a (medical) client at the moment who has a similar resistance to plugins.
Hi Lindsay and Ron,
I've used plugins in the past and one of our largest database solution uses one, but I get constant hassle with it and its not always easy to sort out with the plugin developers who work in different time zones. I do much prefer using native FileMaker as it usually just works and we tend to upgrade as soon as a new versoin comes out. Fortunately for me when I was developing on Macs I didn't encounter many issues I couldn't find work arounds for because of the vast community using that platform but when coming into a Windows and Enterprise environment is a different ball game alltogether.
I'm sure FileMaker engineers should be able to fix this issue, they're probably unaware of it - cretainly don't think printing records from FileMaker should merit having to buy a plugin - especially for 800 machines, adminstrating them would be a nightmare although I've never actually used the server side plugin...
Lindsay I do like your applescript idea, might try when I get a spare moment and see if I can achieve somthing similar with vbscript which we can maintain, however not sure of our users permissions and execution rights. I've got elevated permissions compared to my users, need to test test test.
Is this the right forum to post this as it doesn't seem FileMaker tech doesn't read these boards as I've had no responses from any of their representatives?