vanishing button in a portal

[onefish]

I think I am after the impossible but here goes anyway. I must create one table to handle two different types of records. This is not ideal, I know but I need them to display in the same protal by order of date. I can report on them seperately through scripts though. One type of record has a cooresponding form view and there will be a "goto related record" button in the portal. The other type of record has no form view as the entire records data is easily displayed in the portal. I do not want the "goto related record" button to appear in the portal records that do not have a cooresponding form view. I can make the button a calculation field - result is container, which shows the button if the record type is correct. That's easy enough. I can also halt the goto script if the record type is incorrect. Here's the impossible part. I am 85% through this solution (100s of hours) and all buttons throughout the database change the cursor to a hand. I would like to be consistant for the user's sake but the hand in a portal without a visible button may confuse people. Likewise, if this is the only button in the database that doesn't turn the cursor to a hand it is likely to confuse people. Any ideas?

[onefish]

I was thinking and unless there is another way I may use a repeting container field with two repititions. The first containing a yellow button that says "VIEW" on it and the second a light gray button with nothing on it. Use the calculation field formatted as a button to get the correct repitition for the record type. At least then the user will see there is kind of a button and the curser turns to a hand but nothing happens when they click on the light gray button. Is there another way?:?

[Søren Dyhr]

The repeating container are goin to remove the hand either. But you might view the portals content from it's own table and pull the data from the main table via the bidirectionality of the relations into the header area. This opens up for the visibility trick ...since you unfortunately cant have a portal in a portal. So you can make it happen via a change to the design...

--sd

[Dan-A]

How about 2 forms...

Form A

with the portal to display your data...

I use underlined text(which looks like a link to something) make that your GTRR

button. You can even GROUP all the fields in the portal line and make that your button...

The user clicks anywhere on the line and goes to the related record.

Form B - same look with the text NOT underlined and not a button..

[onefish]

SD,

Are you suggesting table view of the layout? That, along with the visibility trick would work. Unfortunately the form view used throughout the solution is a file type arrangement with all file tabs accessible from nearly all layouts. With changing colours and things it has the appearance of opening the file with the tab that is clicked. Of course it actually only changes layouts and much of the file/tabs are duplicated on the new layout. It is a very ergonomic layout and required little training to get people to understand the navigation system. It would be impossible to duplicate the layout in table view.

[Søren Dyhr]

Not table but list view

Of course it actually only changes layouts and much of the file/tabs are duplicated on the new layout.

Other options exists, although it's in you case might be imposible, the coloured background might be changed as mergefield expoiting the webding char g and the new TextFormatting functions, and the tabs could be made different as well investigate this on Edoshins page:

http://www.onegasoft.com/tools/smarttabs/index.shtml

--sd

[onefish]

SD,

Thanks for the link. The Smart Tab technique is very interesting. There are many ways to skin a cat. The real benifit that I can see is utilising the current layout name and the portal row number the button is in for parameters in a single navigation script for the solution. I will play with it a bit but it's too late for the current solution.

[onefish]

SD,

OOPs, I meant repitition number not portal number. Has anyone else out there experienced a glitch with fm7 relationships? Using the related portal containing a single field as the demo you posted above, I had one of the relationships go funny. My calculations were more complex than the demo but it was not the calculation that was the problem. The glitch is that the relationship would not update until I clicked out of all fields on the body. I could tab through the fields and even run a comit record script but the relationship only updated when I clicked on the body. Two other portals both based on different criteria updated as soon as the match fields changed. I created a new relationship with exactly the same criteria as the faulty one and changed the portal and fields to the new relationship and all was good. I have discovered this problem in a contatenate calculation field based on related information on another layout so it must be a glitch with FM.