Not getting click notifications from List View Control

[colin glenn]

Creation code:

    CONTROL ADD LISTVIEW, hDlg, %IDLV_FOXLIST, _
        "FoxList", _
        498, 26, 114, 110, _
        %WS_CHILD OR %WS_VISIBLE OR %WS_TABSTOP OR _
        %LVS_REPORT OR %LVS_SHOWSELALWAYS, _
        %WS_EX_CLIENTEDGE OR %WS_EX_LEFT OR %WS_EX_RIGHTSCROLLBAR

LISTVIEW SET STYLE hDlg, %IDLV_FOXLIST, %LVS_EX_FULLROWSELECT _
        OR %LVS_EX_ONECLICKACTIVATE

And while the Full Row Select works, the One Click Activate seems to be doing Hot Tracking, the row the cursor is over is changing font color.

Notify Case Code:

        CASE %WM_NOTIFY
            IF ISTRUE isLoading THEN EXIT FUNCTION
            SELECT CASE CB.NMID
                CASE %IDTV_FOXTREE, %IDTV_IMPORTTREE
                    ' this works, when using the treeview,
                    ' notifies are processed
                CASE %IDLV_FOXLIST
                    LOCAL pnmv AS NM_LISTVIEW POINTER
                    #DEBUG PRINT "Foxlist notify: "& FORMAT$(CB.NMCODE)
                    pnmv = CB.NMHDR
                    SELECT CASE CB.NMCODE
                        CASE %LVN_COLUMNCLICK
                            #DEBUG PRINT "Foxlist Column:"& _
                                FORMAT$(@pnmv.iSubItem) &" clicked"
                        CASE %LVN_ITEMCHANGED
                            #DEBUG PRINT "Foxlist Row:"& _
                                FORMAT$(@pnmv.iSubItem) &":"& _
                                FORMAT$(@pnmv.iSubItem) &" clicked"
                    END SELECT
            END SELECT

I get only three messages from the the $WM_NOTIFY checking;

Foxlist notify: -12 <- on startup.
Foxlist notify: -160 <- on startup.
Foxlist notify: -7 <- somewhere when opening the file and loading the list.

So I am overlooking something, but what?

[Chris Boss]

It is important to read the API docs for each style you use to see how it affects the control.

%LVS_EX_ONECLICKACTIVATE

The PB docs simply say:

"Notification sent on single click"

The API docs explain that this extended style makes the control send the LVN_ITEMACTIVATE message when you click an item. It also enables hot tracking, which means when the cursor is over the item is highlighted, but not selected.

The point being that a single style or extended style for a control may effect the notification messages it generates and their order.

The best way to see how this works, is to write some generic WM_NOTIFY code which simply tracks the notification event values (codes) and to log them in another control, like a text box. You want to see what notification events are generated and in what order, when you act upon a control.

Even the API docs don't always explain this in detail.

By writing a simple event logger program for the control you are learning to use, you can get a better appreciation of how the controls works, its notification events and how styles/extended styles effect or change this.

[Michael Mattias]

The code you are using will not show you all the notifications, it will only show you column clicks (on the header) and state changes.

But you should get a state change when you click on a row. Code, er, hand action not shown.

[Chris Boss]

Listview Event Logger in source code forum

I put together a Listview event logger program which can be found in the source code forum:

http://www.powerbasic.com/support/pbforums/showthread.php?p=310971#post310971

Event loggers are useful when learning how to work with a control and to see how styles effect them and their events. It helps you learn what events are generated and in what order.

Feel free to use the program and modify it to your needs to test out any events you need to work with.

[colin glenn]

I put together a Listview event logger program which can be found in the source code forum:

I like that, nice little toy for message checking.

[colin glenn]

PLEASE DISREGARD THIS IDIOT!

Answer staring at me right in the face and I never saw it.

IF ISTRUE isLoading THEN EXIT FUNCTION

Never turned it back off when done loading the listview, ...
:dang:

[Michael Mattias]

Overuse of STATIC and GLOBAL variables will do that to you.

So will not posting all relevant code.

[colin glenn]

I'm up to 1 static variable in my main WinProc, but due to the need to track a lot of objects and global structures, I'm up to 5 of those so far, is that bad?

And posting the whole WinProc might not of revealed where the error was happening, it was only when I constructed a debug line to print EVERY notification that the WinProc saw that my brain went, "Hey dummy, did you clear the flag for the listview like you did for the treeview?".

[Michael Mattias]

When I first saw your post a few days ago, I was tempted to ask if you had reset that flag. Then I said to myself, "Nah, too obivious, he MUST have checked that."

As far as GLOBAL and STATIC vars, I am well-known to be a preacher of the philosophy that says the fewer, the better. If you like 'em, use 'em. Just be aware that every GLOBAL and STATIC var you add makes your code more difficult to appropriate for other purposes. But hey, if you get paid by the hour....

[Cliff Nichols]

Or even as MCM has finally trained me in ("Compilable code example" and I long fought against thinking "Much tooooo large to simplify")

you will be AMAZED at how often trying to demo the problem, leads you to the solution

I add the "Compilable" part cause I also often see that someone attempting to help gets it right when the problem is compiled wrong..and the code is similar (just not QUITE)

Saves a lot of headache and hassle if you ask me

[colin glenn]

Eh:

Code no longer relevant.

So there's 3 static variables, tIndex is a temp used with debugging. And I'm up to 11 globals now, ...