Good day -

I am having an issue with the latest v of ATE: 1726.0 (installed last week). I have a grid that when i rt-click opens an option list. I use XTR'XROW to determine the row selected. This version is reporting row 1 every time. In an odd circumstance i hit the "reset columns" option, then tried the rt-click selection and it reported the CORRECT row. I couldn't figure out why it all of a sudden worked and traced it back to the reset columns.

My other PC running 1709 is working fine, so somehere in between it broke. They are both connecting to the same back-end linux server ver 1696.0

Not gonna lie - all this xtree development gives me reason for concern and apparently for good reason.

Awaiting marching orders...

Can you give me a little clarification on exactly how the right-click leads to the options list? Does it trigger an exit and then the application does something to generate the list based on the XTR'XROW? (Perhaps the actual coldef would be the easiest to supply and the most useful for identifying the issue. Note that if not easy to extract from your source code, you can generate it in the trace window by activating the XTREE and XDEBUG traces.)

It's just a "PopupMenu=" loaded into coldef

It doesn't matter if i have focus on the row first or not, the result is always 1. In other words i don't think its related to rt-clicking on a "target" row that is different than the current row. I can plug some debug traces in if it helps.

So this may be something:

Older ATE reports this when i click on row 2:

15 13:57:52 <TELNET:45e4> XTREE exit: rtncde: 0, extcod: -10010 (-10010), xrow/col=2,13, trow/col=2,13, xvalid=0, navcod/mask=0x0/0xffffff80, selrow=2, t/l idx=0,0, edit=0x0, icc=0

New ATE:

4 14:00:50 <TELNET:45e4> XTREE exit: rtncde: 0, extcod: -10010 (-10010), xrow/col=1,12[1], trow/col=2,12, xvalid=0, navcod/mask=0x0/0xffffff80, selrow=1, t/l idx=0,0, edit=0x0, icc=0, filt=0


Notice the values of xrow for both? Now perhaps i have something coded incorrectly which i am willing to fix but a definite differnce in behaviour.

It sounds like you are displaying a PopupMenu, and then selecting from it something that causes XTREE to exit, and that's where you're seeing XROW=1?
The XTRA2 sample program should in theory be able to illustrate that, but I'm not seeing the problem there. I suggest at least activating the XTREE trace, which should spit out a few lines for the context menu, and then another few for the exit.

Yes correct. did u notice my previous post?

Sorry, overlapping posts. The primary addition to the "XTREE exit" trace message was to add the display row in [brackets], so xrow/col=1,12[1] means physical row 1, physical column 12, display row 1.

A few more questions:

1) Are you getting that same row,col output regardless of which row you click? Or is it just an off-by-one issue?

2) The trace doesn't show anything relating to the context menu, so it's hard to tell whether you are just double-clicking to exit, or selecting something from a context menu which then triggers the -10010 exitcode. Do you get the same results regardless of which method you exit from.

3) The selrow=1 is supposed to indicate the row that the selection bar is on. You said it didn't matter, but is that also stuck on 1, regardless of where the selection bar actually is?

1) Yes same result.

2) Sorry - I have sent an updated trace (see below). I did the rt-click from row 6. (i was already on row6 visually but more than likely xtree had no idea and thought i was still on row 1) Notice the context here says row=6?

3) RIght - again i think xtree just "thinks" its still on row 1 since nothing has occured to change the internal count. Since row 1 is just the initial "focus" row, it hasnt updated.

24 14:58:19 <TELNET:45e4> XTREE: checking contextmenu row=6 (150), col=13 (598), px=1, bPcklst=1
25 14:58:19 <TELNET:45e4> XTREE: processing contextmenu: row=6, col=13, px=0
26 14:58:27 <TELNET:45e4> ProcessKBDClick: %VK_xF10010% (mask:1)
27 14:58:27 <TELNET:45e4> XTREE pckexit
28 14:58:27 <TELNET:45e4> XTREE exit: rtncde: 0, extcod: -10010 (-10010), xrow/col=1,13[1], trow/col=6,13, xvalid=0, navcod/mask=0x0/0xffffff80, selrow=1, t/l idx=0,0, edit=0x0, icc=0, filt=0
29 14:58:27 <TELNET:45e4> XtrOpt[c]: Ansary shortened from 3090 to 5 bytes (0 segments) using diff

I see that the target row is 6 which is correct, but apparently xrow was also updated in the past. Not sure this is new behavour, an xtree glitch or something in my program i was getting away with until now.

