1. TreeView events
- Posted by Tyler Southwick <wick900 at operamail.com> Dec 11, 2001
- 538 views
I have a treeview that i need to capture the expanding of a treeview child. I have it set up to capture the expanding, but I don't know how I can figure out which of the treeview items caused the expanding. 'hitTestTV' does not work if the plus box is clicked next to the item <code> procedure myNotify(atom iMsg, atom wParam, atom lParam) atom lNewMsg, tvId, VOID integer id sequence dirData, currDir -- Only look at NOTIFY messages if iMsg = WM_NOTIFY then -- Get which notify message it is. lNewMsg = fetch( lParam, NMHDR_code ) -- Get which control sent it. id = getId( fetch(lParam, NMHDR_hwndFrom ) ) --use the ID in any way end if end procedure </code>
2. Re: TreeView events
- Posted by euman at bellsouth.net Dec 11, 2001
- 558 views
Hello Tyler, Here is a snippet from one of my projects! iMsg = peek4s(lParam + NMHDR_code) if iMsg = TVN_ITEMEXPANDING then hItem = peek4u(lParam + NMTVHDR_itemNew) if peek4s(lParam + NMTVHDR_action) = TVE_EXPAND then With the (above), if you get to this point then your TreeView Item is expanding. Good luck on your Treeview journey, it took me almost a month to get a directory listing treeview similar to (BrowseforFolders) written without shell commands that is compatible with Win 95,98,2k,NT and XP. I dont release stuff like this cause in testing the waters with the user-contrib page I dont fair well with smiley-faces. I'll help if you have any further question though. Hint for you, keep an eye on the Comctl32.dll version tables in the MS-SDK. Most of the functionalilty you'll require will have to be written for version 4.71+ Euman euman at bellsouth.net From: "Tyler Southwick" <wick900 at operamail.com> > I have a treeview that i need to capture the expanding of a treeview > child. I have it set up to capture the expanding, but I don't know how > I can figure out which of the treeview items caused the expanding. > 'hitTestTV' does not work if the plus box is clicked next to the item > > <code> > procedure myNotify(atom iMsg, atom wParam, atom lParam) > atom lNewMsg, tvId, VOID > integer id > sequence dirData, currDir > -- Only look at NOTIFY messages > if iMsg = WM_NOTIFY then > -- Get which notify message it is. > lNewMsg = fetch( lParam, NMHDR_code ) > -- Get which control sent it. > id = getId( fetch(lParam, NMHDR_hwndFrom ) ) > --use the ID in any way > end if > end procedure > </code> > > > >
3. Re: TreeView events
- Posted by euman at bellsouth.net Dec 11, 2001
- 499 views
Hello again Tyler, I thought I would give you alittle more to play with! Here it is, Good luck! global atom txtbuff global function filltvitem(atom Item, atom mask, atom state) poke4(tvitem + tvitem_hItem,Item) poke4(tvitem + tvitem_mask,mask) poke4(tvitem + tvitem_stateMask, state) txtbuff = myalloc(256) poke4(tvitem + tvitem_pszText,txtbuff) poke4(tvitem + tvitem_cchTextMax,256) return txtbuff end function function WndProc(atom hwnd, atom iMsg, atom wParam, atom lParam) elsif iMsg = WM_NOTIFY then id = peek4s(lParam + NMHDR_hwndFrom) if id = TreeView then iMsg = peek4s(lParam + NMHDR_code) if iMsg = TVN_ITEMEXPANDING then hItem = peek4u(lParam + NMTVHDR_itemNew) if peek4s(lParam + NMTVHDR_action) = TVE_EXPAND then itxtbuff = filltvitem(hItem, TVIF_TEXT, 0) item = SendMessage(id, TVM_GETITEM, 0, tvitem) BTW, I do not use Win32lib 'cos it's waayyy too slow for things like this. You really need to have an in-lined method because when a treeview is visible, your program generates WM_NOTIFY messages very often. Euman euman at bellsouth.net
4. Re: TreeView events
- Posted by euman at bellsouth.net Dec 12, 2001
- 484 views
Hello all, Most of what I write below is intended to spark-a-flame in a few on the list. Win32lib isnt going anywhere at the moment so I thought I would help out. Not with the coding though... From: "Matthew Lewis" <matthewwalkerlewis at YAHOO.COM> > >From MSDN, when you get a WM_NOTIFY from a treeview, you've actually got an > NMTREEVIEW structure, rather than a NMHDR structure. I know Matt was trying to be political about how you setup structures but if you think far enough in advance and dont want any wasted space or memory other controls can take advantage of the same or similar structures *WITHOUT ANY problems. look at the below, I reuse these for listview and treeview *NMHDR_hwndFrom *NMHDR_code elsif iMsg = WM_NOTIFY then id = peek4s(lParam + NMHDR_hwndFrom) if id = ListView1 then iMsg = peek4s(lParam + NMHDR_code) if iMsg = LVN_COLUMNCLICK then -- ListView "could run a sort routine here" elsif iMsg = NM_CLICK then -- ListView Item Clicked junk = SendMessage(id,LVM_GETNEXTITEM,-1, LVNI_FOCUSED) poke4(lvitem + lvitem_iItem,junk) poke4(lvitem + lvitem_iSubItem,0) poke4(lvitem + lvitem_mask,LVIF_TEXT) txtbuff = allocate(256) poke4(lvitem + lvitem_pszText,txtbuff) poke4(lvitem + lvitem_cchTextMax,256) cmd = SendMessage(id, LVM_GETITEM, 0, lvitem) text = peek_zstring(txtbuff) end if elsif id = TreeView1 then iMsg = peek4s(lParam + NMHDR_code) if iMsg = TVN_ITEMEXPANDING then hItem = peek4u(lParam + NMTVHDR_itemNew) if peek4s(lParam + NMTVHDR_action) = TVE_EXPAND then itxtbuff = filltvitem(hItem, TVIF_TEXT, 0) item = SendMessage(id, TVM_GETITEM, 0, tvitem) > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla > tform/CommCtls/TreeView/structures/NMTREEVIEW.asp > > typedef struct tagNMTREEVIEW { > NMHDR hdr; > UINT action; > TVITEM itemOld; > TVITEM itemNew; > POINT ptDrag; > } NMTREEVIEW, FAR *LPNMTREEVIEW > > You should be able to get the child id from itemOld Should? are you sure Matt? > procedure myNotify(atom iMsg, atom wParam, atom lParam) > atom lNewMsg, tvId, VOID > , itemOld, childId -- <== ADD THIS **************************** > integer id > sequence dirData, currDir > -- Only look at NOTIFY messages > if iMsg = WM_NOTIFY then > -- Get which notify message it is. > lNewMsg = fetch( lParam, NMHDR_code ) > -- Get which control sent it. > id = getId( fetch(lParam, NMHDR_hwndFrom ) ) > --use the ID in any way > > -- ***************** HERE'S WHAT YOU NEED TO DO: ************************ > if lNewMsg = TVN_ITEMEXPANDING then > > -- get the pointer to the tvitem > -- need to remember to include NMHDR in offset > itemOld = peek4u( lParam + 16 ) > > -- Get the win32lib item id > childId = fetch( itemOld, TVITEM_lParam ) > > -- Do your stuff.... > end if > -- ***************** END ************************************************* You MUST fill in the _itemNew so you'll know what item is expanding if you want to track the item later. There again, thinking far enough in advance of yourself.. global function filltvitem(atom Item, atom mask, atom state) poke4(tvitem + tvitem_hItem,Item) poke4(tvitem + tvitem_mask,mask) poke4(tvitem + tvitem_stateMask, state) txtbuff = allocate(256) poke4(tvitem + tvitem_pszText,txtbuff) poke4(tvitem + tvitem_cchTextMax,256) return txtbuff end function itxtbuff = filltvitem(hItem, TVIF_TEXT, 0) item = SendMessage(id, TVM_GETITEM, 0, tvitem) > > end if > end procedure > > </code> > > Now that you're starting to interface directly with windows (ie, looking at > raw structures, unfiltered by win32lib), please remember to be patient > (unless you're *very* fluent already with C structures). Better off just learning to write your own code for Windows API because you *will outgrow win32lib eventually or need a feature thats missing. If you know how to write API from the get-go, you want be at a loss when the time comes. Alot of people think that Win32lib will allow them to write some major apps in no time at all but this is huge misconception just look at Judiths IDE. How long has it taken to get to this point? Could have written the same thing without Win32lib alot faster and used less people to do it. > In my experience, > if you find a bug that you can't track down, you're probably Probably? you dont sound sure or, is it because it's Win32lib? > misusing a > structure (declared wrong, improper offset, etc). > > Win32Lib will probably be fast enough Matt doesnt sound so sure of himself, does he? > for almost anything you want to do. Note: almost! My opinion I will keep to myself. > The one known area where it is lacking is in loading large amounts of data > at once to a list/treeview. Yeah, didnt you write that part Matt? > There are some on the list who have work > arounds for that, Sure do! > and something like these methods should be a part of the > lib eventually. Once Derek gets his priorities straight and gets back to > his true calling (coding win32lib, of course!), everything will be better. > ;) > > Matt Lewis Euman
5. Re: TreeView events
- Posted by irvm at ellijay.com Dec 12, 2001
- 473 views
On Wednesday 12 December 2001 02:28 pm, euman wrote: > Better off just learning to write your own code for Windows API > because you *will outgrow win32lib eventually or need a feature thats > missing. If you know how to write API from the get-go, you want be at a > loss when the time comes. Alot of people think that Win32lib will allow > them to write some major apps in no time at all but this is huge > misconception just look at Judiths IDE. How long has it taken to get to > this point? Could have written the same thing without Win32lib alot faster > and used less people to do it. Anyone who outgrows Win32lib is much more likely to go to Delphi, so they can get something done, rather than fall back on the Windows API and C. Nobody really enjoys writing 100 lines of code to get an empty window on the screen, unless they just have nothing else to do. Borland found that out with their TPW and TPC environments - hardly anyone bought them, and those who were foolish enough to do so, like me, never used them for anything more than "Hello World". Irv
6. Re: TreeView events
- Posted by euman at bellsouth.net Dec 12, 2001
- 480 views
Modularity Irv. Ive found that there are certain things like Window Creation which most Common Controls derive from can be built in seperate include's and when needed simply pluged into code. Tommorow, I will have A complete Drive/Directory Listing TreeView that I will send to Robert for you to look at. Once the hard work is thru Irv it is SO much simpler I think that Win32lib to write a program and to prove this, I'll start right now on the Demo and by Tommorow it'll be complete. Much faster than Win32lib, Much Smaller, More reliable, less sofisticated and just as easy to assemble. Jacques Deschenes was on the right track when he wrote the API wrappers and my demo will house a few of his plug-in routines but for the most part, (98%) of the code was written by me. I'll give the time it took to create the demo and lets see if someone can match or beat my time creating an identicle program. Euman euman at bellsouth.net ----- Original Message ----- From: <irvm at ellijay.com> To: "EUforum" <EUforum at topica.com> Sent: Wednesday, December 12, 2001 6:05 PM Subject: Re: TreeView events > > On Wednesday 12 December 2001 02:28 pm, euman wrote: > > > Better off just learning to write your own code for Windows API > > because you *will outgrow win32lib eventually or need a feature thats > > missing. If you know how to write API from the get-go, you want be at a > > loss when the time comes. Alot of people think that Win32lib will allow > > them to write some major apps in no time at all but this is huge > > misconception just look at Judiths IDE. How long has it taken to get to > > this point? Could have written the same thing without Win32lib alot faster > > and used less people to do it. > > Anyone who outgrows Win32lib is much more likely to go to Delphi, so they > can get something done, rather than fall back on the Windows API and C. > > Nobody really enjoys writing 100 lines of code to get an empty > window on the screen, unless they just have nothing else to do. > Borland found that out with their TPW and TPC environments - hardly > anyone bought them, and those who were foolish enough to do so, > like me, never used them for anything more than "Hello World". > > Irv > > > >
7. TreeView events
- Posted by euman at bellsouth.net Dec 12, 2001
- 480 views
Modularity Irv. Ive found that there are certain things like Window Creation which most Common Controls derive from can be built in seperate include's and when needed simply pluged into code. Tommorow, I will have A complete Drive/Directory Listing TreeView that I will send to Robert for you to look at. Once the hard work is thru Irv it is SO much simpler I think that Win32lib to write a program and to prove this, I'll start right now on the Demo and by Tommorow it'll be complete. Much faster than Win32lib, Much Smaller, More reliable, less sofisticated and just as easy to assemble. Jacques Deschenes was on the right track when he wrote the API wrappers and my demo will house a few of his plug-in routines but for the most part, (98%) of the code was written by me. I'll give the time it took to create the demo and lets see if someone can match or beat my time creating an identicle program. Euman euman at bellsouth.net
8. Re: TreeView events
- Posted by euman at bellsouth.net Dec 12, 2001
- 482 views
Hello Matt / Irv Im finished with the Drive/Directory Listing Treeview Demo! Very much like Shell32's BrowseforFolders dialog except this demo uses (0) no Shell commands and doesnt even use Euphoria's Dir( ) procedure. I made my own version and it's on the user-contrib page already. 20 minutes was all I needed to cut/past code. This version will not check for comctl32.dll version so if you dont have version 4.71 or higher the demo will not work. Win95 w/IE4+ has this version. I need to zip it up and send it to Rob, look for it in a day or so on the user-contrib page. Euman ----- Original Message ----- From: <euman at bellsouth.net> To: "EUforum" <EUforum at topica.com> Sent: Wednesday, December 12, 2001 6:31 PM Subject: TreeView events > > Modularity Irv. > > Ive found that there are certain things like Window Creation > which most Common Controls derive from can be built > in seperate include's and when needed simply pluged into > code. > > Tommorow, I will have A complete Drive/Directory Listing > TreeView that I will send to Robert for you to look at. > > Once the hard work is thru Irv it is SO much simpler I think > that Win32lib to write a program and to prove this, I'll start > right now on the Demo and by Tommorow it'll be complete. > > Much faster than Win32lib, Much Smaller, More reliable, > less sofisticated and just as easy to assemble. > > Jacques Deschenes was on the right track when he wrote the API > wrappers and my demo will house a few of his plug-in routines > but for the most part, (98%) of the code was written by me. > > I'll give the time it took to create the demo and lets see if someone > can match or beat my time creating an identicle program. > > Euman > euman at bellsouth.net > > > >
9. Re: TreeView events
- Posted by tone.skoda at siol.net Dec 12, 2001
- 520 views
Win32Lib is good becuase it's simple. I wrote my WinMania library because I didn't want to learn new functions, new names, what they do, and I already had good manual (MSDN) for C functions. Otherwise Win32Lib is great. ----- Original Message ----- From: <euman at bellsouth.net> To: "EUforum" <EUforum at topica.com> Subject: Re: TreeView events > > Hello all, > > Most of what I write below is intended to spark-a-flame in a few on the list. > Win32lib isnt going anywhere at the moment so I thought I would help out. > Not with the coding though...