Send or Post %TVN_SELCHANGED to TV

[BOB MECHLER]

How do you programmtically cause a treeview to post a %TVN_SELCHANGED message? Assume an item is already selected with TreeView_SelectItem.

Bob Mechler

[BOB MECHLER]

Right now I'd settle for a subclass example of the treeview just to trap the enter key and simulate a TVN_SELCHANGED event.

Bob Mechler

[BOB MECHLER]

I was using a hidden buddy box to track the items being chosen by placing the menu number equivalent in the buddy textbox. I was also simulating an enter key on the mouse click to trigger the hidden buddy box to complete and process the menu option. Trouble is the up and down arrow did the same which is not the behaviour we wanted. Since the menu list can be much longer than what can be viewed and we felt fooling with the scroll bar was non-desirable we made the right treeview two levels with section headers that didn't do anything except allow the right treeview to expand of collapse sections of the treeview. Each section could 19 items and we wanted the user to be able to use the up and down arrow without triggering the TVN_SELCHANGED event. The following snippet allowed us to filter out the simulated enter code and limit it to a mouseclick.

This approach also accomodated our keyboard only users because, if desired we could make the buddy box visible and they could ignore the treeview menus except to get a menu number. They can enter 502 or 5.02 and it will traverse to menu 5 and choice 2. If they are already on menu 5 then just a 2 is sufficient. Some of our folks also know the exe name since they use it often and they can just enter the exe name and press enter without navigating the menu at all.

    IF @lpTV.action = %TVC_BYMOUSE THEN

[Chris Boss]

Treeview items can be selected via code by sending the TVM_SELECTITEM message.

You may find that superclassing the treeview, rather than subclassing may produce better results for writing code to trap any messages to change the controls behavior.

The GetClassInfoEx API function can be used to get info about the treeviews window procedure (which is part of the operating system). You then register a new window class (ie. call it MyTreeview) and in your window procedure code, pass all the messages to the CallWindowProc API function instead of DefWindowProc, using the window procedure address for the treeview class returned using GetClassInfoEx.

Once you have your superclass of the treeview, you can add any code you want to the window procedure to change how it works. Trapping the mouse or keyboard is relatively easy to do.

Superclassing (intsead of subclassing) is a much better way to impliment new features for existing controls. By writing a good superclass, you can add it to any application you want, simply by using the new class (put your superclass code in an include file so it can be used with any app).

[Michael Mattias]

How do you programmtically cause a treeview to post a %TVN_SELCHANGED message? Assume an item is already selected with TreeView_SelectItem

???

TreeView_SelectITem (TVM_SELECTITEM message) already causes the WM_NOTIFY/TVN_SELCHANGED message to be posted to the owner window.

As far as subclassing, there have got to be at least two hundred sixty eight examples here of "identify when <ENTER> was pressed."

Not that you need to subclass... WM_NOTIFY/NM_KEYDOWN can tell you when the <enter> key was depressed. (I think).

[BOB MECHLER]

TVN_KEYDOWN doesn't return %VK_RETURN. It returns %VK_UP and %VK_DOWN just fine though. I had to subclass a LISTBOX one time to trap the enter key and the SuperClassing looks promising. For now I changed my approach and got the results I wanted. My first post was not a very good description of what I needed.

Bob Mechler

[Michael Mattias]

Pray what does "Enter" mean if I do it on a Tree Control?

I mean, I can kind of understand "Enter" on a button meaning "press me" even though the Windows' standard for such a thing is <spacebar>; but logically I can't figure out what "<enter>" on a treeview node is supposed to mean. (Edit me? Copy me?)

Inquiring Minds Want to Know!

[BOB MECHLER]

Windows Explorer has a look and feel that I wanted to emulate in my menu.

The left pane of WE is a Treeview and actuates what is in the right pane through a mouse click or the arrow keys.

The right pane in WE has folders and files. You can navigate without triggering the program to run or the folder to open. Clicking or pressing enter will cause the folder or program to run.

I put all my menu and program information in arrays through data statements. The Main Menu has 19 sub menus.

In my left treeview I track the TVN_SELCHANGED event. When it occurs through a click or an arrow, I use the text from the treeview node to find the array element holding information about the submenu. From there I delete all previous elements in the right treeview and fill the right treeview with the elements of the submenu.

The elements in the right treeview are two levels deep, hence the use of a Treeview instead of a listbox. The first level is a descriptive term for the programs in that section and doesn't refer to a program to launch. The right treeview has two to five such breaks. When I fill the right treeview I expand only the first node, leaving the other nodes collapsed to keep it from looking so cluttered.

As each submenu gets populated in the right treeview, I programmatically click in the right treeview to cause it to gain focus and properly highlight the first item in the list. From there I wanted to use the up and down arrow to navigate and click or enter to run the program associated with the tree node.

Associated with the right treeview is an optionally visible shortcut textbox. People who have had the program for years only had this textbox to make their entries and putting the menu choice directly in this box and pressing enter is how they navigated to the desired program.

Normally when a node in the right treeview is clicked or the down arrow is pressed it triggers the TVN_SELCHANGED event. From that I originally chose the node text and looked up in my menu data array what program to launch. From there I translated the treeview node text to a menu number and placed it in the shortcut textbox whether visible or not and used keybd events to trigger the shortcut textbox to complete. From there the program would launch the appropriate program.

To allow the up and down arrows in the right treeview to not trigger a program launch I had to put code in that allowed the menu choice to be put in the shortcut textbox but not programmatically press enter. That was made possible by the lines.

                      CONTROL SET TEXT hdlg,ID_MENU_CHOICE,COPT$
                      IF @lpTV.action = %TVC_BYMOUSE THEN
                        KeyBd_Event %VK_RETURN, MapVirtualKey(%VK_RETURN, 0), 0, 0: SLEEP 0
                        KeyBd_Event %VK_RETURN, MapVirtualKey(%VK_RETURN, 0), %KEYEVENTF_KEYUP, 0: SLEEP 0
                      END IF

This way if they clicked an entry in the right treeview the translated menu number was placed in the shortcut textbox and enter was then simulated in the shortcut textbox. If they just used the up and down arrows then the enter key would not fire. This allowed the up and down arrow keys to be used for navigation in the right treeview. The right arrow and left arrow can also be used to expand or collapse a main descriptive node.

This behaviour simulates Windows Explorer's right pane.

Now if menu items change, all I have to do is change the data statements. The rest is handled by the routines.

Probably more than you wanted to know, but I find by writing out what a section of code like does is it helps me spot anything I might have forgotten.

Bob Mechler

[Michael Mattias]

You're right. It was more than I wanted to know.

I think what I was looking for was something more concise, perhaps...

"Each tree node represents a menu action; the user navigates the tree with the mouse or the up and down arrow keys; when the desired item is selected <enter> selects that menu action."

MCM