How to update the List Box Field when its value has been changed with another callback function

Hi Yi,

I think the problem is that you are not saving the result of remd back to the list and this can cause items to remain on the list.  Try :

  pinNameList = remd(pinName pinNameList)

Apart from this I think the code should work. I've tested variants of it and it seemed ok apart from the above.

Best regards,

Lawrence.

Hi Lawrence

Thank you for your reply.

As "remd" is a destructive removal, so the original list itself would be modified, thus I did not save it.

On the other hand, I also tried your suggestions out, unfortunately, it does not work.

I also do another experiment:

I have create a list box field as below in the form (FORM1)

fPinInfoSel = hiCreateListBoxField(
        ?name 'fPinInfoSel
        ?choices pinInfoStringList
        ?value pinInfoStringList
        ?defValue pinInfoStringList
        ?numRows 50    
        ?multipleSelect t
        ?keepHistory t
        ?enabled t        
    );createListBoxFiled

where pinInfoStringList = list("a" "b" "c" "d" "e")

in the CIW window, I loop the content in of the "pinInfoStringList", as

foreach(pinInfoString pinInfoStringList

    FORM1->fPinInfoSel->value = pinInfoString

    printf("%s\n", pinInfoString)

);foreach

In the CIW window, I do see the "a", "b", "c", "d" and "e" has been printed out one by one.

But in the FORM1 does not change accordingly. It just shows "e" has been selected in the end.

It seems that the FORM1 does not updated inside the "foreach" loop.

Do you know why?

Best Regards

Yi

Hi Yi,

This is a long standing issue. I have reported this a long time ago and it is not yet fixed.

A CCR has been filed, but I don't know the number anymore.

Quek, can you please look-up the CCR and add the number to this post?

Kind regards,

Sjoerd

There is no bug here. 

The original problem is caused by the use of remd(). There are two problems - one is that the return value of remd() is not being used - and whilst a destructive removal of an entry in a list is OK, if you remove the first entry in a list this way, it does not change the list contents, but instead returns a pointer to the new beginning of the list. For example:

lst='(1 2 3 4 5)
remd(2 lst) => (1 3 4 5)
lst => (1 3 4 5)

remd(1 lst) => (3 4 5)
lst => (1 3 4 5)

The reason for this is that the variable lst is pointing to the list cell containing 1 - and the remd() function has no idea what variables are pointing to the same list - all it can do is destructively remove entries within the list, and if it's the first, change what it returns the pointer to. So this is to be expected.

As Lawrence said, you should use the return value of remd.

However, a second issue is that using remd() interferes with the form - you're manipulating data that is used within the form, and what happens is that the selection itself doesn't notice the removal - because you removed it from the list on the form itself. This is just a side effect of using destructive operations on a list that is shared with the form - and so you're getting odd behaviour. Luckily it's easily solved - either use remove() instead of remd(), or continue to use remd() (using the return value as Lawrence suggested) but do it on a copy of the original list:

procedure(fFilterButtonCB(form)
let(
(
    DeSelPinKeyWordList ;list of key words for deselected pin
    pinNameList ;an operation list
);local variable
    DeSelPinKeyWordList = parseString(SISpinInfoSelForm->fDeSelPinKeyWord->value)

    pinNameList = copy(form->fPinInfoSel->value)

    foreach(DeSelPinKeyWord DeSelPinKeyWordList
        foreach(pinName pinNameList
            when(rexMatchp(DeSelPinKeyWord pinName)
                pinNameList=remd(pinName pinNameList)
            );when
        );foreach pinName
    );foreach

    form->fPinInfoSel->value = pinNameList

);let
);proc

As for the final issue with the loop, that's to be expected too.

For a start, the code should be this:

foreach(pinInfoString pinInfoStringList

  FORM1->fPinInfoSel->value = list(pinInfoString)

  printf("%s\n", pinInfoString)

);foreach

Once this is run, the UI only updates at the end - the code is still running and so you won't see the form refresh. So I'm not really sure what you're expecting it to do.

So I'm not sure what long-standing issue Sjoerd was referring to - there's nothing wrong here.

Regards,

Andrew.

Hi Andrew and Sjoerd

Thank you for your reply.

I have tried out the suggestion from Andrew, and it works.

After I fix two issues mentioned by Andrew, the code works as what I expected.

I have also tried with only fixing only one of them, it seems that directly manipulating the form data is major issue. It makes the form has strange results.

Best Regards

Yi

One should always be careful when using destructive operators on lists - you have to know exactly how other consumers of the same list are using the data to know whether they might be impacted. If you are responsible for creation of the list and all operations on the list, then it's under your control and you can take advantage of the efficiency improvements that destructive operators can give you.

Regards,

Andrew

Hi Andrew,

I am talking about an issue described in case 45640742, CCR 1311953 (according to ticket it is now solved in 6.1.7).

I thought the problem as originally stated was similar (if not the same) to what I was experiencing.

This is definitely an interesting post to bookmark, the use of remd, never used it...

With kind regards,

Sjoerd

Hi Sjoerd,

That CCR is related to CDF callbacks being able to update the choices in a cyclic field. This thread is related to altering the selected values in list boxes in general forms (nothing to do with CDF and nothing to do with cyclic field choices). Even if it had been related to cyclic fields in an "hi" form, changing the choices there in a field callback is possible - it was just that the CDF callback mechanism didn't know how to cause the related form to be triggered to update the choices - so it was a CDF (and associated application that's using CDF) specific issue.

Regards,

Andrew.