Yes, it is working fine in FM13. In some cases, depending on the data being set you may need a "Commit" and/or a "Refresh" script step for the result to render.
You may end up needing to post your file for someone to take a look at.
In his always excellent "Shaking the Dependency Tree" session at DevCon, Darren Terry emphatically made the point that, in his extensive testing, conditional formatting always seems to update immediately and predictably. ("It just works.") Same goes for the new-to-13 "Hide object when…." His point confirmed my own experience with these two features. Thus, it's not clear what may be going on in your case, although, like so many things, the devil is often in the details.
Thanks for the tips but I'm apparently struggling with a lack of experience in scripts (still don't know how to write them). I seem to be jumping from objects and fields in trying to build my script. The button is an "object"? And the prompts when trying to assign scripts and formatting always give me options to fields. I can't seem to find a way to assemble a script with the drop downs offered (they're always fields). At what point can I reference the object/button in the script options when writing the script? I'm guessing the "Formula" thing in the Conditional Formatting is the script formula. Kinda confusing.
Many Thanks, that's what I was trying (and It works on the same layout). My issue is the button/object is on another layout. I was hoping I could simply designate the table::field from another table and get it to work on a different layout
For writing a script, you should at first try to reproduce the actions that you'd undertake manually. Once you make a list of those actions, or a flow diagram, then it's a matter of putting together a list of the script steps that accomplish that listing or flow chart.
The conditional formatting of your button depends upon the value or "Condition" of some field or object. Your button can be a field so it's a matter of your script setting the value of that field, then the Conditional Formatting calculation will produce the colour that you want.
I hope this helps,
It now seems that your two layouts are based upon unrelated Table Occurrences.
Should you not want to relate them, then your script will need to switch layouts before setting the field on the required layout then revert to the former layout.
Hopefully that will get your Colour behaviour working.
Quite so. My demo will work on a related layout, but not on an unrelated one.
Sweet! I'll try on Thursday When I get back. Many Thanks!!!
Thanks for the help guys but no dice. I've related the occurances, however the table/layout with the button/object I want to change shows no related tables. Not sure why that's happening. In fact, in tests, I can't get that table to relate to ANY other tables. I've done the foreign key/primary key thing in all the combinations I can think of. I don't know of any other techniques to relate tables. I also don't see a way to build a script using objects, I can only build scripts using fields. It's always one or the other, that's where I'm really confused. It seems objects will not relate to other objects on other layouts. I tried to create a field instead of the button/object to display the status from the other field in the layout, but then I'm back where I started with not being able to relate the two tables together.
Your descriptions are all very abstract; it would be much more helpful if you'd describe what tables you're dealing with, and/or post a sample of your actual file; but let me note anyway that, if you cannot use defined relationships …
Thanks for the help guys but no dice. I've related the occurances, however the table/layout with the button/object I want to change shows no related tables.
… then you have probably not yet realised that context is the single most important concept in Filemaker. The layout you're on at a given moment determines your position within the Relationship Graph (because every layout is based on a table occurrence), which in turn determines what is considered a related TO, and what isn't (as per the connections in the RG) – which in turn determines what related records you can access within the tables related by specific occurrences etc.
If you create a relationship between two TOs, and one of the involved TOs does not appear in the list of related “tables” (e.g. when trying to place a portal, or define a CF calculation), despite your expecting it to do, then you're probably not where you think you are – i.e. you are not on a layout that is based on the other table occurrance involved.
Just an assumption, based on what one can glean from your post.
It might help to post your file.
Meanwhile, I don't know your experience level, so I apologize if this suggestion is way off base, but...
I have recently been helping a friend who is new to FileMaker, and he has repeatedly reported to me the problem you're describing -- related tables simply weren't available from his current location, and yet he knew he had created the necessary relationship.
In each case, when I've looked at his file, the problem has been context.
That is, he had indeed related the two base tables, but his current layout used a different occurrence in a different table occurrence group. So, in his current context -- on his current layout -- his needed relationship wasn't available.
I may be stating something that's obvious to you, and I apologize if that's the case. But this happened enough with my friend -- before he got comfortable with TOGs -- that it immediately comes to mind when you describe your problem.
I'm guessing the "Formula" thing in the Conditional Formatting is the script formula
No. It's a calculation. I has nothing to do with Scripts.
Here is a new version of the demo file I posted previously. I have created three layouts to demonstrate the effect of context, as eloquently described by erolst and jim. Note the file structure:
1. There is a field in table one whose value drives the conditional formatting
2. The conditional formatting is purely a text object, so does not belong to any table
3. Layout one is based on table one
4. Layout two is based on table two, and there is a cartesian (X) relationship between this TO and table one
5. Layout three is based on another TO called table two unrelated which has no relationship link to table one
6. Even though layouts two and three are based on the same underlying table (called table two) it is the table OCCURRENCE that determines the context