Hi, > > In lines 1944 and 1977 of dlls/comctl32/comctl32undoc.c the value > > "0x7FFF" is used to check for the boundary of a 32 bit integer. However, > > there should be used MAX_INT instead.
> I somehow doubt that this function will ever encounter an INT greater > than MAX_INT... :) you're of course right here. > Anyway, I agree that the current behaviour looks at least suspicious. > It was implemented by Dimi Paun in 2002 > (http://www.winehq.com/hypermail/wine-patches/2002/10/0313.html). > > However, it seems it was or is just hiding another bug - I did some > testing on Win95, Win98 and Win2k3 and I can't reproduce that behaviour > - lists with >0x8000 elements seem to work just fine. > > And since those functions are fairly generic and documented for several > years now it's quite possible that third-party apps use them for arrays > with more than 0x8000 elements... > > > By the way: Looking at current MSDN, DPA and DSA looks rather documented > > than "undoc" :-) > > Right (they were undocumented for a long time though). Well, the "insert"-function uses the value 0x7fff as a flag to the "set"-function (to set a pointer at the end of the list). So i guess, what was actually meant is to check on equality to MAX_INT. However, this is used from treeview.c. Where i encountered the problem inserting more than 0x7fff entries. Sascha
