Disabling button on layout

[Bill C.]

I've got a button on a layout for table A that, when clicked, creates a related record in table B. I'd like to disable this button if the related record already exists since only one such record is permitted.

What's the best way to do this? Is there a way to get a script to run when the layout for A opens?

Thanks in advance.

[Reed]

Add an If[isValid(relatedRecordField)] test to your script and if there is a related record, the script should exit, not add the record.

You can even use calculated text to change the text and the text color on the button to indicate the button is inactive.

Finally, you can place buttons in portals, where they are shown or hidden depending on the portal relationship.

[Bill C.]

Add an If[isValid(relatedRecordField)] test to your script and if there is a related record, the script should exit, not add the record.

What I was hoping to do was to disable the button rather than allowing them to click it, then react (by ignoring or popping a message.)

You can even use calculated text to change the text and the text color on the button to indicate the button is inactive.

I so far haven't been able to figure out how to change the text and/or color of a button. Also, where would I put such a script? It'd need to run when the layout first opens -- before the user has a chance to actually click the button.

Thanks for the help.

[IdealData]

Hi Bill. What Reed suggests is correct, and the EXIT SCRIPT step will give the illusion that the button is ineffective. In order to execute the script on change to layout then you'll need to script your layout changes and put buttons there to execute, but you must remove the layouts from the layouts list in the FMP cotrol panel (top left). I should know, I've got some 10,000 scipts in a 50 DB system.

Have you checked the FMP Help on scripting - there's lots of small samples in there, or possibly the sample DBs that came with your FMP7.

If you need a (small) start then e-mail me.

[Reed]

To change the button text color, you don't need a script. You would just define a calculated text field for which the text color was dependent on the presence of a related record:

