Event sequences for emphasis changes - OS2

This is a discussion on Event sequences for emphasis changes - OS2 ; Hello, Our program has two containers side by side. The left one is a tree view; the right one is in details views. Selecting a folder in the tree (left) view causes the contents of the folder to display in ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Event sequences for emphasis changes

  1. Event sequences for emphasis changes

    Hello,
    Our program has two containers side by side. The left one is a tree
    view; the right one is in details views. Selecting a folder in the tree
    (left) view causes the contents of the folder to display in the details
    view container.
    Also the tree view allows multiple levels which may be expanded and
    collapsed.
    When an expanded view is collapsed, the usual (expected) sequence of
    events is CN_EMPHASIS and the flags indicate a loss of emphasis. Then
    another CN_EMPHASIS with the flags showing a gain of emphasis. This is good.
    Based on the above, the code expects to clear the details window before
    re-populating it.
    But the opposite sequence is also happens! The gain of emphasis can
    arrive *before* the loss. This results with the details window briefly
    showing the contents of both folders before it is cleared, showing nothing.

    Is this normal behavior?

    --
    jmm (hyphen) list (at) sohnen-moe (dot) com
    (Remove .AXSPAMGN for email)

  2. Re: Event sequences for emphasis changes

    Jim Moe wrote:
    > Hello,
    > Our program has two containers side by side. The left one is a tree
    > view; the right one is in details views. Selecting a folder in the tree
    > (left) view causes the contents of the folder to display in the details
    > view container.
    > Also the tree view allows multiple levels which may be expanded and
    > collapsed.
    > When an expanded view is collapsed, the usual (expected) sequence of
    > events is CN_EMPHASIS and the flags indicate a loss of emphasis. Then
    > another CN_EMPHASIS with the flags showing a gain of emphasis. This is good.
    > Based on the above, the code expects to clear the details window before
    > re-populating it.
    > But the opposite sequence is also happens! The gain of emphasis can
    > arrive *before* the loss. This results with the details window briefly
    > showing the contents of both folders before it is cleared, showing nothing.
    >
    > Is this normal behavior?


    Sorry to possibly insult your intelligence by asking, but are you
    checking the TYPE of emphasis that is being gained or lost? Keep in
    mind that CRA_CURSORED, CRA_SELECTED, and CRA_INUSE notifications are
    all sent with this same message. Maybe the order of CRA_CURSORED and
    CRA_SELECTED are coming "out of order", but that should still produce
    well-defined behavior.

    --
    [Reverse the parts of the e-mail address to reply.]

  3. Re: Event sequences for emphasis changes

    On 06/30/08 07:17 pm, Marty wrote:
    > Jim Moe wrote:
    >> But the opposite sequence is also happens! The gain of emphasis can
    >> arrive *before* the loss. This results with the details window briefly
    >> showing the contents of both folders before it is cleared, showing nothing.
    >>
    >> Is this normal behavior?

    >
    > Sorry to possibly insult your intelligence by asking, but are you
    > checking the TYPE of emphasis that is being gained or lost? Keep in
    > mind that CRA_CURSORED, CRA_SELECTED, and CRA_INUSE notifications are
    > all sent with this same message. Maybe the order of CRA_CURSORED and
    > CRA_SELECTED are coming "out of order", but that should still produce
    > well-defined behavior.
    >

    Yes. I filter for CRA_SELECTED. Only that event calls the display functions.

    --
    jmm (hyphen) list (at) sohnen-moe (dot) com
    (Remove .AXSPAMGN for email)

  4. Re: Event sequences for emphasis changes

    Jim Moe wrote:
    > On 06/30/08 07:17 pm, Marty wrote:
    >
    >>Jim Moe wrote:
    >>
    >>> But the opposite sequence is also happens! The gain of emphasis can
    >>>arrive *before* the loss. This results with the details window briefly
    >>>showing the contents of both folders before it is cleared, showing nothing.
    >>>
    >>> Is this normal behavior?

    >>
    >>Sorry to possibly insult your intelligence by asking, but are you
    >>checking the TYPE of emphasis that is being gained or lost? Keep in
    >>mind that CRA_CURSORED, CRA_SELECTED, and CRA_INUSE notifications are
    >>all sent with this same message. Maybe the order of CRA_CURSORED and
    >>CRA_SELECTED are coming "out of order", but that should still produce
    >>well-defined behavior.

    >
    > Yes. I filter for CRA_SELECTED. Only that event calls the display functions.


    Any way we could see some code snips?

    --
    [Reverse the parts of the e-mail address to reply.]

  5. Re: Event sequences for emphasis changes

    On 07/03/08 12:27 am, Marty wrote:
    >>
    >> Yes. I filter for CRA_SELECTED. Only that event calls the display functions.

    >
    > Any way we could see some code snips?
    >

    case CN_EMPHASIS:
    {

    if ((NULL == (pnre = (PNOTIFYRECORDEMPHASIS) mp2)) ||
    (NULL == pnre->pRecord))
    break;

    is_select_change = (0 != (pnre->fEmphasisMask & CRA_SELECTED));
    is_selected = (0 != (pnre->pRecord->flRecordAttr & CRA_SELECTED));

    if (IDW_MESS == SHORT1FROMMP(mp1))
    {
    // ... not relevant here
    }

    else if (IDW_FOLD == SHORT1FROMMP(mp1))
    {
    // Only interested in a Selection change.
    //
    if (0 != is_select_change)
    FolderOnSelectionChangeThread(pnre);
    }
    break;
    }

    FolderOnSelectionChangeThread() uses the (flRecordAttr & CRA_SELECTED)
    value to either clear the container or load it with new data.
    By logging the values of is_select_change and is_selected above, is how
    I discovered the sequencing oddity.

    --
    jmm (hyphen) list (at) sohnen-moe (dot) com
    (Remove .AXSPAMGN for email)

  6. Re: Event sequences for emphasis changes

    Jim Moe wrote:
    > On 07/03/08 12:27 am, Marty wrote:
    >
    >>> Yes. I filter for CRA_SELECTED. Only that event calls the display functions.

    >>
    >>Any way we could see some code snips?

    >
    > case CN_EMPHASIS:
    > {
    >
    > if ((NULL == (pnre = (PNOTIFYRECORDEMPHASIS) mp2)) ||
    > (NULL == pnre->pRecord))
    > break;


    One "gotcha" here is when all items are deselected or the container
    background itself is selected. In that case pRecord will be NULL, but
    you might want to still be aware of this.

    > is_select_change = (0 != (pnre->fEmphasisMask & CRA_SELECTED));
    > is_selected = (0 != (pnre->pRecord->flRecordAttr & CRA_SELECTED));
    >
    > if (IDW_MESS == SHORT1FROMMP(mp1))
    > {
    > // ... not relevant here
    > }
    >
    > else if (IDW_FOLD == SHORT1FROMMP(mp1))
    > {
    > // Only interested in a Selection change.
    > //
    > if (0 != is_select_change)
    > FolderOnSelectionChangeThread(pnre);


    If this is truly vectoring out to another thread, you might want to
    reconsider that. You might instead prefer to use WinSendMsg (if that's
    possible with your program architecture) to keep the windows in
    lock-step with each other and remove timing dependencies. If that's not
    possible, then maybe some synchronizing semaphores will be needed.

    If I understand the problem correctly, you might be having one window
    enact a change on the other while the other window is trying to enact a
    change on the first. PM might merge redundant emphasis messages and
    skip one from your perspective. Is that a possibility?

    > }
    > break;
    > }
    >
    > FolderOnSelectionChangeThread() uses the (flRecordAttr & CRA_SELECTED)
    > value to either clear the container or load it with new data.
    > By logging the values of is_select_change and is_selected above, is how
    > I discovered the sequencing oddity.


    --
    [Reverse the parts of the e-mail address to reply.]

  7. Re: Event sequences for emphasis changes

    On Thu, 3 Jul 2008 18:12:26 UTC, Jim Moe wrote:

    > >> Yes. I filter for CRA_SELECTED. Only that event calls the display functions.


    Using CRA_SELECTED may be the problem - use CRA_CURSORED instead.


    --
    == == almost usable email address: Rich AT E-vertise.Com == ==
    __________________________________________________ _________________
    |
    | DragText v3.9 with NLS support
    Rich Walsh | A Distinctly Different Desktop Enhancement
    Ft Myers, FL | http://e-vertise.com/dragtext/
    __________________________________________________ _________________


+ Reply to Thread