mleering

Hey all; I'm working with a client who has a multi-file .fmp12 solution. Every time she attempts to print from one specific file, it prints out in B&W, despite her selection of colour from the printer drivers. Printing from other .fmp12 files is fine, and printing from other applications is fine too though. I've gone through all of the Preferences and File Options, and couldn't find anything that fit the bill, so I went so far as creating a clone of that file, and resetting the print setup options... still to no avail. Has anyone else experienced anything similar? Got any suggestions on what else I could try? Also, when we first go into Print Setup's options, we get presented with this dialog box (see attached image). Obviously, we've tried unchecking the box to use Xerox's black and white conversion, but even that doesn't do the trick for us. Thanks in advance; Matt

Hey capsprojectos; I'm a little confused with what you're trying to accomplish here. If I've read into this properly, the end result you're looking for is to present the end-user with the information that matches various criteria that they can specify. If this is the case, then perhaps things can be simplified a bit. What I'm thinking is that maybe you could have the filter criteria on the same page as the actual data that they're going to view (ie a list view). If this is an option for you, then you can simply write a script (or various scripts) that will fire whenever the values in your filter fields (at the top of the list view) have their values saved/modified/whatever. The simple way to write a find script within FileMaker usually involves: Enter Find Mode Set Field { Set Field { It's in these steps where you actually set the field that you want to search on with the values that were specified in the user's filter criteria } Set Field { Perform Find Hopefully I've understood what you're trying to accomplish, and that this proves helpful to you.

Hi littleb3; it definitely sounds like something's awry. The trick to remember about this technique is that when FileMaker creates a value-list showing only the 2nd field, it will only add entries into your value-list that actually contain a value (other than NULL) in the 2nd field. The first thing that I would do (and perhaps you've already tried this), would be to create a value list that only uses the calculation that you wrote. Make sure that it's returning only the names (not IDs) of the people you want to see. If that's working, then the next step will be simple. Simply change your value list to use the regular ID field as the first field, and your calculation as the 2nd field (and of course, only display the 2nd field). I've attached an image that might tell a thousand words too. Hopefully this clears things up for you, but let me know either way! Warm Regards Matt

I'm working with a client right now who wants the ability to fax one of his reports from FileMaker to the corresponding contact in his database. The report may contain sensitive data that he fears might break the doctor/patient confidentiality agreement he has should he turn to a 3rd party email to fax service. Because of this fact, I've been searching for plugins for FileMaker that could allow for direct faxing via fax modem, and my results are turning up unfruitful. It seems as if Schubec used to have a plugin that has since been retired, and that MyFMButler has one that you can use... but only if you're willing to go through a mail to fax service. There are 3rd party standalone apps that would probably do the trick, but wouldn't receive the fax number from the database. Does anyone know of a good plugin... or workaround? PS --> client is on Windows 7 (32-bit), and is using FM Pro 11 Many Thanks In Advance Matt

No worries Ron; She's very helpful, so I certainly understand. If you named your global variable the same as I did ($$skipValidation), then you can use the exact validation calculation that I'm using. Case ( not $$skipValidation; not IsEmpty ( Self ); //else 1 ) *Self returns the current field that is being calculated It basically says: "If we're not skipping validation right now, then make sure that this field is not empty, otherwise... skip validation alltogether". Other considerations: set $$skipValidation to 1 before your GTRR set $$skipValidation to 0 immediately after you don't need to skip anymore uncheck "Validate only if field has been modified" check for errors etc... Also remember, that this might not be the best approach to solve your solution, however, it is accomplishing what you had asked for help with. Other workarounds: -Instead of ignoring validation, you could check for the contents of the field that has its validation turned on for "Not empty". If it's empty, then you could Halt the script or something to that effect... make sure that you're not in that situation in the first place -Alternatively, if you're deleting ALL of the related records, and not just the related records from one particular related table occurrence, then what you could do is to set up cascading deletes, duplicate the record you're on, and then delete the original. There are many different ways to tackle this. Regards Matt

Glad you got it working! :

Hey Arbatax; a couple of minor changes to what you're doing. These changes are because both arguments were enclosed wtihin your Quote() function The slashes from Get (DesktopPath) need to be reversed to use on the Windows OS "cmd /k ren " & Substitute (Quote( Right( Get(DesktopPath) ; Length(Get(DesktopPath)) - 1 ) & "foldername" ) ; "/" ; "" ) & " " & "new_foldername"

The next thing that I would suggest then, would be to omit the drive/path from the second argument. Since the "ren" command cannot change the drive/path of the folder to be renamed, perhaps doing something like: "cmd /k ren " & Quote("H:x") & " " & "y" This worked for me. Hope it works for you too! Matt

Hello Arbatax; I'm not on Win 7 right on this computer, so things might be different on your OS... so, because of that, I'm sort of shooting in the dark. I will provide some generic advice too though, in case my accuracy is poor due to the darkness. Firstly, whenever I've run folder-level operations on Win XP from within FileMaker, I've typically used the: Send Event ["aevt"; "odoc"; "cmd /c"] instead of "/k". I would give that a try, and see if it yields any better success for you. Should that fail though, I would recommend adding some extra info to the end of your command to tell Windows to pipe its output into a file. ex. adding " > F:output.txt" to the end of it, should hopefully create a new file called output.txt on your F Drive, containing the results of Windows attempt at your requested operation. Hope this helps Matt

Good to see you here as well Barbara, and to be honest, I hadn't seen your post at the time of my response. I would recommend that the OP use your suggestion (instead of mine) for simplicity's sake, and for the fact that it circumvents the need to override validation. I've read quite a number of your posts, and like how you both bring up concerns you have about particular approaches, and also directly answer the questions posed by various posters. Keep up the good work! Matt

There are certain script steps (ex. commit record) that can bypass validation. If the step that you're trying to perform does not support this type of feature, then the way that I would go about bypassing the validation would be by setting a global variable as a flag. (ex. $$skipValidation) You could probably set $$skipValidation equal to 1 at the beginning of your script, do what you need to, and then set it back to 0 or NULL. Taking advantage of something like this would also require you to change how you configure your validation of course. Instead of simply requiring "Not empty", you would want to change your validation to "Validated by calculation" Something along the lines of: Case ( not $$skipValidation; not IsEmpty ( Self ); //else 1 ) and you'd probably need to uncheck "Validate only if field has been modified" so that it takes effect on new records too. PS --> Even if you do choose to take this approach, I would still recommend that you check the layout, check for errors, and potentially (if possible) the found count etc. first prior to ever performing a delete-all.

No problem. : In most cases, it won't be necessary to have 2 calculations for this purpose though. In most cases, I use one of the value lists that inserts one field, but displays the contents from another. If you're doing that, then you can have the primary key as the field that gets inserted, and the calculation as the field that gets displayed. Even though the primary key might have a value for a particular record, if its corresponding calculation does not, then nothing will show up in the value list, and hence, that primary key can never be inserted into a field through that value list. As for the incorrect contact displaying on the top-most field. Is that field pointing to the same table occurrence that the layout is based on? If it is, then that will need to be changed. Assuming that the field that you can enter from browse mode is a field created specifically to store the supplier's ID, then I would have a relationship based on that ID... relating to another occurrence of Contact (ex SupplierContact). Once that relationship is created, then the top-most field on your layout can be directly pointing to the contact name from the SupplierContact table occurrence. Best of Luck! Matt

Hi AndyCan; The way that I typically go about this, is to create a new stored calculation field in the CONTACTS table. The calculation could be something like: Case ( contactType = "Supplier"; contactName; //Else "" ) This calculation will only return the contact's name if the contact is of type "Supplier"... otherwise it returns a NULL value. When FileMaker creates a ValueList, it will exclude any entries that have a null value. So, essentially, you can make your value list use the calculation field. HTH

Thank you for your response Barbara, and sorry for my delayed reply. I think I have found a 'workaround' though. Instead of programmatically manipulating the text that I need right-aligned, I've used a template type of approach. I'm taking a text block such as <> <> <> storing it in a global field, manually right-aligning the text <> and performing a scripted "Replace" to substitute the merge tags with the text that I really want to use. The alignment is persistent. I hope this helps somebody else, because I was really racking my brain on this one... even though it's such a simple solution.

Daniele - That's much simpler! )