Jump to content
rt916

Script Trigger to show/hide a field based on data in another field

Recommended Posts

Hello,

I am working on an older FMP 11 database and trying to create some new features while we wait to migrate to FMP 14. I setup a layout with some basic data collection, where some of the fields are simple YES/NO drop down selections. The data gets populated into another layout for printing and exporting, and I have a few fields where the visibility needs to be based on the result of the YES/NO response. That seems to be available with the inspector in FMP 14, but all of the users are on FMP 11 for a unknown amount of time. 

I assume this needs to be created using a script trigger on the layout, to run at OnRecordLoad.

Something like If table::record = YES, display this text result. But I am new to FMP and learning the functions.

Any help would be very much appreciated!! Thank you in advance!

Share this post


Link to post
Share on other sites

I think the Hide When... functions only became available in FM Pro 13

After that you get into different layouts for for showing/hiding (blecch!)

  • Like 1

Share this post


Link to post
Share on other sites

One way to do it is with conditional formatting. Based on the results of a calculation, you can change the color of the text to match the layout background; or, you can change the size of the text to a very large number so that it's pushed outside the boundaries of the field or text box.

  • Like 2

Share this post


Link to post
Share on other sites

Hey Fitch do you have an example I can look at possibly? Not sure if I would have to change the YES/NO field to a value list, and return a 1 value with a checked box to base that calculation off. Seems like all these FMP 11 work-arounds get very... creative! Maybe I should push for the new features to be available on FMP 14 and try building them in there?

 

Share this post


Link to post
Share on other sites

Another option is to place the objects inside a portal, and make sure that a related record exists or not, based on the selection. It's not quite clear what exactly your need is: do you want to show/hide the fields when printing, or during data entry, or ... ? Your mention of exporting is especially confusing, as that has nothing to do with what's shown on the layout.

Anyway, script triggers play no role here - unless you are browsing records in Form view, and want the layout to change according to the loaded record's status.

---
BTW, I would recommend you use 1/0 (or 1/empty) for Boolean fields, instead of YES/NO - see:
http://fmforums.com/topic/47570-set-a-field-based-on-portal-content/#comment-222189

 

Edited by comment
  • Like 1

Share this post


Link to post
Share on other sites

we are browsing records in Form view, and want the layout to change according to the loaded record's status. the collected data gets formatted and inserted into a layout that's setup for printing and pdf export. 

I thought about doing a portal but the end-result document is size 12 font, and I don't think I can fit the portal into a box that small!?

I'll try the 1/empty suggestion, that seems more like a logical expression that won't break as easily. thank you!!  

Share this post


Link to post
Share on other sites

I am afraid I remain confused. Browsing is one thing, printing and PDF-producing is another. You cannot switch layouts during printing.

Edited by comment

Share this post


Link to post
Share on other sites

That's my fault, not yours ;) It's difficult to explain some of these workflows over threads. But your advice is helping me figure it out!

I won't be switching layouts on a record-by-records basis. Only 1-2 records are affected by this issue and I think your suggestion to make them numbers will work. But, to make this even more confusing, the back end is on SQL server. So I would create/update the record in SQL as a number field right? and lose the text field. then change the field in FMP to a value list, and perform the calculation based off that. yeah?

 

Share this post


Link to post
Share on other sites
12 minutes ago, rt916 said:

So I would create/update the record in SQL as a number field right? and lose the text field

I guess. These is really a side issue, unrelated to your main question here. Whatever solution is found to that, it can be made to work with YES/NO values, too - just a bit less elegantly.

 

16 minutes ago, rt916 said:

then change the field in FMP to a value list, and perform the calculation based off that. yeah?

The value list has nothing to do with the calculation. It only helps with data entry and formats the field for display; the calculation works off the actual data in the field, and is unaffected by how the field is formatted on the layout.

 

20 minutes ago, rt916 said:

Only 1-2 records are affected by this issue and I think your suggestion to make them numbers will work.

I am not sure it matters how many you have. And as I just said, making them numbers will not solve the show/hide problem.

 

Share this post


Link to post
Share on other sites

FYI the suggestion Fitch had did the trick! Conditional formatting was a nice work around and the simplest to setup. Thank you guys for the help, cheers!

Share this post


