HowWhere does µTorrent keep the column order ?

[chaosblade]

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
[reqver] 1.1.5.0

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

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

//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)
[column_start]
1
9 IF_NO_TEXT="Done!"
7 IF_NO_TEXT="0"
0
8 IF_NO_TEXT="0"
0
3
0
6
5
2
0
0
4 SKIP_ENTRY_IF_TEXT="Finished" SKIP_ENTRY_IF_TEXT="Paused" SKIP_ENTRY_IF_TEXT="Queued Seed"
[column_end]

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

[vurlix]

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.

[chaosblade]

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.

[ludde]

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?

[chaosblade]

Yeah, It does. I'll report back when i got results

Thanks for the quick help, Both of you

[chaosblade]

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 -

44,60,60,60,65,65,120,60,40,49,118,118,118,119,58.

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

[jewelisheaven]

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.

[chaosblade]

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.

[jewelisheaven]

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

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

[chaosblade]

I read a triplet of bytes, and only address the ones i need. So adding new columns in the same structure is simply a matter of updating my list of columns that match the context-menu list.