Ryan Norton

I can confirm what jay pointed out...

Later builds do use UAC to install into "C:\Program Files" - but you'll need to uninstall first or remove the uninstall registry key manually. If you need more info let me know.

Oh, and as to the icon thing I should state that all we did was literally add the 256x256 png - that is it and causes it by itself.

kokobaroko, if you've interested, here's the latest WINE stuff. 1) Icon in Taskbar notification area (sometimes called the systray) doesn't work with our icon. You can use a resource hacker-type application to easily see what icon formats we provide - but it stopped working since we added a 256x256 compressed vista png icon. 2) WINE doesn't correctly handle WM_PAINT and/or WM_ERASEBKGND from its list controls - I havn't spent hours testing to determine which, but it gets a black background (you can see this if you set it not use emulate XP or higher with the most recent 1.7 beta)

It isn't Firon being lazy - it is intentionally left out of the updates for now. I'm not sure on the exact reasons but it has probably has something to do with the wide scope of the changes in this beta and that we are trying to get it signed so vista people don't get the yellow UAC dialog. If you do use this new beta though autoupdates to future versions should work fine.

Thanks for the report poncho - that is what I expected .

poncho - what Windows version do you have WINE set to emulate?

Thanks for reporting the issues with the taskbar icons and toolbar. The latter should be fixed in upcoming builds already and we are working on the first; kokobaroko - maybe fixing the lowres problem will fix WINE as well... well update when ready .

kokobaroko - I can confirm that it is the icon change that is causing the problem. Evidently Wine must load the wrong icon for the taskbar icon *sigh*.

dabreaka - the livesearch was only in the internal beta; it isn't in the official (2740) one....

The 256x256 icon only works in "large icons" mode and bigger (i.e. there is an "extra large icons"). And no, it isn't for the tray icon :).

Yes, this is official. Everyone, please continue reporting bugs in the Found Bugs forum; we do look at them! Speaking of which, I tried for days to reproduce the upload rate limiting issue some have reported and it worked perfectly every time for me - so could those with that issue please provide more information; as much useful information as possible would be appreciated; thanks!

@Edtech There is already another long thread about the vista program file stuff and this thread does not need any extra posts... EDIT: here http://forum.utorrent.com/viewtopic.php?id=24697

@maidenfan88 Screenshots are always appreciated on gui reports :) Circling the offending part is good too.

@Falcon4 What make/model etc. of a router do you use? EDIT: BTW - don't forget to turn on all of your logging options

(blank I guess )

Sorry for the delay kokoborako > so if you call GetBkColor as a first thing in your app it will always be white under every windows version? and is gray under wine? is that correct? I'm pretty sure - I'll even note a Windows bible with a link From Programming Windows, 5th edition (heck, its even in the sample chapter online - it is page 1001 in my hard copy) http://www.microsoft.com/mspress/books/sampchap/2344.aspx#SampleChapter "The default background color is white." don't think it can get much clearer then that.... > thats weird, because you can see plenty of gray space, but its his code, anyway looks like its going to get fixed Yeah, try to tell him the dialog should resize itself or something if the text is too big - I would think Wine has an internal function or something that does this automatically for its dialogs > why is that little webserver app able to bind the same port to its socket that is allready allocated for utorrent (under XP SP2)? that sure is weird. According to my boss this is standard windows behaviour due to SO_REUSEADDR (that the HTTP server must use I guess) and thus is another Wine "bug" > but the binding just FAILED and it sure is not connected, so you kinda cant call getsockname? Maybe, but then Wine should return failure or something... > Now the difference between wine and M$ is that M$ doesnt modify the sockaddr structure, > and wine zeroes the sin_port if socked is not bound or connected. I zero it before calling the function - I havn't checked if it actually modifies the structure; so either it doesn't modify it and returns success (which is kind of a ..HUH?) or sets the port to 0 and returns success; which shouldn't happen.

I believe the default text background color is always white by default in Windows - thus it appears to be a Wine bug... (I could add a call to set the text background color to transparent but I really don't want to add obvious hacks like that in uTorrent...) Also kokobaroko - the thing where it resets the port to 0 if it is already in use by another app appears to be a Wine bug as well. I've put a workaround in the next uTorrent release but basically getsockname() returns success but either fails to set the port of the passed in struct or sets it to 0 for some reason... Thanks again .

kokobaroko - that is just the standard folder chooser dialog (SHBrowseForFolder), so there are no functions failing; it just would appear that the dialog they bring up is buggy . BTW kokobaroko do you notice that the background color of the caption in the speed wizard is wrong? For example on my darwine it is grey but it should be white (the same as the rest of the top part). Maybe it is specific to darwine. ----- TECH: The problem here is that the default background color of text calls (SetBkColor) is not white as it is on real windows (specified in Programming Windows); instead it appears to be the background color of the window it is drawing to.

@jassethi2003 It won't be in your startup folder - it will be in the HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run subkey. Could you let me know what that says? It is likely you have a setting left over from 1.6.1 or an old 1.7 beta.

For those using the new "graceful_shutdown" there might be a very rare case where it waits indefinately (i.e. never fully shuts down) - if that happens please let us know.

Whenever we consider it stable .

That is awesome! Thanks to kokobaroko and the wine devs .

(the following gets a bit technical) The problem with the right-click on the download/upload on the status bar is that the dwItemSpec member of the NMMOUSE structure wine sends on the status bar's NM_RCLICK event does not contain the expected value. On Windows it is the part number the user clicked on (zero-based index), but Wine sends a number for it that I don't know where it got the value for - i.e. appears the same for several of the status bar parts and sometimes even (randomly?) changes each time. Albiet the MSDN documentation on this point seems somewhat sparse.

FYI about wine-specific combobox issue as well http://forum.utorrent.com/viewtopic.php?pid=250177#p250177