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.
I hope you have arisen from your carb and suds induced stupor. For me i added some weekend hikes and maybe managed to burn 1/10 of the calories consumed... long way to go towards knocking off hibernation / covid reserves
I have tested the new rev... (i already had the proper .dll loaded), now the leftpanel is docked/slammed as far to the left as possible, so no joy to be found yet. Clicking reset cols does place it in the correct position. Let me know if a trace would help. Not a rush on this as it's going to be an inhouse utility.
What would be the most helpful is if I could just ATE direct to that program, which would allow me to step through the logic in action.
Second best would be a trace with XTREE and XDEBUG set.
The fact that it resets properly when you do the reset column operation seems like a hopeful sign, and also an indication that it's somehow tied to the previously saved settings rather than the specifications (which makes it harder to reproduce).
Might not be much help. I was only able to capture xtree trace as xdebug seemed to be filtering off my mouse clicks and not transferring the exitcodes back to the program. Program is in limp mode i would need to tighten it up before you wasted your time connecting. The first display is correct.. remaining clicks are all bad except the last one where i click back on the main panel. Perhaps i have other xtrctl settings that are not optimized... not sure.
WARNING: this is a "very beta" version for unrelated reasons, with the most obvious one being that PDFX is broken (due to an update in progress). So only use it for in-house testing. I tweaked the threshold between going with the control's recommended splitter position and the one we manually calculate, and also added some relevant traces (set the XTREE trace flag).
Ok not sure what results you were expecting.. but same issue persists, however with a new anamoly of missing entire row data in the clicked on panels. Clicking reset cols brings everything back. The initial trace includes xtree and xdebug, then i turned off xdebug and clicked a new panel... not sure that helps or not.
Something fishy here. We should see traces that look like this:
Code
34 13:47:22 <XTRA5:c6f> Splitter opt pos: 445, tree width: 1167
Does your About box show a Release Date of 20-Nov-2021?
I'm wondering whether there was some mix-up in the upload or the download. But just to be sure, I've just recompiled it (release date now shows 30-Nov) and changed the link slightly (adding an 'a'), so let's give it one more try: ash-6.5.1709.0a-w32c-upd.zip
Also, can you confirm your xtr.leftpanewidth and xtr.leftpanecols values? (They don't show in the trace).
This is pretty baffling. The About box looks right, but if you have leftpanecols > 0 and leftpanewidth = 0 then it should be calling the routine to calculate the pane position, in which case you should get the splitter traces.
Aside from when you load the tree, another way to force that calculation would be with Control+ or Control- to adjust the font size.
Just to be sure about those leftpane values, I've posted yet another version which will display them (but it requires the XTREE and XDEBUG traces)...
Since that trace is already present in your trace log (without the leftsplit suffix), we should be able to confirm definitely whether you have the right exe and/or right values. If that doesn't get us anywhere, we may have to revise setting up a direct connection for me to be able step through it.
Agreed the wild goose chase might not be the best way to triage this... in the meantime here is the xtree/xdebug trace. Seems there are some newer messages here. Also, hitting ctrl+/- does recalculate the display correctly adding the panel back.
Ok, we've confirmed that you have the latest version, and that you have leftpanecols=9 and leftpanewidth=0. Also, the trace suggests that XTREE thinks that those 9 columns on the left have a combined width of 0???? What I'd like to see is the trace of your Control+ operation (which you say fixes the problem).
That would make sense right? Since the panel is slammed as far to the left as possible... Unfortunately i can't give you xdebug as it seems to grab all the program inputs... so here is xtree trace after hitting ctrl/-
There are a couple of mysteries here - one is why the initial auto-positioned splitter bar is so far to the right (1065 out of a total tree width of 1231, compared to the eventual position at 388), and why when we manually try to recalculate where it should go, all the columns are marked as invisible and thus zero width.
I'm not sure it makes sense to keep digging deeper into this rabbit hole, but I guess there is no harm in adding a fail-safe to avoid extreme positions. Feel free to try this one...
OK now the splitter is way out to the right. It seems like it is taking the hidden cols into consideration in the panel calculation. Perhaps it's just not going to work if you hide a column to the left of the split. We do agree on one thing we aren't getting anywhere... i will wait until i have a prototype for you to play with or you can create on your side. Moving on for now.
For what it's worth, I added a new alternative/workaround for this problem of optimizing the position of the splitter. As of 6.5.1720.0, you can set XTR.LEFTPANEWIDTH = -2 to force XTREE to use it's own logic for estimating the optimum position (instead of using the control's internal logic if you set XTR.LEFTPANEWIDTH = 0). It's now available for testing in this beta version...
Hi, The initial position of the split bar is something that I stop bothering a long ago because never was able to have full control of it, but now that you brought it up, I revisited one of my problematic XTREEs and here is my diagnostic.
1. Using xtr.leftpanewidth = 0 On the first CREATE, the split bar is not correct but after REFRESH, that also uses XTROP'CREATE, the split bar goes to the correct position. (in picture 1, the red arrow should point to an XTREE with the split bar in the right position but it got truncated, consider picture #3 to ilustrate the result after the REFRESH) 2. Using the new xtr.leftpanewidth = -2 Neither on the first CREATE nor after REFRESH, the split bar goes to the right postion, it's always in the wrong place. 3. Defining Dspwid to each column on the left pane and assigning the sum of them to xtr.leftpanewidth The split bar is always on the right position.
NOTE: Both columns have explicit Dspwid, 9 and 12 respectively.
I believe that any logic to calculate this automatically is very difficult considering all possible combinations for font size, resolution and other settings for display. According the documentation: If zero, then XTREE will try to determine the optimum width by adding up the optimum display widths of the initially visible rows.
Wouldn't it be the case to sum the Dspwid of the columns when explicitely defined?
Anyway, many thanks to bring this up because, now I have a method to make it work.
Last edited by Jorge Tavares - UmZero; 01 Sep 2209:58 AM.
Thanks for the detailed feedback, even if it isn't all positive. To answer your last question: yes, that seems very sensible (i.e. why not at least check to see if the columns to the left of the splitter all have defined Dspwid values, and if so, use them?) This latest patch (for LEFTPANEWIDTH = -2) was put in at the last minute and I didn't really give it as much thought as it probably deserves. The one concern I have about automatically using the Dspwid values (if available) is that I'm not sure what happens when there is "special space" on the far left for the purpose of multi-level indicators or item icons, which I don't think get included in the Dspwid for the first column because they technically aren't part of that column, yet they would need to be taken into account. In theory the built-in optimization should handle that (if it only worked!). And I'm not sure if the -2 workaround does or not.
I redid the LEFTPANEWIDTH = -2 logic to fix a couple of problems in 6.5.1720.1. There are still cases, particularly involving SHOWROWHDR, where it seems to come up a bit short, but it definitely seems improved from the prior version ...
Definitely improved and, also, I agree that it looks tight with the limit of the right most column from the left panel, maybe a few extra pixels could make it breath.
Then again, maybe we need to go back to the very beginning of this thread (where Steve first wondered about the possibility of a fudge factor a add a few more pixels!) On the other hand, given the long circular path this has taken us on, do we dare?
