Jump to content

HowWhere does µTorrent keep the column order ?


Recommended Posts

The title of this thread kinda says it all. I had a look in the settings.dat file, but binary is bit problemetic to pick-off from.

The reason im asking this is, as ive said before, i use a certain mIRC addon to show µTorrent status in it, and it uses config files like this one:

//GTSdll Configuration file
//for the µTorrent v1.1 Client
[client] µTorrent v1.1
//required GTSdll-version

[title] µTorrent v1.1 Default Configuration
[author] chaosblade
//Identifier used by mIRC to recognize BitTorrent
[ident] BTInfo

[appclass] µTorrent4823DF041B09
[apptitle] µTorrent*1.1
[findsub] #32770
[findsub] SysListView32

//used columns, you can skip useles columns here,
//and change the order of returned columns
//NOTE!!: Seperator for each column parameter is Chr(160) ( ) (alt + 255 or alt + 0160 on num-pad)
9 IF_NO_TEXT="Done!"
7 IF_NO_TEXT="0"
8 IF_NO_TEXT="0"

As you see, its very column-order specific. I wish to make a simple program to generate configs according to the currently saved columns and their order, So if you could point me in the right direction, It will be most appriciated.

I wonder if im asking for too much here, hmm ;)

Link to comment
Share on other sites

Look in settings.dat, to the right of lv_files28:, there there's 3 bytes per column, and you're interested in every 3rd byte.... the upper bit is 1 if the column is disabled, the lower 7 bits contain the "order" of the columns on the screen. Hope this makes sense to you.

Link to comment
Share on other sites

The order of columns is saved 15 times (the number of columns) ?

I'm pretty sure i misunderstood something. So, right after the lv_files28: part, i should have 3 bytes for each column, 15*3 bytes. For each set of 3 bytes, the 3rd byte contains an indication of it being disabled on the MSB, and the rest save the order.

Link to comment
Share on other sites

Hi, when you extract every 3rd bytes, lets say you end up with the list (in hex) (this is an example of a list with only 7 columns, to make my example simpler)

0: 1: 2: 3: 4: 5: 6:

01 02 83 05 84 06 00

This means that column 2 and 4 are hidden.

And on the screen you will see the columns in this order:

6 0 1 3 5

hope it makes more sense?

Link to comment
Share on other sites

Im kinda annoyed i still haven't got this working, but im really not sure what went wrong. I did read the settings file as binary until the point i found the binary representation of "lv_files28:" - After that i read 45 bytes (15 columns totally in µTorrent * 3 Bytes per column) and what i get is a bit odd..

Here's the list of every 3rd byte from those 45 bytes that follow the lv_files28: string -


It doesnt make sense to me.. I wonder what im missing here.

Link to comment
Share on other sites

  • 2 years later...

For all of the LV_* keys, the first two bytes are the primary and secondary sort order. The high bit is set for descending (reverse, aka down arrow) order, and the rest of the byte is the column number. The rest of the key comprises of 3 bytes per column: First Byte = order, high bit = disabled; Second Byte = width; Third Byte is NULL to keep columns aligned and unmangled.

I'm rubbish at coding, but when new columns are added I imagine one COULD simply add 3 NULL bytes where the new column occurs in the context menu list but that would make the rest of the list wonky, and I'm not positive if one can actually resize a 0 width column, so a better idea would be to add 3 NULL bytes with a hex editor (or use Ultima's BFE) and then overwrite them with the number of the new column (in hex) then a width of "0x40" which is ~ 4 characters @ 12 pica, and then a NULL.

Link to comment
Share on other sites

  • 3 months later...

Thanks for the help so far, jewlisheaven. My 1.8 settings.dat file seems to match your description, aside from one oddity - the first column has the value of 01 instead of NULL for its third byte.

I'll see about repairing my code again now for 1.8 - Since it did work perfectly with previous versions.

Link to comment
Share on other sites

Yep that's what I mentioned previously. I'm thinking the devs might know which property is specified with that extra bit, due to something about listviews.. but if you're just parsing the columns, start at char(2) of the lv_overview string :D

Were you keeping it future-proof by using the NULL as delimiters?

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...