Good morning,

Is there any secret setting to make the left side button, to expand/collapse XTREE levels, bigger?
It always look too small compared with the text and, even zooming or scaling, it still stays small.

Is this only me being picky or, at least, some of my dear fellows have the same feeling?

Hey Jorge,

I use this feature in many xtrees. I find the size to be perfect for our application. Perhaps it's because you are running 4096x2024 resolution!

It also looks well when pairing with the xtr'show3d switch. Try it for fun and see what you think.

I've been wondering about that problem myself. It's clearly connected somehow with higher res screens, although I'm not sure if it crept in during a Windows update, an XTREE update, a hardware update, or changes in A-Shell for dpm support. But when I compare A-Shell's XTREE grids to generic samples from the control supplier, the buttons are the same. However, there are some alternative button styles that we could implement, although I'm not completely sure they're that much of an improvement. But you decide...

"Wide" buttons...


"Large" buttons ...


"Standard" buttons ...


Note that these examples all use the default font which is quite small, making the buttons look less out of place. I think one part of the problem with XTREE is that it's easy to make the fonts larger, but that scaling doesn't affect the buttons.

You're right, it becomes worst when the font is bigger.
In my XTREE menu, using the default font, which is small, those buttons are also small but proportional to the text.
When the user CTRL+Scroll to make it bigger, those buttons look weird.
In both cases, they don't work fine in touch screens and, even with the mouse, it's not that easy to click and work on the first attempt.

If not complicated, I would like to give a chance to your "large buttons" besides I don't like the yellow arrows inside.
No hurry.

Thanks

Right - I didn't like those yellow arrows either. There are a couple of other options we can explore. One is to use another embedded feature (requiring some new flags to expose) referred to as "plus/minus" buttons, which is yet another bitmap that can be used to identify and toggle the item levels. (It seemed weird and redundant to me to have both, but...) The other is to come up with custom bitmaps for the buttons. This image shows an example of both ...


The problem with the bitmaps is that they also must have a fixed size. So it's hard to make them adjust to the font size. But perhaps we could come up with an alternate set that was, say, twice as big as the standard ones but otherwise the same style, and allow the app to just select it via a one bit option in one of the XTRCTL fields?

Version 6.5.1706.0 attempts to increase the size of the expand/collapse buttons and checkboxes/radiobuttons based on various heuristics. Here's an example ...



You can download the beta copy from:

ash-6.5.1706.0-w32-upd.zip
ash-6.5.1706.0-w32c-upd.zip
ash65notes.txt

I'm not seeing any change on this, do I have to use or setup anything to wake up that "heurisitc guy" :-)

Before we deconstruct the heuristics, let's try a couple of things:

1. ash-6.5.1706.1-w32c-upd.zip (closes a loophole that I overlooked in the 1706.0 version)

2. Activate the XTREE and XDEBUG traces and look for a line something like this:


3. See what effect adding or subtracting the -dpm command line switch has.

Movie for Sunday, if nothing better to watch

It seems that something got broken when handling this feature in splitted XTREEs

Below is the corresponding log for the error illustrated in the first image for the expected XTREE in the second image.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
26-Set-21 08:48:05 [UMZPOWER:02-2]<SCCTLPROJ:25a41> Loading SftTree_IX86_U_75
26-Set-21 08:48:05 [UMZPOWER:02-2]<SCCTLPROJ:25a41> XTREE begin: ctlno=-1, op=0, flags=2014a221,0, tgt=0,0, t/l idx=0,0, navcd/msk=0x0/0x0, pos=4000,2000, par=1, max=0, icc=0, hwe=0
26-Set-21 08:48:05 [UMZPOWER:02-2]<SCCTLPROJ:25a41> xtree: auto-assign ctlid 0
26-Set-21 08:48:05 [UMZPOWER:02-2]<SCCTLPROJ:25a41> xtree in: op=0, ctlno=0, active=0, par=1, trow/col=0,0, iaclick=0,0, lastxc=0, max=0
26-Set-21 08:48:05 [UMZPOWER:02-2]<SCCTLPROJ:25a41> xtree: loading split functions
26-Set-21 08:48:05 [UMZPOWER:02-2]<SCCTLPROJ:25a41> GetProcAddress: SftTreeSplit_LoadGDIPlusImageFromResource (err #127)
26-Set-21 08:48:05 [UMZPOWER:02-2]<SCCTLPROJ:25a41> Impossível localizar o procedimento especificado.


26-Set-21 08:48:06 [UMZPOWER:02-2]<SCCTLPROJ:25a41> SETFOCUS
26-Set-21 08:48:06 [UMZPOWER:02-2]<SCCTLPROJ:25a41> putting focus back on msgbox (GetProcAddress: SftTreeSplit_LoadGDIPlusImageFromResource (err #127))
26-Set-21 08:48:06 [UMZPOWER:02-2]<SCCTLPROJ:25a41> SETFOCUS
26-Set-21 08:48:06 [UMZPOWER:02-2]<SCCTLPROJ:25a41> putting focus back on msgbox (GetProcAddress: SftTreeSplit_LoadGDIPlusImageFromResource (err #127))
26-Set-21 08:48:06 [UMZPOWER:02-2]<SCCTLPROJ:25a41> !XTREE error loading function pointers (bad DLL version?)
26-Set-21 08:48:06 [UMZPOWER:02-2]<SCCTLPROJ:25a41> XTREE pckexit
-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Let's try that again...

ash-6.5.1706.1-w32-upd.zip
ash-6.5.1706.1-w32c-upd.zip

(Note that the version is still 1706.1 because nothing really changed here other than fixing the library linkage problem.)

Wait!
Apologize, but the bigger button was working fine in some of my programs, but not all, including my main menu what induced in wrong evaluation.
Now I'm searching what is different in the XTREE setup that explains the behavior difference.

Anyway, this last version fixes the error on splitted XTREEs.

I haven't seen that problem, but will admit to having seen cases where the button sizes appear to be getting auto-scaled, or not, based on as-yet-unrecognized factors. (I also run into this problem in apps unrelated to A-Shell, so it's presumably due, more generally, to the mysterious inner workings of the Windows high-resolution scaling logic.)

In your example above, the outer tree on the left is actually a separate instance of A-Shell, correct? Are both instances getting launched with the same -dpm option (i.e. both using it or both not)? Any chance of capturing the XTREE + XDEBUG traces? (It might be necessary to add it temporarily to the miame.ini.)

Oooo came back from Vacation and updated to 6.5.1706.3.. looks good to me.

Thanks for the visual feedback. I wonder how long users have been grumbling about those tiny buttons, or even how many have been affected by it.

im sure the grumbling was never loud enough..

No grumbling here. Our app is not touch screen based.

I guess that's one silver lining to the old-age onset of deafness!