Unexpected parameter type limit of _GUICtrlTreeView_GetItemParam

[Sponge Jhan]

When $hWnd is not of type HWND (and $hItem is not 0), _GUICtrlTreeView_GetItemParam immediately tries to convert $hItem from an ID to a handle via GUICtrlGetHandle.
If $hItem is a handle got by other _GUICtrlTreeView_* functions, _GUICtrlTreeView_GetItemParam fails.
Converting the ID of the treeview into HWND via GUICtrlGetHandle before calling it may avoid this problem.
However, I think it is meaningless to treat $hItem as an AutoIt internally defined ID, because the internal ID is exactly the same value stored in the lParam field of the item.
Thus, I classified this ticket as a bug, and $hItem should be treated as a handle anyway.

[Jpm]

Can yo more precise on what should be change where(?).
the _GuiCtrlTreeview_* must work on ID when AutoIt builtin are used to create the item
and Hwnd when created by _GUICtrlTreeView_* are used

[Sponge Jhan]

Replying to Jpm:

Can yo more precise on what should be change where(?).
the _GuiCtrlTreeview_* must work on ID when AutoIt builtin are used to create the item
and Hwnd when created by _GUICtrlTreeView_* are used

Because treeview and items both may created by AutoIt internal functions or _GUICtrlTreeView_* functions, $hWnd and $hItem may be a handle or an ID.
To supporting all 2*2=4 cases, _GUICtrlTreeView_* functions should consider their conversions independently.
For example, _GUICtrlTreeView_GetFirstChild uses two if statements to adjust $hWnd and $hItem.
However, _GUICtrlTreeView_GetItemParam returns False when $hWnd is an ID and $hItem is not an ID.
I think it can ignore GUICtrlGetHandle failure, like the implementation in in _GUICtrlTreeView_GetItemHandle.
By the way, _GUICtrlTreeView_GetParentParam has the same structure of code and the same problem.

[Jpm]

please just post a repro script to illustrate the "bug"

[Jpm]

I close as no info where provided