Sign in to follow this  
Followers 0
PaulIA

ListView LVN_COLUMNCLICK

6 posts in this topic

This is in regards to the post that I made yesterday about a problem with the ListView controls in AutoIt.

While doing some research for Auto3Lib, I created a ListView with CreateWindowEx and found that when I clicked on the header of the ListView, the program would crash. After some further research today, I found that if I captured the LVN_COLUMNCLICK notification messages that are sent from the ListView, the problem goes away.

I'm guessing that AutoIt looks for the LVN_COLUMNCLICK notification messages so that it can implement the GUICtrlRegisterListViewSort callback function (or something similar). Anyway, I had a couple of questions about this:

1. I would not have expected a crash because I created the ListView with CreateWindowEx instead of GUICtrlCreateListView. I would have expected that AutoIt would check to see if it was the creator of the ListView and bypass whatever is causing the crash. Would the current behavior be considered a bug?

2. If this is not a bug, is there any way (short of capturing the LVN_COLUMNCLICK notification) of using a ListView control created outside of GUICtrlCreateListView? For example, is there something that I can do during the creation of the control to make it compatible with the way GUICtrlCreateListView works?

Before anybody lights me up, yes I know the simple answer is just to use GUICtrlCreateListView. That's not the point. I'm just curious as to why the ListViews created by AutoIt exhibit this behavior.

If anyone can shed some light on this, I would appreciate it.

-Paul


Auto3Lib: A library of over 1200 functions for AutoIt

Share this post


Link to post
Share on other sites



IMO, it's a bug. If AutoIt didn't handle the message, it should return what the documentation says (probably calling DefWindowProc()). And from the sounds of things, AutoIt should not and can not handle the message because the HWND does not correspond to a control created via AutoIt's GUI API.

So my vote is this is definitely a bug.

Share this post


Link to post
Share on other sites

You cannot expect AutoIt can catch all impact of using such external call.

Anyway it is easy to avoid this crash in this case so I will add this to next beta. ;)

Share this post


Link to post
Share on other sites

to Valik.

I think AutoIt cannot fight with all situation created with this kind of extension call

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

You cannot expect AutoIt can catch all impact of using such external call.

Why not? I do. If the message isn't handled, meaning AutoIt doesn't recognize the control, then AutoIt needs to treat it like it does all other unhandled messages. It should not just blindly assume the control is valid and try to act on it.

to Valik.

I think AutoIt cannot fight with all situation created with this kind of extension call

It can if the code is written right. Edited by Valik

Share this post


Link to post
Share on other sites

Why not? I do. If the message isn't handled, meaning AutoIt doesn't recognize the control, then AutoIt needs to treat it like it does all other unhandled messages. It should not just blindly assume the control is valid and try to act on it.

It can if the code is written right.

I understand your point but we will see what is the next hole ...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0