Is this an editable tree? When you way you were "already on row 6 visually", did you mean that the mouse was hovering over row 6 but cell 1,13 was currently selected for editing?

This seems like the situation alluded to in the xinfo doc, where you have an established editing context (row 1, col 13) and then activate a context menu from another row. If you have cell validation enabled, that creates the possibility of two exitcodes, one for the cell being exited (which should be identified by xrow,xcol as 1,13), and the new 'target' cell (where you activated the context menu from.) And as you can see, the targetrow being returned is in fact row 6. So even without cell validation, one could argue that the current behavior is the most correct, and the most informative, telling you exactly what happened, i.e. the user had the focus on row 1 but then right-clicked on row 6 and triggered an exitcode from the context menu. Note that the situation isn't unique to context menus - any situation where a click produces an exit potentially involves a distinction between the xrow (where the focus was prior to the click) and where the click occurs.

I'm able to reproduce both behaviors in the XTRA2 and XTRA5 sample programs. In the first case, (XTRA2, not editable), the xrow and targetrow are the same (where the context menu was launched). In the second case (XTRA5, editable) xrow returns the location of the cell that had the focus before the right click, and targetrow returns the location of the click.

Unfortunately this is a bit of a gray area, and I'll admit that in the process of dealing with a related issue the behavior might have changed slightly. But it seems more like a fix than a bug. How difficult would it be to just adjust your code to consider the targetrow instead of the xrow?

What was that in the old book? If the eye offends thee... pluck it out?? Or was that cutoff the offending limb?

I am OK with adjusting this program. I neglected to say "repair" as it was in perfectly fine working order! Oddly this is not an editable grid HOWEVER the editable flag was set for some reason. When removed its now squealing about needing editable for TSEI types yet i havnt been able to locate the offending column. Is there something in debug that will pinpoint the bad coldef? (perhaps this is why I "punted" before and just set the editable flag)

Oh its the Filter Option... that's why it has to be editable:

X'COLDEF += "2~1~Filter~H0UE#~~"

So yeah i'll update the logic to grab the "xtr'targetrow"

Fair enough! Can we agree then to call both changes as "refinements" rather than bug fixes?

Deal!

More than likely this was a "fix" in ashell at some point to not confuse the original row with the newly selected row. I am just hopeful i was more careful coding other grids!

Revisiting this thread - different scenario:

Row 1 has focus. I am sitting on an editable combo field. I change the value. I then click on row 4. This generates an exitcode of -48. However, XTR'XROW AND XTR'TARGETROW are BOTH 4! How is the program supposed to ascertain that ROW1 is the value that needs to be updated when both return a 4?

Same issue as above 1726 reports a XTR'XROW=4. 1709 Reports XTR'XROW=1.

This is a new grid I am coding so I can work with the toolbox but this makes we wonder how any grid would "know" what fields is edited if XTR'XROW is now = TARGETROW.

Clearly I am missing something!

I have narrowed this down when the XTF2_AUTOFILTER is active. Or perhaps its more related to the X2'FLAGS switch i am not sure. What i do know is activating the autofilter causes xtree to return xrow and targetrow to be equal...

Reviewing some other programs that "work" i am not mixing editable and filter in the same grid. Seems very likely that these 2 options do not play well together.

Anyone else have this working? Perhaps i have an incorrect switch set.

