1. Win32Lib bug, or just me?
- Posted by Aiereis Jul 28, 2008
- 1037 views
- Last edited Jul 29, 2008
Using Win32Lib 0.70.4a.
I want to override the default style flags for a listview control. With other controls, say a plain list, I can do this by passing a sequence rather than an atom for the style flags. With a listview, doing this crashes, with an error because procedure handleLV() expects an atom rather than a sequence for its flags. In createEx(), I found this at line 13660 (according to EditA):
elsif lControl = ListView then
handleLV(id,or_bits(classStyle[lControl],styleFlags),lvcol)
end if
I'm thinking the variable "styleFlags" shouldn't be passed, but rather "flags", which is an atom that createEx() earlier makes by ORing together the atoms in the sequence of style flags. Am I right about this, or am I doing something wrong? Is there some other way to override the default style flags for a listview? If I pass an atom, Win32Lib just adds it to the defaults.
Thanks!
2. Re: Win32Lib bug, or just me?
- Posted by Mike777 Jul 29, 2008
- 1032 views
Using Win32Lib 0.70.4a.
I want to override the default style flags for a listview control. With other controls, say a plain list, I can do this by passing a sequence rather than an atom for the style flags. With a listview, doing this crashes, with an error because procedure handleLV() expects an atom rather than a sequence for its flags. In createEx(), I found this at line 13660 (according to EditA):
elsif lControl = ListView then
handleLV(id,or_bits(classStyle[lControl],styleFlags),lvcol)
end if
I'm thinking the variable "styleFlags" shouldn't be passed, but rather "flags", which is an atom that createEx() earlier makes by ORing together the atoms in the sequence of style flags. Am I right about this, or am I doing something wrong? Is there some other way to override the default style flags for a listview? If I pass an atom, Win32Lib just adds it to the defaults.
Thanks!
Here's an example of code that you can use (generated the Judith Evans' Enhanced IDE, in case you are interested):
atom lvMask integer lvOk lvMask = w32or_all({LVS_EX_UNDERLINEHOT}) lvOk = sendMessage(lsvSelectEmployees,LVM_SETEXTENDEDLISTVIEWSTYLE,lvMask,lvMask)
Mike777
3. Re: Win32Lib bug, or just me?
- Posted by CChris Jul 29, 2008
- 955 views
Using Win32Lib 0.70.4a.
I want to override the default style flags for a listview control. With other controls, say a plain list, I can do this by passing a sequence rather than an atom for the style flags. With a listview, doing this crashes, with an error because procedure handleLV() expects an atom rather than a sequence for its flags. In createEx(), I found this at line 13660 (according to EditA):
elsif lControl = ListView then
handleLV(id,or_bits(classStyle[lControl],styleFlags),lvcol)
end if
I'm thinking the variable "styleFlags" shouldn't be passed, but rather "flags", which is an atom that createEx() earlier makes by ORing together the atoms in the sequence of style flags. Am I right about this, or am I doing something wrong? Is there some other way to override the default style flags for a listview? If I pass an atom, Win32Lib just adds it to the defaults.
Thanks!
I'll check this tonight. However, setLVStyle() is the preferred way to set ListView styles after the call to createEx().
I'll reply tomorrow to confirm whether the change you suggest, or similar, is something to do. In tht case, it will go in my working copy, and thus in the next release, whenever it takes place.
CChris
4. Re: Win32Lib bug, or just me?
- Posted by Aiereis Jul 29, 2008
- 923 views
- Last edited Jul 30, 2008
Using Win32Lib 0.70.4a.
I want to override the default style flags for a listview control. With other controls, say a plain list, I can do this by passing a sequence rather than an atom for the style flags. With a listview, doing this crashes, with an error because procedure handleLV() expects an atom rather than a sequence for its flags. In createEx(), I found this at line 13660 (according to EditA):
elsif lControl = ListView then
handleLV(id,or_bits(classStyle[lControl],styleFlags),lvcol)
end if
I'm thinking the variable "styleFlags" shouldn't be passed, but rather "flags", which is an atom that createEx() earlier makes by ORing together the atoms in the sequence of style flags. Am I right about this, or am I doing something wrong? Is there some other way to override the default style flags for a listview? If I pass an atom, Win32Lib just adds it to the defaults.
Thanks!
I'll check this tonight. However, setLVStyle() is the preferred way to set ListView styles after the call to createEx().
I'll reply tomorrow to confirm whether the change you suggest, or similar, is something to do. In tht case, it will go in my working copy, and thus in the next release, whenever it takes place.
CChris
Thanks CChris (and Mike777). As I said, I don't know if it's a bug or not; I just thought it was strange that I could pass a sequence of flags for most controls but not for listview (and I didn't see anything about this in the documentation). I haven't tried Mike777's suggestion yet, but setLVStyle() won't, as far as I can see, let me do what I want, which is to have the WS_BORDER style not be set on the listviewwin32lib sets this by default. I'll try and see if the IDE has a way of doing this. Thanks again.
5. Re: Win32Lib bug, or just me?
- Posted by Mike777 Jul 30, 2008
- 940 views
Using Win32Lib 0.70.4a.
I want to override the default style flags for a listview control. With other controls, say a plain list, I can do this by passing a sequence rather than an atom for the style flags. With a listview, doing this crashes, with an error because procedure handleLV() expects an atom rather than a sequence for its flags. In createEx(), I found this at line 13660 (according to EditA):
elsif lControl = ListView then
handleLV(id,or_bits(classStyle[lControl],styleFlags),lvcol)
end if
I'm thinking the variable "styleFlags" shouldn't be passed, but rather "flags", which is an atom that createEx() earlier makes by ORing together the atoms in the sequence of style flags. Am I right about this, or am I doing something wrong? Is there some other way to override the default style flags for a listview? If I pass an atom, Win32Lib just adds it to the defaults.
Thanks!
I'll check this tonight. However, setLVStyle() is the preferred way to set ListView styles after the call to createEx().
I'll reply tomorrow to confirm whether the change you suggest, or similar, is something to do. In tht case, it will go in my working copy, and thus in the next release, whenever it takes place.
CChris
Thanks CChris (and Mike777). As I said, I don't know if it's a bug or not; I just thought it was strange that I could pass a sequence of flags for most controls but not for listview (and I didn't see anything about this in the documentation). I haven't tried Mike777's suggestion yet, but setLVStyle() won't, as far as I can see, let me do what I want, which is to have the WS_BORDER style not be set on the listviewwin32lib sets this by default. I'll try and see if the IDE has a way of doing this. Thanks again.
You might need to use setLVStyle to set it to zeroes and then do an all new "or".
Mike
6. Re: Win32Lib bug, or just me?
- Posted by CChris Jul 30, 2008
- 928 views
Using Win32Lib 0.70.4a.
I want to override the default style flags for a listview control. With other controls, say a plain list, I can do this by passing a sequence rather than an atom for the style flags. With a listview, doing this crashes, with an error because procedure handleLV() expects an atom rather than a sequence for its flags. In createEx(), I found this at line 13660 (according to EditA):
elsif lControl = ListView then
handleLV(id,or_bits(classStyle[lControl],styleFlags),lvcol)
end if
I'm thinking the variable "styleFlags" shouldn't be passed, but rather "flags", which is an atom that createEx() earlier makes by ORing together the atoms in the sequence of style flags. Am I right about this, or am I doing something wrong? Is there some other way to override the default style flags for a listview? If I pass an atom, Win32Lib just adds it to the defaults.
Thanks!
I'll check this tonight. However, setLVStyle() is the preferred way to set ListView styles after the call to createEx().
I'll reply tomorrow to confirm whether the change you suggest, or similar, is something to do. In tht case, it will go in my working copy, and thus in the next release, whenever it takes place.
CChris
Thanks CChris (and Mike777). As I said, I don't know if it's a bug or not; I just thought it was strange that I could pass a sequence of flags for most controls but not for listview (and I didn't see anything about this in the documentation). I haven't tried Mike777's suggestion yet, but setLVStyle() won't, as far as I can see, let me do what I want, which is to have the WS_BORDER style not be set on the listviewwin32lib sets this by default. I'll try and see if the IDE has a way of doing this. Thanks again.
You might need to use setLVStyle to set it to zeroes and then do an all new "or".
Mike
I didn't try yet, but chaning
handleLV(id,or_bits(classStyle[lControl],styleFlags),lvcol)
to
handleLV(id,w32or_all(classStyle[lControl] & styleFlags),lvcol)
should kkeep you going. If tthe fix is right, I'll include it.
CChris
7. Re: Win32Lib bug, or just me?
- Posted by Aiereis Jul 30, 2008
- 925 views
That change seems to work, thanks!
As a side note, ORing the defaults from classStyle[lControl] into the parameter passed to handleLV(), in addition to styleFlags, doesn't actually seem to matter, as handleLV() only checks for the flags LVS_REPORT and LVS_SORTDESCENDING, which are not set by default. Of course, not knowing much about how Win32Lib works, I could be wrong about this.
8. Re: Win32Lib bug, or just me?
- Posted by CChris Jul 31, 2008
- 923 views
That change seems to work, thanks!
As a side note, ORing the defaults from classStyle[lControl] into the parameter passed to handleLV(), in addition to styleFlags, doesn't actually seem to matter, as handleLV() only checks for the flags LVS_REPORT and LVS_SORTDESCENDING, which are not set by default. Of course, not knowing much about how Win32Lib works, I could be wrong about this.
True, but default styles are not immutable. This is why, as a matter of precaution, I didn't optimise this call when splitting off the special processing of ListViews. As the cost is negligible, the benefits of keepiing seemed higher than those of trimming it.
Also keep in mind that classDefaukt() can change the default attributes for a class.
At any rate, I 'll include the fix in my working copy, so it will be on the next release.
CChris
