FWD » Core Development » User Interface

The problem:

There is a feature of existing TREEVIEW implementation in FWD: if a TREEVIEW is navigated with keyboard past the last tree node, the selection jumps to the first tree node. And vice-versa: if a TREEVIEW is navigated with keyboard before the first tree node, the selection jumps to the last tree node.

The TREEVIEW was modeled after the MS Treeview control, hence the TREEVIEW behavior should match that of the control.

At the moment of writing, it is unclear, if this feature exist in original MS Treeview control, so this needs to be discovered using a native MS environment, and we need to assure the TREEVIEW implementation matches that of MS Treeview control in this respect.

Vladimir: We generally don't add random features. Why was the feature there if it is not needed? I'm worried that it is needed in some use case that customer code will hit.

Hynek: Please review.

Greg Shah wrote:

Vladimir: We generally don't add random features. Why was the feature there if it is not needed? I'm worried that it is needed in some use case that customer code will hit.

Hynek: Please review.

This came to my mind either, but I did not found any way to make MS TreeView roll-over. In any case, if we will want to enable this feature, we will need to make it configurable as some FWD extension, that means do change the previous implementation, since neither TREEVIEW OCX, nor TREELIST OCX support this feature.

Eugenie: Could this code have been used in that customer-specific OCX replacement from #3822?

Greg Shah wrote:

Eugenie: Could this code have been used in that customer-specific OCX replacement from #3822?

Do you mean if we have some non-standard customer specific feature of OCX control - can we convert them by the same approach that used for the object discussed in #3822?

Eugenie: Could this code have been used in that customer-specific OCX replacement from #3822?

Do you mean if we have some non-standard customer specific feature of OCX control - can we convert them by the same approach that used for the object discussed in #3822?

No, I'm asking if the code removed in 3821c rev 12882 was inserted originally by you for usage in #3822? Doesn't the replacement widget in #3822 use the TREEVIEW code internally?

Greg Shah wrote:

Eugenie: Could this code have been used in that customer-specific OCX replacement from #3822?

Do you mean if we have some non-standard customer specific feature of OCX control - can we convert them by the same approach that used for the object discussed in #3822?

No, I'm asking if the code removed in 3821c rev 12882 was inserted originally by you for usage in #3822?

No. I did not add this code.

Doesn't the replacement widget in #3822 use the TREEVIEW code internally?

Yes, the new widget acts like TREELIST in all places where it does not need specific processing.

Eugenie Lyzenko wrote:

Doesn't the replacement widget in #3822 use the TREEVIEW code internally?

Yes, the new widget acts like TREELIST in all places where it does not need specific processing.

I think, Eugenie meant no, the FWD implementation in #3822 is based on TREELIST, not on TREEVIEW.

AFAIK, TREEVIEW is not used in this customer project.

Vladimir Tsichevski wrote:

Eugenie Lyzenko wrote:

Doesn't the replacement widget in #3822 use the TREEVIEW code internally?

Yes, the new widget acts like TREELIST in all places where it does not need specific processing.

I think, Eugenie meant no, the FWD implementation in #3822 is based on TREELIST, not on TREEVIEW.

AFAIK, TREEVIEW is not used in this customer project.

Yes, you are right. TREELIST is a different object. Sorry for confusion. The widgets can cross on the common base TreeWidgetBase implementation methods.

Code review 3821c revision 12882. The changes are OK.