Tree/Tab Expansion Memory and Focus

[jacky]

Update:I just updated to latest...went looking for the INI settings...found this:

Code: Select all

TreeItemDistY=-1
lCatalogItemDistY=0
lListItemDistY=0

The 2nd and 3rd lines show as having a 1 prefix char in XY preview and here but in hex it's a 6C

Yeah I saw that too.. allthough, Hex 6C, yeah it's only a lower L (not one)
I'm guessing that's the internal name that Don also used for the INI values by mistake...

BTW, is there a good reason why the user tweakables like these couldn't be at either the start or end of all 'settings' instead of in the middle?

Probably some internal order, but don't you search for them?? I know first thing I do when editing my INI is Ctrl+F and enter (part of) the value name, so it doesn't really matter where it is located...
And, I belive it makes more sense to have values ordered by "functions" like I'm guessing they might be, than by anything else.

Because it makes sense, having user-editable value first doesn't really (to me at least). If only, because one could edit them all, and who says tomorrow some won't get a user interface somewhere, then what? Move them in the INI? Better to have them always at the same place, according to what they do IMO...

[admin]

Update:I just updated to latest...went looking for the INI settings...found this:

Code: Select all

TreeItemDistY=-1
lCatalogItemDistY=0
lListItemDistY=0

The 2nd and 3rd lines show as having a 1 prefix char in XY preview and here but in hex it's a 6C

It's a small L and it's a bug. Will be removed in the next version. Which means: your values are reset to 0. BETA world...

Other questions:

The INI file is pretty chaotic anyway, because it is impossible to order such a large set of options in a semantically meaningful way within just one dimension (top to bottom list) and some sections. Also, as you know, it is growing all the time Still I try my best to put some order into it. But a separate sections for hidden options is not necessary and not useful. You have to know the keyname anyway to find it, so your editor's Find command wil do the job for you. Also, hidden (hard-core) settings might surface in later versions. And for other than hardcore usage, the order of keys is totally irrelevant.

Row height in pixels depends on font type and size. So an absolute value would be useless here.

[peterbonge]

But I (we?) think it would be nice if this value would also affect the double-click-scrolling.

As I stated right before your "hello mr admin" post, I'm convinced having dbl-click work differently from tab-switch is a good thing, even though I use it very rarely...now maybe the (ugly) solution to this would be another INI setting?
...

I'm not sure... The goal of both ways (double-clicking or changing the tabs) is the same: The active folder shall scroll to a certain position. Therefore one setting should be enough (in my opinion). But 2 settings would also be OK.

[jacky]

I'm not sure... The goal of both ways (double-clicking or changing the tabs) is the same: The active folder shall scroll to a certain position. Therefore one setting should be enough (in my opinion). But 2 settings would also be OK.

I wouldn't say that the goal of both ways is the same actually. Autoscroll when changing location/tab aims to put the node in view if it wasn't visible already, but if it was then the Tree does not move.
Using the dbl-click though, it will move & put the node where it should no matter if it was already visible or not. Those do not behave the same and do not serves the same purpose, IMO. Besides, as mentionned before, for consistancy sake both dbl-click to put focused item into view on Tree & List should behave the same I think.

[Creat]

The INI file is pretty chaotic anyway, because it is impossible to order such a large set of options in a semantically meaningful way within just one dimension (top to bottom list) and some sections.

Well, about that... Have you considered going from an ini file to a xml file to save the settings? My guess is, you're using Get/SetPrivateString (or however the good ol' standard ini/registry function was called again, haven't used it in a while) so you could just switch to xml for now, not changing anything. But you could - if you ever find the time - introduce sublevels and such, including a category telling us, it's child settings only exist in the file.
Just as an idea, might make the whole thing more manageable (and readeable for those of us who do that ).

bye
Creat

[admin]

The INI file is pretty chaotic anyway, because it is impossible to order such a large set of options in a semantically meaningful way within just one dimension (top to bottom list) and some sections.

Well, about that... Have you considered going from an ini file to a xml file to save the settings? My guess is, you're using Get/SetPrivateString (or however the good ol' standard ini/registry function was called again, haven't used it in a while) so you could just switch to xml for now, not changing anything. But you could - if you ever find the time - introduce sublevels and such, including a category telling us, it's child settings only exist in the file.
Just as an idea, might make the whole thing more manageable (and readeable for those of us who do that ).

XML is slow. All my decisions are based on things like speed, usability, intuitiveness... but on the surface, not in the backyard. If you do manual INI-editing you go the hard way and cannot expect a lot of comfort there.
BTW: I'm using GetPrivateProfileStringW for reading, and my own functions for writing (WritePrivateProfileString is too slow when a virus scanner is active). I might replace GetPrivateProfileStringW in a later version, too. Who knows, maybe MS stops supporting it in VistaPopista 2

[Creat]

Yea that was the Function (Syscall) I meant.

Actually in my test XML was quite fast, certainly faster than ini files though not as fast as real databases of course. But the fact that you can handle it like an object structure usualy makes things a lot easier.
The speed probably depends on what you use to access it (library or whatever).
And as for usability and intuitiveness xml certainly wins over ini. And according to my experience also with speed

anyway, it was just a thought

bye
Creat

[admin]

Thanks! I like it! I set mine to 4...Only suggestion would be to put a short comment line before it in INI to make locating it a tad easier, as it's buried in a long list...yes, one can do a search, but tagging it might be nice...just a thought.

Thought about it again, and: I did it. Including a very brief explanation/usage instruction.

[peterbonge]

What's up with my wish? It seems that it went down here...

Some time ago there was at least one build where doubleclicking on an empty tree area scrolled the active folder to the 3rd position (and not to the top). I really liked this very much. Please bring it back. Maybe as an INI setting "TreeRowForDClickScroll".

[admin]

What's up with my wish? It seems that it went down here...

You are alone.

[peterbonge]

What's up with my wish? It seems that it went down here...

You are alone.

[admin]

What's up with my wish? It seems that it went down here...

You are alone.

There will be a shortcut...

[peterbonge]

What's up with my wish? It seems that it went down here...

You are alone.

There will be a shortcut...

I don't understand this. I'm speaking of a setting, not a function. How will you add a shortcut for this?

[admin]

What's up with my wish? It seems that it went down here...

You are alone.

There will be a shortcut...

I don't understand this. I'm speaking of a setting, not a function. How will you add a shortcut for this?

Scriptable Hotkeys! This particular case might be a little extreme, but it would work like this. Each SH (Scriptable Hotkeys) points to a user-defined function which consists of two parts, an action and a parameter (modifier, variable...). Here are 3 examples, the first would be your wish:

Code: Select all

Action -----------------------------  Parameter
scroll tree selection to row [...]    3
goto                                  C:\
open                                  (path to any app/file)

You can map any key(s) onto these user-defined functions

[peterbonge]

Scriptable Hotkeys! This particular case might be a little extreme, but it would work like this. Each SH (Scriptable Hotkeys) points to a user-defined function which consists of two parts, an action and a parameter (modifier, variable...). Here are 3 examples, the first would be your wish:

Code: Select all

Action -----------------------------  Parameter
scroll tree selection to row [...]    3
goto                                  C:\
open                                  (path to any app/file)

You can map any key(s) onto these user-defined functions

That all sounds great. But I don't see how this helps me. Will I be able to use a user-function when doubleclicking on an empty tree area? Otherwise this wouldn't help me (in this case).