Currently, XTREE returns whatever targetrow/col combination has been clicked either the current XTREE if that was clicked, or another XTREE. There are times when this is useful in doing pre-validation on the other clicked XTREE, but there are times when you don't need to do pre-validation that it complicates keeping the proper context in the XTREE that originally has focus.



Here's an example of this. The left XTREE has a one-to-many relationship with the right XTREE. We're changing the right XTREE contents based on whatever row from the left XTREE is currently selected. If I have focus on the left XTREE, and I click on row #2 in the right XTREE. The left XTREE has returned the targetrow/col related to the click, so now the context of left XTREE is kind of corrupted and I have to trap that it was the other XTREE that was clicked and then reset the left XTREE's targetrow/col to the xrow/col. This isn't that hard to workaround, but it's more code overhead to remember to keep updated if you add more XTREEs to the mix.

Would it be difficult to add a flag that would never return another XTREE's targetrow/col in the current XTREE, just set the targetrow/col to xrow/col on return like this?

I didn't mean to ignore this, just got overtaken by a flurry of other inquiries.

In theory it doesn't sound too difficult to add a flag that forces the returned targetrow/col to match the xrow/xcol. But I'm not sure that the simplification from the application point of view would be that significant. Isn't it just a matter of needing a conditional something like this:

To eliminate that you'd need to define a flag and set it, and XTREE would need to test the flag and have some logic similar to the above.

I'm not saying that's a bad tradeoff, but maybe I need a bit more convincing.

Why not just make XTREE-2 be display only? OR - you know which xtree the user clicked on, just ignore the request if coming from XTREE-2 or display some sort of message.

The right-side XTREE is editable, and if it wasn't active the user couldn't click on a specific row/col and go directly to editing it.

Jack, that's basically what I did in this program.

My reason for asking this is because I'm trying to write code where controls are (at least logically) isolated from one another, so I don't want the left-side XTREE to even know the right-side XTREE exists. It would probably be better to test that the exitcode doesn't match the current XTREE's clickcode, and then reset the targetrow/col.

If I need to, I can just add my own flag to my Code generator XTREE widget, and handle this in the generated dialog code. It just seems like there would be more cases than not that you wouldn't care about knowing the other XTREE's targetrow/col prior to calling it.

To me this is like saying you want xtree to know that "certain" other objects don't exist. (xtree-2 in this case). Why would the second xtree be any different than say a button or icon?

IMHO I think it should be up to the app to determine what's allowed and what's not. Not the clickable object to refuse click events from certain objects.

What if you simplify your model and force the user to click something before allowing access to xtree-2? Keeping it disabled beforehand. Might require extra clicks but might be more straight forward?

My point was not that I want the actual control to not be aware of other controls, but that the code I write to not reference any other controls specifically.

I already typically do this, but in this case I had to reference the other XTREE in my code to keep a click on it from changing the context of the XTREE that originally had focus.

Basing my comments on your original request:

"Would it be difficult to add a flag that would never return another XTREE's targetrow/col in the current XTREE, just set the targetrow/col to xrow/col on return like this?"

My point simply being, in agreement with your last post that your code should keep track of this.

FWIW, I added this feature in 6.1.1409.0:

Thanks for letting me know you added this. I'll try to get it tested before too long. I'm in the middle of figuring out how to best Dockify our applications, so I'm kind of covered up with documentation and container building.