This discussion is archived
8 Replies Latest reply: Apr 4, 2013 9:03 AM by Howard (... in Training) RSS

Why doesn't this work? Seems so easy...

1000162 Newbie
Currently Being Moderated
Hi - I'm using oracle 10g xe and apex 2.2 (constraints from the university server - i know).

I have a table
Tests
-testName
-testType
-testResult
-isImage

Where isImage is t/f if the testResult should represent an image file (based on the test type).

I'd like to have testResult represented on a form by either a radio group that has the possible images, which will conditionally appear if isImage is true (done - got this working) or by a textfield if it is just to be a free-form result (also got this working). To do this, I change P17_testResult visibility based on the isImage flag. I've created a new dummy item as a radio group, P17_testImages, and I am trying to assign the value of P17_testImages to P17_testResult before writing to the db. P17_testResult maps to the database column testResult. I've tried also having P17_testImages point to the column, but I get a duplicate column error. No matter how I try, it doesn't seem to work. I've tried adding a computation based on item value, putting P17_testImages in for P17_testResult, tried writing procedures that will do the assignment, etc, but nothing seems to work.

How, can at the time of submit, I change the value of one page item to that of another? I'm sorry if this is a real beginner question, but i'm pretty new with apex.

Thanks so much

-glen
  • 1. Re: Why doesn't this work? Seems so easy...
    Nattu Explorer
    Currently Being Moderated
    Hi,

    You can do it in after submit computation or process.

    In the after submit computation, just assign the value to the item

    Eg. :P100_X1 := :P100_X2

    Regards,

    Natarajan
  • 2. Re: Why doesn't this work? Seems so easy...
    Howard (... in Training) Pro
    Currently Being Moderated
    gvaj,

    The reason one needs to do what Nattu has given is because radio group items (variables) are not available in the session state like (many? most?) other page items (checkboxes, text fields) are. (There must be a reason this is so. Perhaps someone who knows can tell us why.)

    If you have tried to use the radio group without knowing this, I believe you will find that it's value seems to lag. That is because any value you are operating on is the previously "saved in the session state" value. The current value on the screen may be different.

    (More later as I have time.)

    Howard
  • 3. Re: Why doesn't this work? Seems so easy...
    fac586 Guru
    Currently Being Moderated
    Howard (... in Training) wrote:
    gvaj,

    The reason one needs to do what Nattu has given is because radio group items (variables) are not available in the session state like (many? most?) other page items (checkboxes, text fields) are. (There must be a reason this is so. Perhaps someone who knows can tell us why.)
    Not true. Radio group items are no different to any other item type.
    If you have tried to use the radio group without knowing this, I believe you will find that it's value seems to lag. That is because any value you are operating on is the previously "saved in the session state" value. The current value on the screen may be different.
    This applies to all items/types. Depending on user activity and/or page scripting, item values in the browser page can differ from those currently in session state on the server, until the page is submitted or individual item values are modified via AJAX.

    (I don't understand the original question. Demonstrating problems with examples on apex.oracle.com is a better use of your time than posting stream of conciousness descriptions here.)
  • 4. Re: Why doesn't this work? Seems so easy...
    Howard (... in Training) Pro
    Currently Being Moderated
    I need to more carefully check what I read from others then. And preface my remarks with "It sure seems to me like ...".

    Need to do more work on my example ...

    Later,
    Howard
  • 5. Re: Why doesn't this work? Seems so easy...
    1000162 Newbie
    Currently Being Moderated
    THanks for the input Nattu and Howard.

    I agree with Howard that it seems that the value in the radio group is lagging - in session state before and after submit it seems to stay as NULL. I have done what you suggetsed, Nattu, and put an "after submit computation", assigning the value of 1 item to that of the radio group. It doesn't work. That's what I was trying to do at 4am and was causing me grief. I'll try to get an example up later today - sorry I didn't post one last night, was just getting too late.

    Thanks

    -glen
  • 6. Re: Why doesn't this work? Seems so easy...
    Howard (... in Training) Pro
    Currently Being Moderated
    Glen,

    I think I have it now. The problem (for me) is not with Radio Groups but with understanding the semantics of "Source".
    NOTE TO ALWAYS REMEMBER: There are two values(?) for each item. One value is held in Session State and one is in the HTML displayed to the screen.
    [Now I'm reaching for the correct terms to explain the difference.  So here goes.] When the item value is derived by "Process" (i.e., :P3_ITEM1 := <value>; in a Before Header Process), the two will always be the same as the Session State is updated immediately. When the value is derived by the "Source" attribute of the item (say, P3_ITEM2), then the two can differ as Session State is unaffect by this assignment.

    So, just looking at the Session State, an item whose value is derived by "Source" can seem to "lag" the HTML value and "lag" the values of items derived by "Process". ["Process" or "Computation", I suppose they function the same.]

    I fail when I write code without regard to whether I want the Session State value or the HTML value. And it can be frustrating if I debug by checking the HTML value while operating on the Session State value.

    Edited by: Howard (... in Training) on Apr 4, 2013 10:41 AM
    To quote:
    Dan McGhan: Values of items on the page are pushed into "session state" when the page is submitted. {message:id=3653190}
    Arie Geller: If you are using the SQL query in the item’s Source value or expression field, the retrieved value will not set Session State. Computation, on the other hand, will set Session State. {message:id=9533409}>
    Howard
  • 7. Re: Why doesn't this work? Seems so easy...
    fac586 Guru
    Currently Being Moderated
    I'm still confused as to why&mdash;when the problem appears to relate to post-submit processing when all values are available in session state&mdash;we're having this lengthy discussion about the much-covered topic of rendered item values vs session state item values, with a digression into mythical properties of radio groups.

    I still need a clearer description/demonstration of the actual problem, which from what we have so far does not appear to have anything at all to do with source/default values.
  • 8. Re: Why doesn't this work? Seems so easy...
    Howard (... in Training) Pro
    Currently Being Moderated
    Paul,

    I plead guilty to some "Session State" obsession. But I was trying to both correct my earlier comment that Radio Groups somehow differ from other items ({message:id=10944004}) -- they don't. And to response to glen's statement :"it seems that the value in the radio group is lagging - in session state before and after submit ... ." It can "seem" to lag and I was trying to explain why that is. ({message:id=10944621}).

    A simplified example on apex.oracle.com could go a long way toward revealing the problem and it's solution.

    Thanks,
    Howard

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points