Hi Jack,

This is old, not related to any new release but never posted here because, probably, there are too many details to trace that I was afraid to start the topic.
Today I stumbled on this again but due the relaxing view,I thought I could be lucky and some easy solution could came up so, here is the paradise view and the problem

After exiting the combo cell, some columns in the XTREE are adjusted in their width and on re-entering the combo cell, it go out of alignment.
Maybe you need more details or maybe I'm lucky and you reproduce it on the first shot, please, let me know but no hurry on this, I have the sea waiting for me before the cold beer and the barbecue

Boy, you really know how to elicit sympathy for your terrible situation!!!

In fact, maybe I should just head on down there and help you out with all of those responsibilities?

While I pack my havaianas and a swim suit (or is that even necessary?), I'll ponder the problem. (The edit and combo box controls are entirely independent of the tree control, and rely on some calculation to superimpose them in the right position. So I'm guessing that XTREE doesn't realize that the column widths have been adjusted. If I can get your view out of my head, maybe I'll be able to tinker with the code.)

In the meantime, don't strain yourself!

The havaianas are unecessary extra weight.

Sorry, even without the havaianas I couldn't get past the baggage check (operated by my wife at the front door), so I guess you're stuck dealing with all that scenery without my help.

That's not to say I can't help fix this one little imperfection in the otherwise perfect XTREE view, but so far I haven't been able to come up with a combination to do so. In fact, the logic seems like it should be impervious to changes in column size of position, as there is a function to locate the coordinate of a cell that gets executed just before creating the edit or combo control. I suppose it might be possible that if a lot of things were happening at once, the background thread handling the display updates might get out of sync with the foreground thread calculating the position. But that would be pretty tricky to reproduce. Or to correct.

So if you find yourself getting bored and can't resist getting back to programming, and want to give me any further clues, I'll happily receive them. Is it at all reproducible? Or something that only happens intermittently? If you can make it happen, can you do it with the XTREE trace on? (That might reveal some sequence or parameter that unlocks the door.)

Otherwise, go back to the more important business at hand !

This woul be far easy to understand here, combining the view, warm sea water and all the drinks around, you would easily see those combo going out of sync.
Anyway, yes, this is something that happens all the time so will be easy to apply some traces and test a few different scenarios to observe changes of behavior.
Will be back, thanks.

Hi,
I thought this could be the perfect to-do topic for the pos-Carnival season, just adding some traces and check behavior changes, nothing too much brain consuming, just perfect!
But never imagined that I would solve the problem on my first attempt with a simple change and even without adding a single TRACE.

In my code found the XTF_NOREDRAW moved to right in a comment.
It looked too tempting to remove the comment and did it, ét voilá, problem is gone


Maybe It will be a waste of time to try to understand why the fields move without the XTF_NOREDRAW, but if you think it worths, no problem, I'll follow your directions or open a door for you to test.
Now I have two new problems:
1. Finding if adding the XTF_NOREDRAW will bring new issues that probably were solved removing it
2. Find a new simple to-do topic but probably I've done enough for today and just go take a nap

You've definitely outdone yourself today! Better to ease back into work over a few days, preferably with the aide of a hammock!

In the meantime, I'll ponder how XTF_NOREDRAW could possibly have this effect.