Annoying TreeControl_OnItemExpanding bug

OK I've been chasing this bug for months now.
The prob. is 99% of the time the code run fine.
Only about once or twice a week across 30 users does the bug pop up.

I keep getting this invalid argument type for my tree control (see attached pic).
I've added this debug code:


(defun c:MainTMaCAD_TreeControl_OnItemExpanding (ItemText Key /  x n1 tpkey rValue PathList CurrectKey ParentKey SubFolders KidKey ParKey)
  (if DEBUG
    (progn
    (princ "\nRunning TreeControl_OnItemExpanding... ")
  (princ "\nItemText: ")
      (princ ItemText)     
  (princ "\nKey: ")
      (princ Key)  ;<--- Crashing here
    )
  );_ if

(if (dcl_Tree_IsItemExpanded TMaCAD_MainTMaCAD_TreeControl Key) ;<--- Crashing here, if DEBUG is off
.......


The output I get is:

Running TreeControl_OnItemExpanding...
ItemText: 13081
Key: 2.1868e+009; error: ADS request error


When the code is working 99% of the time I get, something like this:

Running TreeControl_OnItemExpanding...
ItemText: 13081
Key: 833029504


What is wrong with the key? Is this a memory addressing issue?
OpenDCL Runtime [7.0.1.2]

Is the form's Event Invoke property set to Synchronous or Asynchronous?

The form's is: Synchronous
The Tree control is: Asynchronous

Asynchronous calls require the event handler arguments to be passed as strings, so I suspect that has something to do with it. I'll have a look at the code to see if I can figure out how your observed behavior might happen.

I'm pretty sure the problem you see is due to sufficiently large handle values causing the argument to become a floating point value, which is then rejected as a valid handle when using it to call back into OpenDCL. The problem should now be fixed in the next build.

Thanks Owen.
I guess I should have posted earlier.
I've been trying to narrow this down to something in my code. ;-)
What is making the handles values to become large?
The number of items in the tree?

A handle is essentially a pointer to something in memory, so it just depends where the memory happens to get allocated. I doubt that the number of items has any noticeable effect.