ATE 6.5.1621.1

I've had reported issue with keyboard based row selection. I've linked to a video to display this. FYI, I had to play the AVI with Windows Media Player as the Win 10 video app doesn't have the correct Codec.

When the dialog with the XTREE is launched it looks like focus is on row #1 (it always has been previously) because it is highlighted in blue, but when you look more closely you can see that row #2 actually has the selection frame. If I just click enter there the second row is selected. The video also shows that moving the selection down with the keyboard down-arrow results in the row below the one I stopped at being the one actually selected.

http://www.mediafire.com/file/2dnl1lvwdxuea6z/ATE_6.5_XTREE_wrong_row_selected.avi

P.S. This worked in previous ATE version 6.4.1547.6

Interesting. I'll investigate and get back to you.

I was unable to reproduce this in any of my test programs, but I have posted a possible fix:

ash-6.5.1626.1-w32-upd.zip

Just before turning control over the user, it makes certain that the "caret" (the dotted line current item indicator) agrees with the current selection. That seems like a harmless refinement, although would only apply to single-selection mode.

If that doesn't fix it, the next step would be to activate the XTREE and XDEBUG traces and send them to me.

That didn't fix it. Still the same behavior

Here's the ATE ashlog file with XTREE and XDEBUG
https://send.firefox.com/download/f8cffed1f2/#VtdHl14bQiyNlfh3Mv_6GA

The initial version of the patch didn't do anything for multi-select trees, which it appears your is. So I've posted a revised version:

ash-6.5.1626.1-w32-upd.zip

(Same version # as before; make sure you delete your existing copies first to avoid any confusion.)

If it still has the problem, can you repeat the trace but this time after loading the tree, just wait two seconds and hit ENTER, which, if I understand correctly, will select the 2nd item rather than the first. The down-arrow operation is probably not relevant since the moving of the selection bar and caret are handled internally for that operation, and presumably both are just being incremented. Since the problem seems to manifest at the start of the XTROP_RESELECT, just hitting ENTER at that point should be sufficient.

No change

Here's the updated log
https://send.firefox.com/download/6ec582634c/#Myy2Si-CKY3WHlB-NA_6hw

I give up. At this point I think one of the following would be the most efficient way to proceed:

1. Provide me a way to run the program from ATE remotely.

2. Provide me a portable sample that I can run here illustrates the problem (or best yet, find one that already exists in the 908,21 samples).

3. Narrow it down a bit more to when it started happening. (There have been a lot of updates to XTREE since 6.4.1547.6.)

I'll let you connect remotely, but I won't be able to do that until tomorrow.

Just so we're clear, that log was only on the ATE side. Do you think the server-side would help?

That's fine. I don't think the server side is relevant. Somehow the selection and caret are getting out of sync, but I can't see where it is sense that patch reset the caret at every place I could think of that affected the selection.

Does the problem happen if you click on another row? Or when reentering the tree with targetrow>1? Or is it only when you start with no selections and targetrow = 0?

I'll be emailing connection info shortly.

Ok, let's try again with:

ash-6.5.1626.2-w32-upd.zip

It appears to have been a long-standing bug, but one that was masked in most cases, including all case where sorting and/or dragdrop was enabled. (In those cases, there is a separate logical-to-physical row index.) The bug was causing the non-indexed case to be confused with another case, which almost always would have caused the "smart" row lookup to fail and fall back to the "dumb" version. But in this case, it so happened that column 0 had numbers that looked just like those in the row index, except they were off by one.

The ashw32.exe file in this .zip still has the bug, but it's modefied date is 1/29/2018 3:15pm, and

SHA-1: 0AD3A6C4D1B5B88B12906688AA33188DB8C7D9F8

Is that correct?

Oops, that's the same file as before. It's supposed to be 6.5.1626.2. (I copied the link from above and failed to update it.) Should be ok now (although make sure the file has the right name in case your browser cache fails to update!)

Much Better. Solves the problem as far as I can tell.

I'm going to leave it in BETA for another day or two while I test out an unrelated potential new feature that allows filtering of the rows while loading them (possibly useful for eliminating the need to maintain two sets of arrays when using XTREE as a device for displaying a subset of records from a larger set). I'm not yet sure if it really works properly or if it is particularly useful.

Also, FWIW, in the meantime, there was a another patch, unrelated to either of the above:

ash-6.5.1626.3-w32-upd.zip
ash-6.5.1626.3-w32c-upd.zip
ash65notes.txt

In the course of further testing, I found another related bug which is fixed in 6.5.1627.0 along with an unrelated new feature. I've moved it out of BETA back into the regular distribution directory where it will be available immediately for manual updating, and within a few days for automated updating.

ash-6.5.1627.0-w32-upd.zip
ash-6.5.1627.0-w32c-upd.zip
ash65notes.txt

Thanks for the heads up