If I don't want to customize portal, it could have automatic header. You could set number of columns, define field and column title for them. Then If clicked on a column header, it will be sorted automatically.
It was already implemented in Bento
As an extension to this, I've often wished for a "table control" which, like a portal, could display related records. Unlike a portal, you would simply define which fields would appear in the control and FileMaker would automatically insert them. The user could expand, rearrange, and sort to their hearts' content.
also a automatic footer which could summerize the column. I think bento did that also.
Yes, this would be great! I can't tell you how many hours I have spent making portal row headers, and they aren't even sortable! I'd like to see this for list views too.
along with "headers", I'd like to see other "parts" on portals, such that we can have sub-summaries and footers for totals. I guess this is like having form and list in the same view...
This type of UI widget is often called a "Data Grid" or "matrix" in other platforms...
Features that are often provided are:
this is good, but partially a duplicate with "Horizontal portals" and the discussion there.
Given that Bento had this some time ago, I keep wondering why it never showed up in FileMaker itself. My speculation was that it used some Mac OS specific code, but that is just a wild guess. Having said this, I believe that MS Access has offered such a control for ages as well.
I would like to see an entirely NEW type of portal object. This would allow FM Inc to not break anything and still give us the functionality that we are all craving.
- Setup of the new portal object would include it having it's own inspector window like the button bar.
- Add fields to the portal via a selection dialog in a new Portal Inspector.
- Drag and drop fields from the Field Picker directly onto the portal to add them.
- Column width settings and field order would behave like table view on a layout.
- Additional tweaking of the column widths could be done via the portal inspector.
- Ability to apply the Hide Object When calc to each field in the portal.
- Allow fields to still be accessible via script even if hidden.
- Hidden fields would auto adjust the other fields in the portal just like adding or removing a column does in table view for a layout.
- Field Labels would actually be a part of the portal and would allow text and/or icons like the Button Bar.
- As discussed previously, Allow users to sort the portal by clicking on the column (field label) header. This would remove the requirement for the developer to use a hack to achieve this ability. It should be a native feature. The sorting could even function similarly to Table view on a layout.
beverly wrote:along with "headers", I'd like to see other "parts" on portals, such that we can have sub-summaries and footers for totals. I guess this is like having form and list in the same view...
Or maybe what you are asking for is what HTML calls an iframe, where you can essentially have a layout within a layout. In terms of this request, that FM iframe window might be a table view or list view (with or without sub-summary parts), etc, and with all the options that we already have in a layout.
then vote here :-)
Subsummaries in sorted portals
nope! not really an iFrame. Pop-overs? or Cards (as in Product Roadmap Next)?
iFrames are embedded in a window/frame - sort of like the Web Viewer. Pop-ups (web) can be a new window entirely and float above the main window.
What you are asking for here, Bev, is an automatic header, plus sub-summary parts, etc -- everything an FM table view already provides. Plus, a table view gives you the quick ability to change found sets, easy sorting, etc. The one problem with a table view is that it requires its own layout and cannot currently be "placed" within a layout or popover.
My thinking with an iFrame type object is to give you a direct view of a second FM layout -- such as a table view -- within the current layout, with the ability to specify whether the view is to be based on a relationship or not. The frame might otherwise be set to display a list view...or even a standardized navigation area that is layout based but can be displayed within multiple layouts.
I realize the scope of this goes way beyond this particular feature request, but it seems to me it would be a way to accommodate this request and many others. It's an idea I used quite a bit when I was programming in MS Access 2.0 (before I'd discovered FileMaker) and it is still one of the Access features I miss in FM.
One last note, since you mention popovers and cards: popovers are limited to same-table or related data and cannot as easily be applied to multiple layouts. Cards are presumably a separate window type -- a nice-to-have in its own way, displaying context that can be separate from the current layout and displayable from any other layout...but since it is considered a separate window, it doesn't and can't serve as the in-layout portal/table view display this request is asking for.
Retrieving data ...