Visualforce page:

<apex:page standardController="Member__c" extensions="MemberExt" recordSetVar="Member">
    <apex:pageBlock >
        <apex:pageBlockTable value="{!memList}" var="M">
            <apex:column value="{!M.Name}"/>
            <apex:column value="{!M.Age__c}"/>
        </apex:pageBlockTable>
    </apex:pageBlock>
</apex:page>
Apex Controller:
public class MemberExt {
    public List<Member__c> memList {get;set;}
    private ApexPages.StandardSetController standardController;
    private Set<Id> memIds = new Set<Id>();
    public MemberExt(ApexPages.StandardSetController standardController){
        this.standardController = standardController;
        memList = new List<Member__c>();
        for (Member__c mem : (List<Member__c>)standardController.getSelected()){
            memIds.add(mem.Id);
        }
        memList = [SELECT Name, Age__c FROM Member__c WHERE ID IN: memIds];
    }
}
Custom Button:

Output:




have you seen a problem where the very first time through, the getSelected returns empty even though selections have been made...?

You can observe this situation by following below steps:
i) Login as user
ii) Go to the tab, Select the list view and Click on "Go" button to show the list view of all the records
iii) Select all the records and click on the custom list view button that redirects to visualforce page.
iv) Now, even though records have been selected, my page shows empty. This can be observed only the user didn't navigated to any other visualforce page after logging in.
If the user navigates any of the visualforce page after logging in, then the selected records shows properly without any issues. Is there anyway to make sure selected records are shown even when this is the first visualforce page that user navigates to.?

Thanks in advance.

We're developing an app and switched from using GETs with long URLs to POSTs to overcome limitations with large numbers of records.  Our managed app refers to other managed apps (some of which we wrote) in order to extend the functionality.  When we try to send a post to that other app (which, being managed, is on a different subdomain), the request is redirected a few times, first to "ourInstance.salesforce.com/visualforce/session" with the url attached, then "destinationNamespace.ourInstance.visual.force.com/visualforce/recsession" before finally redirecting back to the requested page.  I believe that this redirect chain is to properly handle the session handoff because once the session cookie is set, it doesn't do it again.

This wouldn't be a problem, except that it converts from a POST to a GET by the end.  This means that the first time you use this app from our app, it appears to have ignored your selection.  This is somewhat frustrating for us as we have had to implement a workaround where we requested a resource file from the destination app during the initialization of our javascript so that it handles the session and subsequent requests work as anticipated.

The workaround is klugy and wasteful, but effective.  We are curious as to whether anyone else is struggling with this and if Salesforce is aware of it.  I don't know when it started because we didn't switch to POSTs until after Summer '14.

 

We're developing an app and switched from using GETs with long URLs to POSTs to overcome limitations with large numbers of records.  Our managed app refers to other managed apps (some of which we wrote) in order to extend the functionality.  When we try to send a post to that other app (which, being managed, is on a different subdomain), the request is redirected a few times, first to "ourInstance.salesforce.com/visualforce/session" with the url attached, then "destinationNamespace.ourInstance.visual.force.com/visualforce/recsession" before finally redirecting back to the requested page.  I believe that this redirect chain is to properly handle the session handoff because once the session cookie is set, it doesn't do it again.

This wouldn't be a problem, except that it converts from a POST to a GET by the end.  This means that the first time you use this app from our app, it appears to have ignored your selection.  This is somewhat frustrating for us as we have had to implement a workaround where we requested a resource file from the destination app during the initialization of our javascript so that it handles the session and subsequent requests work as anticipated.

The workaround is klugy and wasteful, but effective.  We are curious as to whether anyone else is struggling with this and if Salesforce is aware of it.  I don't know when it started because we didn't switch to POSTs until after Summer '14.