Hi Jack,

Would it be reasonable to make working the H and HH option in the Property sheets?
In this case it would not hide the column but the row.

Thanks and wish you a lovely weekend

Hi Jorge,

It certainly seems reasonable. One could argue that in the case of Property Sheets, adding H is no easier than simply removing the 'column' entirely. But that wouldn't be reasonable expect for the HH workaround, and if we're going to support HH, the H logic would be part of that. So consider it on the list. Maybe by earlier next week. First I have to burn off some of yesterday's excess turkey consumption and then attend to that lovely weekend...

Jack

I'm fully recovered from Thanksgiving, but may have spoken too soon on how reasonable this is. It wouldn't be difficult to implement for non-editable fields, but if the field is editable, removing it from the property sheet would cause the answer and data arrays to get out of sync with the display. I guess it could be handled via the autofilter mechanism, but currently autofilter is incompatible with property sheets, and implementing it would be complicated. Another approach would be to add a hidden column to cross-reference the display columns with the physical columns, but again, I'm not sure the extra complexity would make sense, at least not for the simple H case (which is easy enough to handle at app level by just removing the column).

The HH (conditional hidden) case is the one where it would be nice if XTREE just handled it, but the question is: does it make sense to remove an editable column (or property sheet row) from the display just because it doesn't have anything in it (yet)?

If you think H and/or HH support would be useful even if confined to non-editable columns, then I can just add a simple test to ignore it (or generate an error trace) if you try to use the feature with an editable column.

Hi Jack,

I'm glad you survived to Thanksgiving even with difficulty, that means it was absolutely fantastic and full of great food and drinks.

Maybe if I explain the goal will bring light to a possible solution.
These xtrees have around 30+ settings, but most of the time only 4-6 have values and many times just one, that makes it difficult for the user to know which settings are set, to make it worst some of them are checkboxes that don't resize with Scale (maybe an embedded request :-) )

My idea is to add an external button (or a context menu option) to hide every non-valued rows (columns) just to view, not to edit, only when the xtree reverts to the full view beocme editabel again.
I'll be (very) happy with the H option, in fact, the HH option don't makes sense because I would need to remove it when going to edit mode so, it would not save me from a manual loop.

In resume, H only for non-editable xtrees will be perfect.

Thank you

Good, that's what I was hoping. As long as there is no editing (and also no sorting, which currently is impossible with property sheets anyway), then we can just filter out the H and HH items as they are being loaded.

Except I just thought of one more potential complication - selection. If you want to allow the user to select an item in the property sheet, then we still need to maintain an internal hidden column containing the original row numbers so that we can return the correct selected row number.

Good morning,
No, at least on this specific case, there is no need to save the row number.

Thank you

Well, this ended up being more complex than hoped for, due to the fundamental lack of orthogonality between the two dimensions (rows and columns) in the tree. The titles and tooltips, as one example were stored in array buffers that were separate but logically parallel to the columns, which are set up before the row data is processed. Anyway, I think it's working now in 1765.9, provided that the property sheet isn't editable. I'll circle back to deal with that issue in a later update.

ash-7.0.1765.9-w32-upd.zip
ash-7.0.1765.9-w32c-upd.zip
ash70notes.txt

Also, while you're at it, pick up the standalone compiler update for APN ...
compil-7.0.1048-w32.zip

Following the complexity theme here, in the process of adding support for editable property sheets with H and/or HH cformat codes, I discovered (and hopefully fixed) a number of other property-sheet related problems, most of which were probably introduced in 1765.9. Please give the following beta update a workout...

ash-7.0.1766.0-w32-upd.zip
ash-7.0.1766.0-w32c-upd.zip
ash70notes.txt

And here's a sample program (now in the EXLIB repository) ... XTRPSH.BP

Good morning,

I need to investigate this one because loading an XTREE is taking far longer than usual, I'm talking about a nomal XTREE, not a Property xtree.

Well, while here, I decided to take a quick look in ASHLOG and it seems there is some forgoten trace:
10-Dez-24 08:40:25 [UMZPOWER:1D-1]<MAIN:5554> addstring (24) : -
There are countless "addstring" statements and XTREE trace is not enabled.

In my heaviest xtrees the difference is huge, like 40+ seconds to load something that loads in 3 seconds.

Meanwhile, I've looked the Property xtree that triggered all this, which is not heavy and loads fast enough, and it seems that "synch scroll" performs smoothly without so much intermitance scroll-pause-scroll (if you understand :-) ) but there is some problem in the HH feature which I need to investigate what I'm doing because, apparently, it's filtering the correct rows (with values) but only displays the "labels" on the left column and empty "values" on the right column.
Maybe that's related to my first attempt handling the Edit mode to disable/enable according to the HH mode, will get back to this later.

Thank you for all the effort on this.

Mea culpa. I added that trace in an act of desperation while trying to track down a problem that only appeared in the non-debug build. (Good reminder to be extra careful with versions downloaded from the Beta directory!)

I've recompile and re-uploaded them (no version or filename change, but the About box will now show Dec 10 instead of 9) ...

ash-7.0.1766.0-w32-upd.zip
ash-7.0.1766.0-w32c-upd.zip

Another bug found in the above update, fixed in 1766.1 ...

ash-7.0.1766.1-w32-upd.zip
ash-7.0.1766.1-w32c-upd.zip
ash70notes.txt