Yes, method two, virtual list would probably be the way to go. Mark your question as answered. you had your own good suggestions.
Although, I might just use conditional formatting (background or text colors) based on the type and this would "separate" those types.
I display contact data like this all the time. Virtual list works great. Also you can use the blank line as a place for someone to add a new related record of each type. If you are going to hang a contact data TO off the virtual list just be sure to add an x join to the relationship and change the value to get it to refresh.
You can also use a $$variable on the layout, and build its content, including extra rows, via a script that runs OnRecordLoad.
Another method is to use single-row portals (or double-row, depending on data content) for each bit of related data. Place the portals where you want them, with desired spacing between, and then filter each of them to show only the appropriate related data. This would give you group-block or single-row/field levels of control over placing the data on the layout.
I like this idea Stephen. What would you do if you have more rows of data than portals?
This is a template I have been working on using the virtual portal technique. Its allows great flexibility for users when they are not sure how much of each data set they are going to need.
I also wanted to show this because it also shows that you can simulate summaries and headers in portals with other methods. As shown by list of contacts on the left.
You can still use portals with scrollbars, allowing the filtering to determine which data appears in which portal. Some of them will need to be scrolled if there is more than you provided on-screen rows to appear.
Thanks very much for sharing the demo movie Jared, that looks pretty slick. Could you possibly post a screen capture of what the layout mode looks like?
And by now I'm sure you've decided that your "Option 1" is a non-starter. Dummy records are a bad idea for just about any purpose. Best of luck with however you decide to proceed.
really that isn't going to help you much. Its just a portal with lots of crap all in the first row.
Here is the recipe..
1. virtual portal.
2. Two tables off the portal. One with the appropriate contact data and the other with one record for each data type. Both are tied to the list by id.
3. sql call to make the global var to populate the virtual list... but I actually do one for each group. I then concatenate with an id from another table to provide the space and place to add things. It ends up looking like this
id <- from phone from detail table
id <- from phone from detail table
id <- from phone type from detail type table
Empty <- really i just use the word empty. makes hide calculations easy
id <- from email from detail table
id <- from email type from detail type table
id <- from url type table
So the virtual list is populated by ids and the word empty. The detail table has one field for each type of value so it can format it. For example my demo formats the phone. Others that don't need formatting use the same general text field.
4. I use a lot of the new hide function. If its not a phone line then I hide the phone field. I hide all the add buttons unless the id is from the type table, rows labeled empty get all hidden.
Hope this helps you figure things out direction.
Thanks Jared. That really helps.
Yes, the hide feature in FM13 is really great. Imagine what we could do it they gave us layout layers (similar to the layer feature in Photoshop and Illustrator) that we could toggle on and off. I am going a bit nuts having to stack things on top of each other. It makes it really hard to make layout changes.
When your editing a stack of elements make sure you are using themes and saving elements properly. Then you can change the elements on another layout where you have them all separated and the style will be applied. Also you can move the elements out of the portal and drag one down, then distribute them all vertically. That way you can see them all and position them. Then align centers and drag the group back.
And keep in mind that there are serious limitations with stacking elements if the solution will be used via WebDirect, which fails to create any level but the topmost visible "skin" of the layout — no click-throughs, etc.
That is a good point but you won't have any issues if you are using "Hide object" properly. I have tested my solution and it works fine in web direct.