Hi Ashish

This is a problem quite a number of us have "solved" in different ways - and in different versions of Apex.

The checkboxes in an IR created through apex_item.checkbox2 - when "checked" are not stored in session - a pagination causes a partial page refresh and the HTML is replaced.

You will need to keep track of the checkbox status manually.

John Snyders put together a more up to date example using Apex 5 on his blog - this is one way to do what you are attempting.

APEX Interactive Report Checkbox Row Selection | HardLikeSoftware

Take a look and see if this helps you - and remember to provide more information when asking a question - e.g. which version of Apex!

how to get answers from forum

Regards

Hi Ashish,

another approach to preserve checked values nicely described joelkallman-Oracle here Let's Wreck This Together...with Oracle Application Express!: Preserving checked checkboxes in a report . While the requirement and the idea behind is still perfectly valid, the implementation is a bit obsolete, so I tried to reimplement it using current APEX features and dynamic actions.

The underlying report select is

select
apex_item.checkbox2(1, empno, 'onclick="$s(''P1_CHECKED_CBOX'',this.value)"',a.c001) cbox,
"EMPNO",
"ENAME",
"JOB",
"MGR",
"HIREDATE",
"SAL",
"COMM",
"DEPTNO"
from "EMP" , apex_collections a
where a.c001 (+)= empno
and a.collection_name (+)= 'EMP_COLLECTION'

In the original solution it calls a JS function f_UpdateCollection(this) which executes a page process using the (undocumented) htmldb_Get function. I modified it a little bit and instead of executing a process, when the checkbox is checked, it's value is assigned to the P1_CHECKED_CBOX page item (using $s api function JavaScript APIs ). On this item there is an on-change DA that executes slightly modified PL/SQL code instead of using a global variable (line 9) it just takes item's value (note that this item must be submitted).

declare
    l_value  varchar2(4000);
    l_seq_id number := 0;
    l_collection_name constant varchar2(30) := 'EMP_COLLECTION';
begin
    --
    -- Get the value of the global which will be set in JavaScript
    --
    l_value := :P1_CHECKED_CBOX; --wwv_flow.g_x01;

    --
    -- If our collection named EMP_COLLECTION doesn't exist yet, create it
    --
    if apex_collection.collection_exists( l_collection_name ) = FALSE then
        apex_collection.create_collection( p_collection_name => l_collection_name );
    end if;

    --
    -- See if the specified value is already present in the collection
    --
    for c1 in (select seq_id
                 from apex_collections
                where collection_name = l_collection_name
                  and c001 = l_value) loop
        l_seq_id := c1.seq_id;
        exit;
    end loop;

    --
    -- If the current value was not found in the colleciton, add it. Otherwise, delete it from the collection.
    --
    if l_seq_id = 0 then
        apex_collection.add_member(
            p_collection_name => l_collection_name,
            p_c001            => l_value );
    else
        apex_collection.delete_member( 
            p_collection_name => l_collection_name,
            p_seq             => l_seq_id );
    end if;
    --commit; no need to commit here as APEX commits automatically
end;

So basically whenever any checkbox is checked, it triggers a DA that saves it's value to the EMP_COLLECTION. The nice thing is that we have a declarative way to run the PL/SQL block asynchronously on the background, so the user does not have to wait until the value is saved (Wait for Result = NO).

Please, see the working example on https://apex.oracle.com/pls/apex

workspace: testing

user: supporter

pwd: supporter1234

app: Application 105127 - preserve_report_checkbox

Regards,

Pavel

Hi Pavel

I have used Joels version myself many times - updating a collection and using that as an outer join in the select statement

I've also always forced a "synchronous" DA to ensure that updating the collection happens correctly (i.e. duplicate clicks on the same checkbox work as you expect them to... rather than potentially out of sequence)

What do you think about the future (Apex 5.1 and beyond) where the synchronous element of the DA is no longer available by default?

i.e. all DA's will be asynchronous

The way discussed by Joel probably needs amending/tweaking to incorporate this.

I think John Snyder is trying to address this in his post.

I may try to apply John's ideas to the collection version - unless you've already done so and can shed your thoughts on this!

Regards

Kelvin

Hi Kelvin,

sorry for a bit late response. I'm not that familiar with APEX 5.1 yet because of obvious reasons. So far I've just toyed with APEX 5.1 (https://apexea.oracle.com/ ) and my impressions are that:

1) the new Interactive grid is pretty cool and feature-rich,

2) DAs look same way in the page designer (e.g. there is still the very same Wait for the Result toggle button), so I don't care too much how it's implemented internally.

John's method involves quite a lot of custom JavaScript (which can potentially cause some problems in later APEX versions...just a feeling) while Joel's uses only the APEX API, is pretty straightforward and completely understandable.

There is no reason why the method described above should not work also in APEX 5.1 (I haven't tested it yet though), so for me the choice is simple.

Regards,

Pavel

Thanks for getting back to me Pavel.

Its the "Wait For Result" bit that interests me as this may change going forward

The following forum post - John Snyders response - made me wonder if we should be catering for the death of the "synchronous" DA in Apex right away to help future proof upgrades.

Synchronous requests deprecated

Plus Johns blog page - APEX and Asynchronous Ajax | HardLikeSoftware

I was just hoping to pick up on a nice way to make things future proof :-D

Currently though, as you said, I agree that the collection version is easiest.

Regards

Kelvin

I'm definitely not the one who can make these things clear. From my point of view the Wait for Result toggle button is not going to disappear. I just believe APEX devs do care of the backwards compatibility and if this functionality was removed, lots of apps would start to produce pretty surprising results.

Also if there was no way to keep consecutive true actions in one DA "synchronized" (e.g. run one after another is finished), I would consider it as a serious limitation...in fact it would be IMO broken.

Regars,

Pavel