Is there any fudge factor I missed for XTree's XTF_SPLIT as 90% time it just needs to be manual widened a few pixels to see the whole field.. For example see the "Total Balance" on the attached screen shot, by default the last few digits are cut off this column and it needs to be manually made wider. Thanks.
PS: I did report a problem in split grids however, columns after the split, if you click on them they do not indicate the sort order. Have you noticed that in your application?
I guess we know now who has the guts out there. (Not that I'm trying to challenge anyone to post more complaints!)
I do suspect that Steve (or is it Jorge in disguise?) has the right theory - the "+" is messing with the optimization logic. Let me see if I can work around that.
The other issue, with the sort indicator not appearing on the right side of a split tree remains out of my hands. I'm hoping for an update of the control to resolve that eventually.
Maybe I had comment that problem when, suddenly, from the dark a deer crossed our way and confused Frank Just to say that, indeed, this topic could be posted by me before but, I'm pickier than my customers and since nobody claimed about this, I just saved our time. But I'm very happy that Rene spotted it and, even more important, that Ty found it simple to solve.
Everybody happy
Last edited by Jorge Tavares - UmZero; 14 May 2007:58 PM.
There are few pros and cons to the tweaks to 6.5.1680.8...
The Pro is it sorted the last column size in the left hand Split, the Con nothing shows at all in the right-hand split until I right-click and select 'Reset Columns'
I didn't see this happening in my test program XTRA5[908,21]. I'm guessing it is somehow connected with the use of the XTR'USRCFG option. Does the problem go away if you change your TreeID ?
This actually reminds me that I've see a variation of this problem before, when adding columns to an existing tree whose saved parameters don't include the new column, causing the new column to initially appear invisible. We may need some logic to automatically detect when the saved configuration should be ignored due to changes in the tree. But the change here (slight widening of the left panel) was too slight to have such a big effect, so I'm not sure if we're dealing with two separate issues.
Your should be able to emulated this by logging on to our Test system at Caliq via VPN and typing "JACK" at the DOT Prompt, Then Click Continue button..
When adding or changing columns in an existing xtree when usrfcg is also active, you should change the xtree ID so it doesn't fall into this situation.
With you there Frank, in this example we have not changed the program just the Ashell version, But if changing the xtreeID solved the issue I would happy done that.
Does Jorge win a Microsabio Anniversary Pen for the smallest pickiest observation and creating the the longest of BBS threads along with using Jacks precious time to solved it.
Jack - any traction on this? I don't want to leave it just to bring it up 10 revs from now. To repeat, my grid repopulates every 5 seconds, when it does, the rows show expanded, then collapsed on their own, like when it repaints it opens the rows, then closes them. I don't know if Steve or Jorge or Herman is having the same issue or even give 2 shakes but it was better before the change. Or i can change some switches on this end to see if it would prevent this behaviour.
Sorry, got distracted. It seemed like part of the problem with the calculation was that the expand/collapse state hadn't been initialized, so I changed the order. Didn't notice the refresh problem (in theory redraw should be disabled at that point), but I'll see if that can be backed out.
I can confirm that the row open/collapse flash is gone. I can also confirm that the grid appears to be making adjustments for the [+] addition and removal. ie. no more empty pixel space before the split.
Just a word of caution, i had to reset the columns for the adjustment to take hold. Not a problem just an FYI.
Stephen, are you referring to the sort direction indicator? Or the actual sorting of the column? I can confirm it will sort just wont indicate what its doing, which is indeed confusing to the user.
It looks like the underlying problem in the control was fixed. But for some reason I haven't yet determined, the fix isn't percolating up into the A-Shell implementation. (If I recall correctly, the idea of having a sort indicator was something we convinced them to add, but at some point perhaps prior to that, A-Shell came up with it's own version the indicators.) Let me investigate further and see if I can't resolve it.
It seems that the underlying problem was fixed, but only partially. The control supports two sort modes, dubbed automatic and manual. The indicators now work in the automatic mode, but that mode only supports the primary sort indicator. (Whereas in the manual mode, we supported up to 3 columns at a time with sort indicators.) Still, that's better than nothing. Aside from that, there seems to be some mysterious variability in the actual indicators used, with a tiny triangle used in some cases and something more like a v or ^ in other cases. (For such a tiny detail, there seems to be a lot of complexity surrounding it.) Anyway, if you want to give it a try ...
I hate to tear back into this oozing wound but alas i am having an issue getting the split panel to look correct...
Scenario: I have a screen with a tab control with 10 panels each with an XTREE using a split option. The coldef is the same for all panels. Looks great on panel 1, however when i switch panels, the split doesn't align properly. (there is a wide gap). HOWEVER if i click reset-columns it fixes the display. But clicking off this panel and back in doesn't keep the display fixed.
I know this has been reported before, it's not a fudge factor, its more of like a whole willy wonka factory of emtpy space. Here are the specifics, the leftpanelcols=9. On the first panel everything looks OK. When i switch panels i am filtering the data AND hiding some of the initial columns that were displayed in panel 1.
Question - leftpanelcols should include hidden columns correct?
I have turned off the treeid just to make sure it doesnt revert back to some older display setting.
I am use XTROP_CREATE each time and turned off NOREDRAW just to be sure...
I tested a few more things and it seems that adding a hidden column to the mix confuses the leftpanel logic... i guess i could just not display these on the other grids but the hiding them seemed like a more logical approach.
Just wanted to get a confirm/deny as to what is the best approach to get this to work.
