Trouble deleting multi-selected items

I can't figure out why this won't work.  I've set up a simple example of what I'm trying to do in the attached.  Basically, I want to select a bunch of items, click the arrow button and have them "moved" to the other listbox.

Adding the items to the second box is working great, the problem is removing all the selecting ones from the first box.  Only half of the selected items are being removed.  I've even tried doing them individually through a loop with the same results.  Works great if all I'm selecting is one item.  (4.0SP1)

???

[attachment deleted by admin]

Perhaps try something like this ..
I imagine there is a problem when incrementing the item index and deleting items at the same time
.. reversing the index list and incrementing from the bottom up seems to work ..

// kwb

  (DEFUN c:ListTest_ListTest_Add_OnClicked (/ rValue)

      (SETQ rValue (DCL_LISTVIEW_GETSELECTEDNTHS ListTest_ListTest_ListView1))

      (DCL_LISTVIEW_SETCURSEL ListTest_ListTest_ListView1 -1)

      (FOREACH rv rValue

          (DCL_LISTVIEW_ADDITEM ListTest_ListTest_ListView2

                                (DCL_LISTVIEW_GETITEMTEXT ListTest_ListTest_ListView1 rv)

          )

      )

      (IF rValue

          (DCL_LISTVIEW_DELETEITEMS ListTest_ListTest_ListView1 (reverse rValue))

          ;;(DCL_LISTVIEW_DELETEITEMS ListTest_ListTest_ListView1  rValue)

      )

  )

... also. I'm getting errors when loading and unloading the odcl.

I haven't played with using ,lsp files as .odcl's and am not familiar with the traps in doing so.
are you seeing those ??

if so, perhaps Owen needs to see the code and run it through the debugger ..

author=Kerry Brown link=topic=42.msg162#msg162 date=1187146983 wrote:
Perhaps try something like this ..
I imagine there is a problem when incrementing the item index and deleting items at the same time
.. reversing the index list and incrementing from the bottom up seems to work ..

That sounds like a winning strategy.  I'll give it a try tomorrow when back in the office.

I just put this example together really fast today, but it is handled the same as my applicaiton is this is going for.  The only errors I sometimes get are two .arx unhandled excemption dialogs when I close AutoCAD while the Editor had concurrently been open and some changes were saved to the odcl/lsp file.  I don't know of any traps beyond what I have in the example code, any pointers would be greatly appreciated.

Kerry, this is what Owen instructed me to do - in a thread over at sourceforge I think:

(if (not (vl-bb-ref 'jbVmanager))
  (vl-bb-set
    'jbVmanager
    (dcl_project_import
      (strcat
"YWt6Aw . . .")))) << this odcl "strings" go here.

I havn't had any problems importing the Forms this way - it simply rocks!  A true AutoLISP application: one .fas / .vlx file for the Lisp code and the form code!  Hope this helps.

author=Kerry Brown link=topic=42.msg163#msg163 date=1187147474 wrote:
... also. I'm getting errors when loading and unloading the odcl.

There are several problems here. The default project key name stored in the project is "ListTest", so calling (dcl_Project_Load "ListTest_ODCL.lsp") a second time causes an error because of a design flaw. When no project key is specified in the call to (dcl_Project_Load), it should open the project file and get the default key, *then* check whether that project is already loaded with the default key, and return no error if it is. Instead, the code is looking for a project with a key equal to the filename base ("ListTest_ODCL" in this case), and upon not finding one with that key, *then* trying to load the project file and failing because of a name collision.

The other problem is that the code passes the filename instead of the project key name to (dcl_project_unload), which results in failure to unload the project.  The argument should be the project key as specified when the project was loaded (or as defined in the project file if none was speified). In this case, changing the code to (dcl_Project_Unload "ListTest") will resolve that problem.

In addition, there is a superfluous call to (dcl_unload_dialog) that should not be there.

Thank you for the correction, Owen.  I think I have caught these now in my current project.  Thanks again for everyone's help on this one.