Case(IsValid(relatedTable::relatedRecord;TextColor("text";RGB(100;100;100));"text")  

This way any records containing related records will show the button text as gray, and those that don't will just show the default color you define in layout mode.

[Bill C.]

Reed

Thanks for the further response. Sorry to be dense, but I don't find any where to put a calculated text value in button. I'm brand new at FMP so apologize again for probably missing the obvious.

[Bill C.]

Hi Bill. What Reed suggests is correct, and the EXIT SCRIPT step will give the illusion that the button is ineffective. In order to execute the script on change to layout then you'll need to script your layout changes and put buttons there to execute, but you must remove the layouts from the layouts list in the FMP cotrol panel (top left). I should know, I've got some 10,000 scipts in a 50 DB system.

I understand, but my intent is not to make the button ineffective, but to make it not even tempting!

If I understand you correctly ("...you'll need to script your layout changes") you are suggesting that all transitions from layout to layout be done via buttons rather than simply selecting from the layout menu. That sounds like a reasonable solution to the problem. I'm just used to event driven user interfaces so it's hard to get my head wrapped around what's available in FMP.

Have you checked the FMP Help on scripting - there's lots of small samples in there, or possibly the sample DBs that came with your FMP7.

If you need a (small) start then e-mail me.

I have spent a fair amount of time perusing the FMP help on scripting and it looks like a good reference for getting the details once you know what you need to do. It isn't so good at helping you figure out "what you need to do" however.

I'll take a look at the sample DBs however. That's a good suggestion.

Thanks again.

[IdealData]

Pretty much anything you can do with mouse you can do with a script. You can use extensive calculations to perform the logic control of your scripts, and you're right about scripting the navigation from layout to layout. My 50 DB system is TOTALLY SCRIPTED. Users cannot switch layouts without buttons

To learn "what you need to do" then do all the actions by hand, taking notes along the way. Then create your script(s) based on your notes, in the same sequence.

How can you make the button "not even tempting" ? It's a bit like "having your cake and eating it" :-)

Sorry Bill, you've got to have the button, so the least you can do is make it not work.

[Bill C.]

How can you make the button "not even tempting" ? It's a bit like "having your cake and eating it" :-)

Sorry Bill, you've got to have the button, so the least you can do is make it not work.

It is a standard of good UI design that you should not give the user an action when all the action will do is produce an error message; i.e., if the action is not permitted (or doesn't make sense) then don't give the user the option. In the MS Windows UI for instance buttons (and other controls) have a boolean Enabled attribute. If you set this to false then the button is presented in a "grayed out" manner indicating that the button is not operative. Ditto for menu selections. In some cases you might set the Visible attribute to false so that it doesn't even appear on the form (layout). That's what I meant by "not even tempting".

[IdealData]

From you're original post:

I've got a button on a layout for table A that, when clicked, creates a related record in table B. I'd like to disable this button if the related record already exists since only one such record is permitted.

You could use a second layout, almost identical but without the button. In order to determine which layout to go to then you must perform the test outlined by Reed earlier in a script, (but try using the COUNT function on the related records because the ISVALID function can return "false" for other reasons - see the help system), then you can determine which layout to use.

I use the same techniques, so a layout with (say) 5 "tabbed" displays is actually 5 different layouts, but each identical where it needs to be.

There are other ways to "hide" the button, but your button would still be there and require activity control in your script.

[Bill C.]

I use the same techniques, so a layout with (say) 5 "tabbed" displays is actually 5 different layouts, but each identical where it needs to be.

There are other ways to "hide" the button, but your button would still be there and require activity control in your script.

Mark

Interesting technique! I wouldn't have thought of that. I can see though how the number of layouts could grow very quickly using this technique. For instance I'll have 3 buttons (Client, Vendor, Employee) each of which can be there or not, so we're talking 2^3 = 8 layouts! Maybe I can figure out a way to use tabs to keep the number of layouts at least linear rather than exponential.

With all these near duplicate layouts is there a clever way of maintaining them or do have to manually change all of them if you need to, for instance, add a field?

Thanks.

[IdealData]

You're gettin' there !

Sometimes it just a damned hard slog to get the results you're after. Yes, the layouts do grow and you must maintain them individually. I recently implemented a set of duplicate layouts to deliberately grant updating facilities (or not) to individuals identified by their PIN code, and whether they had been granted any form of access to specific layouts. It was complicated but works brilliant.

Alternatively...

Make your button from a container field (as a global). If you script control you can then change the content of the container field to be a graphic of your button or an EMPTY container (you'll need a global field for that too). Just use the SET FIELD script step to assign the appropriate BUTTON or EMPTY container to the container on screen. There will still be an "active" area where the container is displayed (and you need script control), but it is now invisible.

[comment]

Go to http://www.databasepros.com/resources.html and search for "visibility".

[LaRetta]

With all these near duplicate layouts is there a clever way of maintaining them or do have to manually change all of them if you need to, for instance, add a field?

That's exactly why I find ways around the 'easy escape' of just duplicating a layout, Bill. Remembering to make every change to every layout is a pain in the backside!!! It also bloats your Layouts list and file size.

Use visibility (as Comment suggests). I use make/break relationships to display many fields or buttons for User, depending upon multiple permissions or criteria. And I use invalid portal to display in Find. There are many methods available - ALL of which I'll take advantage of before I resort to duplicating a layout. In fact, I've never yet needed to duplicate one ... not since I was brand new and discovered Forums and alternate ways of solving these problems.

LaRetta

[sbg2]

It is a standard of good UI design that you should not give the user an action when all the action will do is produce an error message; i.e., if the action is not permitted (or doesn't make sense) then don't give the user the option.

I Agree wholeheartedly, unfortunately with filemaker you have to work for it a little bit. The attached is how I have been handling buttons that I want to Show or Hide.

Show_Hide_Button.zip

[Reed]

Reed

Thanks for the further response. Sorry to be dense, but I don't find any where to put a calculated text value in button. I'm brand new at FMP so apologize again for probably missing the obvious.

Once you create the field, you just use the Insert Merge Field... command to place the label.

This will gray out the button, but you should also look into what I mentioned about using a portal to conrol visibility of buttons on a layout. Comment left a link that shows how to do this.

[IdealData]

Well Bill, there we have it. About a 1,000 ways to skin the same cat ! When I made my first reply I figured you were very new (saw your previous postings) and addressed the problem in ways you could actually deal with now.

The solutions offered here vary wildly in their application. The "visibility" offering at databasepros has a beauty all of its own that when you've worked it out will put a big smile on your face. (Thanks also to "sbg2"). However, if you can't work out how it works then it not going to work for you. You'll need a strong understanding of relationships, and of course the necessary relationships and fields to support the "visibility" method.

So we end up trading off "easy escape" layout duplicating for "expert knowledge" relationships/fields/calculations.

In fairness, there are some real experts around on fmforums (a while ago I relinquished my "moderator" status to concentrate on my real job) each with our own experience levels. In my discipline I can't easily create new fields as I develop in a real time environment on live DBs in FMP Server (field creations and mods are not allowed when serving Dbs), so I had to adopt duplicate layouts to minimise down time to my 40 user base. Just think, if I shutdown for 1 hour, we lose 40 hours processing (=1 week of my programming !). I recently checked/changed every layout (about 1000) in 50+ Dbs for my companys new branding in 3 days.

It's a hard life, sometimes.