Link to post
Share on other sites

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

  • Similar Content

    • By wedgeman
      I've been searching for some clear answers on db vulnerability, specifically related to scripting.
      We have a particular solution running in FMP13, with EAR. This is a peer-shared file design, which has hundreds of installations in peer-shared environments.
      User access accounts have been severely limited in released versions (no admin, no [full access]), limited menus, etc..
      Users are heavily striated by account privilege set.
       
      I've read bits here & there mentioning that initial opening scripts (onwindowopen, etc) at startup are particularly vulnerable, but haven't found anything definitive.
      1. is an opening script trigger a legitimate security flaw?? We use it to determine layout paths, check/confirm licensing, etc, so if it is 'hackable', what alternate option is there?
      2. I noticed that even attempting to bypass script triggers, the system requires a full access name/password.. BUT it also displays the name of the particular script (seems like a point of weakness to me)... Is there a way to prevent this?
    • By Joel Shapiro
      Hiya
      Can FMPerception show the elements that have script triggers that call a specific script?
      Thanks,
      -Joel
       
    • By Scott Pon
      Environment: FM13 with FM13 Server, mix of Windows 7 and 10.
      Is there a way to set a script trigger on if this portal row is new? IE, a script to run if this new child/portal record is new.  
      We have a parent record, and portal to Children records.  The children records have 2 fields: Profile Name and Process type.  Our user would like to enter a new child record (profile name and process type).  if the process type already exists, we will need to archive the existing record (matching the profile type).  There is more bI want to start with this first.
      I see script triggers to the layout "OnRecordCommit", but no similar script trigger for portals.  Any ideas on how to handle this?  Or am I going to have to add a button to go to another screen to accomplish this?
      Thanks.  I hope i gave enough info for you to help me.
       
    • By dav1089
      Hello,
      I want to create a script trigger which opens a layout based on account name ,create new record and put cursor in first field of the new record
      Now, I was able to direct user to specific layout and also created new record using New Record/Request function but somehow it doesn't put cursor in the first field , instead it selects whole record .
      Note: I also have script triggers attached to first and second field which runs on exiting the fields. (I don't think they affect anyways , but just mentioned to give idea)
    • By tdub808
      Aloha All,
      DISCLAMER
      I'm not a programmer nor a technical writer and also is ESL. So my writing is tailored to me or someone like me aka noobie as F* (toward me not you). Detail and step by step and as clear as possible. Please let me know if i’d missed something or grammar correction.
      System: As of 04-20-2016 (not potting around) macOS 10.11.4 (yeah I’m using macOS name form now on instead of OS X), iOS 9.3.1, Filemaker Pro Advance 14.0.5 and GO 14.0.4 
      OBJECTIVE
      Make merge variable to show the slide control panel's object name (the name of the front most slide panel). So when the file is open the merge variable will show the name of the from most slide control panel letting you know which slide you're on.
      ISSUE
      Merge Variable does not show value on open first window. Please read entirety below.
      WORKAROUND
      Although it's a lame hack that I prefer not to use but it does the job. I'd included these two ugly steps in the script Go To Object [ Object Name: "Panel2" ] then Go To Object [ Object Name: "Panel1" ] to have the merge variable show Panel1 name on opening of the file.
      # the number symbol or the hashtag is to comment as a note to yourself and others about the script line(s) (ignored when the scrip is performed functional line). Set Variable [ $$panelName; Value:GetValue ( Get ( TriggerTargetPanel ) ; 2 ) ]  #The "2" is the result value which is the name of the objectName that you gave it in the inspector panel. Number "1" will return the number of the panel. As in 1 (which is the first) of 3 panels or 2 (which is the second) of 3 panels or 3 (which is the third) of the 3 panels. Go to Object [ Object Name: "Panel2" ] Go to Object [ Object Name: "Panel1" ] #Refresh Window will work the same but I think it'll refresh the whole layout. FYI: "MVpanelName" is the object name of the merge variable "<<$$panelName>>." Refresh Object [ Object Name: "MVpanelName" ]  
      ENTIRE HOW TO
      Create a new file.  Choose File menu > New Solution… https://www.filemaker.com/help/14/fmp/en/html/create_db.8.5.html Enter Layout Mode. Choose View menu > Layout Mode or press COMMAND + L keys. https://www.filemaker.com/help/14/fmp/en/html/fmp_basics.3.7.html Insert Slide Control. Choose Insert menu > Slide Control https://www.filemaker.com/help/14/fmp/en/html/create_layout.9.42.html Name the each slide panel. Choose View menu > Inspector or press the COMMAND + I keys. Choose Position tab > Enter Name field. Press the Enter/Return key to commit the name to the object. http://help.filemaker.com/app/answers/detail/a_id/6147/~/naming-objects-in-filemaker-8.5-and-later Choose the next slide and repeat.     Create a script with the above script. Choose Scripts menu > Script Workspace… Type or copy and paste the script in the code box above in the the WORKAROUND section of this post. https://www.filemaker.com/help/14/fmp/en/html/create_script.14.3.html Choose Insert menu > Merge Variable. Name it the EXACT same as the name use in Set Variable objectName ($$panelName). https://www.filemaker.com/help/14/fmp/en/html/create_layout.9.35.html#1064499     Set File Script Triggers. (not a 100% sure this is needed) Choose File menu > File Options... Choose Script Triggers tab > click checkbox OnFirstWindowOpen > click Select button > choose your script > click OK button > click OK button. Set Layout Script Triggers. (not a 100% sure this is needed) Choose Layouts menu > Layout Setup... Choose Script Triggers tab > click checkbox OnLayoutEnter > click Select button > choose your script > click OK button > click OK button. Set Object (slide control) Script Triggers. (this is a must) Right click on the Slide Control Panel object > select Set Script Triggers... Click checkbox OnPanelSwitch > click Select button > choose your script > click OK button > click OK button. Enter Browse mode. Choose View menu > Browse or press the COMMAND + B keys. SEEKING HELP
      Please reply if you have a better solution to this terrible workaround.
       
      Mahalo All!
       
×

Important Information

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