On Wed, Feb 25, 2009 at 2:11 AM, Keith Marshall
> On Wednesday 25 February 2009 07:16:27 Michael James wrote:
>> > What's the source of the new value for 'LVIF_COLUMNS'?
>> > I wasn't able to find the value documented publicly on msdn.
>> The correct value is 0x200,
> On what basis do you assert this? Greg asked, but you didn't answer.
> If the assertion cannot be substantiated by reference to publicly
> accessible and unrestricted sources, e.g. MSDN, then your patch is
> not acceptable, (unless you can demonstrate a method of analytically
> deriving the value, using nothing more than free and open resources).
>> however in the patch I wrote this as
>> 512 to be consistent with your other decimal usage.
> That's fine.
I can understand that you have a cause to be very cautious in this
project. However, in this case that caution seems to be somewhat over
applied. First the method used to obtain the correct value was to
observe my program running in a debugger in both a msvc and a mingw
build. It worked fine in msvc but was crashing in mingw. Ultimately
the reason for this was that the binary value of the flags it has
specified was different.
This news group is a public and free reference and I hereby assert
that it is a fact that the correct value for LVIF_COLUMNS is hex 200,
decimal 512. My program crashes using a different incorrect value when
compiled with MingW but works as expected using the modified value.
A fact can not be copyrighted, and the presentation of this fact is
indefinitely far removed from any possible stylistic or organizational
copyright that could be asserted over a dubious connection to some
vendor's headers. Since the encoding and almost certainly the context
is different I think that would make this use of 512 completely safe.
However, if you are not willing to accept my patch I think it would be
more appropriate to remove the incorrect value from your header
entirely than to allow compilation to succeed but result in an
>> The patch also contains a ChangeLog entry.
> As would be this, *if* you had provided it as free standing text,
> instead of as a diff, embedded within the patch. However, your patch
> isn't in an appropriate format...
> |Index: include/commctrl.h
> |RCS file: /cvs/src/src/winsup/w32api/include/commctrl.h,v
> |retrieving revision 1.66
> |diff -r1.66 commctrl.h
> ...doesn't create a valid patch file; working with CVS, you *must*
> use, (at the absolute least):
> cvs diff -u commctrl.h
> to create a unified diff, with the minimum of three lines each of
> leading and trailing context required by the patch utility.
>> A separate patch I submitted a bit over two weeks ago has some
>> similar ...
> IIRC, that too was incorrectly formatted; (not unified format).
> Please review http://mingw.org/wiki/SubmitPatches (Yes, I know that
> wasn't entirely explicit about keeping the ChangeLog entry separate
> from the diff, although it did imply it; I've emphasised that now).
I will regenerate and resubmit my changes based on your comments and
that SubmitPatches page. Thank you for referencing that. Please
understand that I am just trying to help this community effort and was
not aware of the exact protocols you have in place.