I see no reason to hide fields in that layout. What problem are you solving by hiding fields? Can you provide an example?
You interface is cluttered beyond what words can describe, but keep in mind that when using a portal for data input, you can improve the situation by working at the portal:row level and specifying a different, eye-catching formatting for the active state as opposed to a mild formatting for the rest.
Sometimes you want the speaking person to sound louder than the mass: one way is to pump up the mike volume, another way is to mute the mass.
You built a bad interface and now trying to clean it up at the interaction level by hiding things in order to help people focus on a specific field.
Think better, redesign the whole interface and you won't need tricks to fix what's broken at the root.
I was wanting a total for each category so I created a price field for each category and layered them on top of each other. Really messy. I started with one field but did not know how to get totals for each categor, which I need. I know there must be a simple way to do this but couldn't work it out.
Yes, there are better options. The same field can calculate different totals for different categories by using either a relationship or ExecuteSQL.
Are there any examples if this. I am the first to admit that I need some help.
1 of 1 people found this helpful
I can't provide a detailed example that matches your data model and how you want these totals to calculate as I don't know enough detail. Thus, the following example may need modification to fit your needs:
I can see that you have a layout, a portal and that your portal records are assigned to categories.
So you have a relationship for the portal, perhaps:
LayoutTableOccurrence::_pkLayoutTableID = PortalTableOccurrence::_fkLayoutTableID
But with different names
So you might set up this relationship:
PortalTableOccurrence::_fkLayoutTableID = PortalTO2::_fkLayoutTableID AND
PortalTableOccurrence::Category = PortalTO2::Category
Then a calculation field defined in your portal table to evaluate from the context of the portal's table occurrence: Sum ( PortalTO2::Cost ) will compute the total of all records of the same category that are linked to the same layout record.
PortalTO2 Is a second occurrence of your portal table.