4 Replies Latest reply on Dec 5, 2011 5:27 AM by ajk

    Deafult Printers in Windows 7


      Hi all,


      Need some advice from the FileMaker tech folk please.We've got a a Windows 7 environment all running FileMaker Pro 11v3 and we have no end of support calls regarding issues with printing. Our main problem is FileMaker Pro doesn't recognise when the printer has changed default and uses what I think from my brief testing the printer that was default at the time of launching. We're in an enterprise environment and this causes our users and tech staff alot of ear ache. Is there anyway FileMaker can fix this with a patch or in their upcoming version 12 or whatever it is. We just want FileMaker Pro to recognise what printer is set on default, including the settings like tray etc and then RETAIN this information on the next print. If the default printer changes, we want FileMaker to recognise this and make changes within the program accordingly.


      Our Windows/.net developers have told us that FileMaker Pro needs to respond to the WM_Settings message within the Windows envrionment. This message states the variables within the client environment that have changed - including the printer setting.


      Im not interested in buying plugins to do this as I feel printing feature should be a standard and robust feature within FileMaker (Adobe, Microsoft seem to do it OK with their wealth of products) and if a small plugin developer can solve this, FileMakers engineers can too.

      Would love to hear your feedback, either by personal message or in the forums.

        • 1. Re: Deafult Printers in Windows 7

          Hi ajk,


          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.


          - Lyndsay

          • 2. Re: Deafult Printers in Windows 7

            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.


            Warmest regards,



            • 3. Re: Deafult Printers in Windows 7

              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.


              - Lyndsay

              • 4. Re: Deafult Printers in Windows 7

                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?