This is indeed tricky to pin down as it is at least somewhat timing dependent. (A single click ends up triggering multiple event messages that don't necessarily arrive in a set order, forcing the tree to use timers to gather them up and then try to sort them out.) And because there are so many variation (flags, tree configurations, environmental considerations, etc.) it's hard to offer definitive statements without really being able to dig into the details.

I often use the test program XTRA5 which seems to support the main options you're talking about (combo editing, validation, filtering, ...). But my efforts to reproduce this here have been unsuccessful. Here's specifically what I tried (maybe you can repeat the test there). I activated conditional validation, combo boxes and auto filtering...

Although the program displays its own messages in the system message window, I also activated the XTREE trace option which provides more detail.
The program starts in editing m ode on the first Description. I clicked the down arrow and selected another description from the list. Then I clicked on the Description column 2 rows down, which triggered the exit sequence. A slew of trace messages get spit out...

The most interesting one is that last one shown above, which identifies the xrow/col (exit cell) of 1,4 and the trow/tcol (target cell) of 3,4.
That's what we want here, I think. If you get different results with the same sequence of clicks, then maybe we can drill further down to other things that may be different between our environments. Or maybe you discover that you can cause the problem with a slightly different set of click events.

I'm virtually always testing with the latest version, which is 1735.3. I'm not aware of any recent changes affecting this, but XTREE is subject to a fair amount of tinkering, so it always helps to identify the exact version just to be sure.

Alternatively, if you can arrange to allow me to ATE in to your machine to run the test from here, then I can have access to my full development/debug environment, which is almost always the most efficient way to cut through all the superfluous details and get to essence of the problem.

The problem seems to be more random than that - i replaced X2'FLAGS with X'FLAGS in XTREE call, and the returned values of XTR'XROW are still un-reliable. Sometimes they are correct, sometimes they are same as TARGETROW. It seems that when there is only a single editable field in the grid that it doesn't know what row its on... simply arowing up and down confuses it...

OR could this be it... If I click on the editable box first on a row it doesnt report back the correct focus row.... hmmm... what a CF.

Let me see if I can reproduce in XTRA5...

As far as version i get it... i cant push out updates like windows does ever other night...

I can verify if the issue exists in a prior version and whether subsequent updates affected it, but I need to know exactly which version we're dealing with.

No luck with XTRA5 since the row #s are not obvious from the grid display.

I seem to be narrowing the issue down.

See if you can follow this recipe:

Focus on row 1. Click the combo and change the field.
Click on row 4 in a NON-EDITABLE area.
Generates -48 with xrow=1 and targetrow=4. Correct.

Then click on the combo and change it.
Click on row 8 in a NON-EDITABLE area
Generates -48 with xrow=8 and targetrow=8 <<< it has lost the fact that the last row was 4 for some reason.

Even the above scenario is random. What is apparent to me is that clicking on a non-editable area of a row FIRST, then clicking the combo and changing it - xtree seems to have lost the focus row number it is on. Clicking on a non-editable field doesnt cause xtree to change its internal row counter until it needs to, and in some cases just clicking on the editable combo on that row doesnt properly return the current row. I can reproduce this fairly easily. You may come back and say well try the new version which i can understand, but what i wouldn't understand is when it went bad, and what versions were good and bad. Perhaps we will never know the answer, just like the licks to a tootsie pop center.

This is however a serious bug that will cause erroneous results to be stored back to the grid. I am considering abandoning editable combo altoegeher and just trapping a request and handing the data on my own.

PS: Versions listed above.

I can also confirm that turning on xtree and xdebug in the trace actually changes the behaviour... thats unsettling.

I cant paste the debug message since it seems to "fix" the issue but here is proof of a scenario:

EXITCODE=[48], XTR'XROW=[8], XTR'TARGETROW=[11] <<< Focus Row 8, clicked on Row 11
XCLAIM.STATUS=[G44.82 ], WORK=[1 ]
EXITCODE=[48], XTR'XROW=[26], XTR'TARGETROW=[26] <<< Still on Row 11 clicked on row 26 but for some reason xtree lost its original focus.
XCLAIM.STATUS=[G44.82 ], WORK=[4 ]

Good news, bad news --

I can reproduce this is 1726.0 (which I'm guessing is the version you're using. Your post above send the versions are "listed above", but the only versions I see in the thread above that are several months ago when it began in March.) I can't reproduce it in the current version. There have been 9 sets of internal edits to the XTREE code since 1726. None of them explicitly targeted this issue, so it's not obvious which might have been responsible for the fix. But it does seem unavoidable that correcting the situation now is going to require a change to your version, and if so, it might as well be to something closer to the current version. Not that 1726 is that ancient, but by the same token, you shouldn't be too worried about updating to it.

However, I will re-iterate my standard advice to everyone using the 6.5 development version -- that they do abide by two guidelines: 1) always run it in-house for awhile before releasing it to customers, and 2) stay reasonably up to date so that in a situation like this, you can take advantage of a bug fix update without having to get past the psychological hurdle of worrying about the 100 other things that changed in the last several months. (Another side benefit of staying reasonably up to date is that you often "miss out" on bugs that got fixed before you discovered them.

p.s. It is definitely unsettling, but not surprising that turning on the traces (in particular XDEBUG), alters the behavior when the behavior in question is intimately connected to window events and timing, since the trace messages themselves generate a bunch of window events and alter the timing. The only workaround would be to activate the traces internally, either in the miame.ini or via SET or something along those lines, and disable the message window.

Thanks for the reply - yes 1726.0 is my current "r&d working version".

Thanks for the confirmation, glad to know that i wasn't going crazy (in this case), not that in any way diminishes that in fact I am.

Ok so you opened pandoras box here - hasn't there been chatter for YEARS about rounding 6.5 up to the next standard version? I can assume that this will/should be a topic of the fall meetings. I am in favor of an endgame to 6.5 so we can test it and start rolling it out. (Steve and have my proxy vote!! )

1640+ supports autofilter. Is there a mimimum and maximum version you recommend for the field?

Indeed we have been talking about rolling the versions over for years now. There just doesn't seem to ever be a good time or cutoff that everyone agrees on. At one extreme we have people on 6.4 who are not going to be happy when tell them that it is no longer the supported stable version. And at the other extreme are those who are enjoying being on the cutting edge, and don't want to go through a several-weeks-long lock-down period while we do the roll over. And in the middle are those who have decided to make a particular 6.5.xxxx version their own standard. (Inevitably the new stable version will have to go through considerable field testing given the lengthy period that has elapsed, so ironically it won't be very stable itself during that period.) Plus it's a lot of administrative work. So it has been too easy to put off.

The Conference would present a good opportunity to finally make a decision. But I'll have to warn you that we have no ethical regulations to prevent Steve from being subjected to intense in-person lobbying, complete with drinking, dining and who-knows-what other entertainment prior to any vote. So the only way to be sure that your vote gets cast properly would be to do it in person!

Unfortunately, I do not have a minimum and maximum version recommendation for "the field" (by which I assume you mean end users). It largely depends on which features you use. Just to take AutoFilter as an example, it was make VASTLY faster in edit 1724, along with several other refinements between there and 1729 when the new CBX filter type was added. But not everyone will notice the difference. Or the new gridmap collection type -- if I was going to plan to stick on one version for the next couple of years, I'd want to have that data structure available. But as with most new features, there have been a number of feature and bug fix updates, included a set of three new related dot functions likely to be released in 6.5.1736.0 tomorrow. I think you have to peruse the 6.5 Development Notes to find a point at which none of the subsequent features or bug fixes matter to you.

Understood

Thanks and yeah, i thought that 1726.0 that i had been stress testing for a few months now "was" that version!

As an aside, just because we goto 6.6 stable doesn't mean that 6.4 ceases to become stable. It just means that no more bug fixes will be made to it. I think our release time on 6.4, I might have still been on windows XP! So it would be hard to complain about 6.4 being locked down. Agreed - no good time to lock 6.5 down, so pick a date! As soon as its locked down the next day there will already be requests for 6.7... and so on and so on... at least you can focus bug fixes in 6.6 and get it stable. And to your point, it will take some time to vet out 6.6.

OK so it gets more confusing. In the 65dev/ate/ dist area the latest version *IS* 1726.0 which is exactly the version i am using.

The latest update in the /bin-win folder is 1730.1 which incidentally is the only version after 1726.

There was no indication in the release notes that I read indicating the above xtr'row glitch (but it could have been broke and repaired w/o discovery).

So FYI 1730.1 seems to have repaired the xtr'row anamoly. If you need / recommend a higher rev please vet and release to at least the /dist area. We are already on an "unstable" version (your words), i don't want to push it to "unstable/beta".

Admittedly this is confusing. The latest patches (and corresponding dev notes) always go into the /temphold/beta directory. Theoretically after a certain amount of time with no changes, they'll get moved to the /dev65/ directories, and eventually show up in the Check For Updates link. The idea is to allow each developer to find their own happy spot between the latest (features, bugs and bug fixes) and what has been out there for awhile (presumably 'stable'). I suggest reviewing the ash65notes.txt to see if there is anything in there since 1730.1 that seems relevant to you. If so, then you can access those versions directly from that /beta/ location. Otherwise go with 1730.1 (or .2). But as long as you're doing development in house, I don't see much downside to using the very latest version. Not only does it help everyone else (by exercising the code), it helps you (by exposing your own app to A-Shell code that it will almost certainly get exposed to in the future.)

I don't disagree - however the "happy spot" for our company is not using bleeding edge tech that requires potentially hundreds of users to update their ATE installation. That doesn't mean that we don't use new tech but the ROI has to be there for us to have to force wide-spread upgrades. The downside of staying on beta versions inhouse is that i can be lured into a feature/option w/o realizing that there is no backward compatibility so we need to be mindful of that.