Well, not really: just kinda mashed together a listbox with edit controls to end up with an editable listbox, one you can type into directly without any extra programming. Something that a lot of others have done, no doubt, but here it is in a fairly neat package. I call it a "ListEdit".
It's based on an owner-draw listbox; actually learned a lot about owner-draw doing this, so I feel a lot more competent with that. Owner draw, of course, means that you control the vertical and the horizontal; in the case of a listbox, you're responsible for displaying the text it contains, plus any other drawing needed. The magic happens in your WM_DRAWITEM handlng code. I kept this pretty simple, just horizontal rules between "cells".
I was just about done and thought to myself "well, at least I didn't have to do any subclassing", but I ended up having to do that; problem was catching the last edit before the user hits "OK" if they didn't invoke another LBN_SELCHANGE by clicking on another item, so ended up with an "orphaned" item. Problem solved easily with a very simple subclass routine for the edit control that simply marks it "dirty" if any keystrokes come through it.
BTW, fun fact: this works with only a single edit control. Quiz question: how does that work? I've used this technique before and it's pretty cool, I think.
Anyhow, play with it and let me know what you think.
I should point out that the "control" has no keyboard interface, which would be nice. Maybe in version 1.1: cursor keys for prev/next item? Tab for next item?
Seems to work here. :thumbsup: Running Windows 7 32 bit in case that matters.
Not sure what I'd use it for though. I'm certain if you have a use for it someone else might too.
Quote from: NoCforMe on August 18, 2022, 09:17:53 AM
Well, not really: just kinda mashed together a listbox with edit controls to end up with an editable listbox, one you can type into directly without any extra programming.
You might test this one (http://masm32.com/board/index.php?topic=3231.msg112221#msg112221) for your inspiration ;-)
Pretty kewl there.
Found a bug for you (small one): If you select a row by clicking on any data element in the table, it highlights the row and shows it in the status window at the bottom. But if you select a row by clicking on its row # (leftmost column), it highlights the row but doesn't show it at the bottom of the window.
Quote from: swordfish on August 18, 2022, 10:55:57 AM
Seems to work here. :thumbsup: Running Windows 7 32 bit in case that matters.
Not sure what I'd use it for though. I'm certain if you have a use for it someone else might too.
It's for users to enter 3-4-5-6 separate text items (in this case, search terms for excluding files from a search, like .jpg, .pdf, etc.) Rather than use a set of separate edit controls, which looks really dorky, I thought it would be nice to have a single control, like a multi-line edit control where all could be entered at once, but more structured than a multiline edit control. (Which would require some parsing; here the separate entered items are very easy to retrieve from the listbox.) Works very nicely for its intended use, methinks.
Ok, for something like running multiple 'replace text' functions where you replace each listed item with those from another listedit control? Sounds feasible. I guess I would use that for a purpose like that. I usually use two text lists for multiple word replacements (with a qeditor plugin)
Yeah, kinda, sorta. It's for my file-finder program (like Windows Explorer's search function, which for some strange reason is completely broken on my system). I want to be able to exclude certain file types from a search where I'm looking for text in files, which as you can imagine is pretty time-consuming. As it is, my program stupidly opens any old "binary" file, JPEG, .EXE, whatever, and tries to find text within it. (Of course, there are times you want to be able to do that.)
But yeah, you could use it for such a purpose as you described.
Ok.
Quote from: NoCforMe on August 18, 2022, 01:05:24 PMI want to be able to exclude certain file types from a search where I'm looking for text in files, which as you can imagine is pretty time-consuming. As it is, my program stupidly opens any old "binary" file, JPEG, .EXE, whatever, and tries to find text within it.
The WIN32_FIND_DATA structure has everything you need.
Quote from: NoCforMe on August 18, 2022, 12:23:10 PMFound a bug for you (small one): If you select a row by clicking on any data element in the table, it highlights the row and shows it in the status window at the bottom. But if you select a row by clicking on its row # (leftmost column), it highlights the row but doesn't show it at the bottom of the window.
Thanks, I will look into that :thumbsup:
Attached is the latest version of my FindIt! program which uses this "new" control to exclude files from a search. (I've been using it with search terms like .jpg, .exe, etc. Program doesn't need wildcards, like *, just text.)
Browse to folder doesnt seem to work.
Browsed TO c:\mam32 but it remained "C:"
searching for exstensions seems to work, and is fast! ( .jpg, .dll)
Search for "." seems to list all filenames with any extension. (File name contains a dot)
search for "" (empty textbox string) crashes the program
How would you exclude a single extension from a search with this? Does it need an argument?
Edit == whoops! I found the button lol... Will test this function later
Hmm, not sure what's going on here: right after reading your reply I tried running it and couldn't get the browse for folders dialog to open. But now it works fine. Blank "Filenames to match" field no problem. More investigation required ...
Yes, if you give a search term of "." it will find any filename with a dot in it. Nothing magic there.
Thanks for trying it out and reporting problems.
Okay ran it again, all files (".") exluding .dll, .exe and .manifest
67 871 files found on C: (with those files excluded)
Then I ran it, all files (".") without any exclusions
if window is minimized to taskbar during long (entire drive) search then maximized, the program still runs but the graphics no longer work. Taskmgr shows about 50 % when running.
Once the program finishes the search taskmgr = 0 and after minimizing then maximizing it, screen remains frozen unless minimized then maximize again it then it shows results.
btw, 122 863 files without the exclusions mentioned above
hope this helps
Oh yeah. Would be possible to print the list to a text file?
In Browse for folder, folders can't be selected but files can. odd that.
One thing important, when you are scanning for files, ALWAYS start from the end of the filename to get the extension so you avoid embedded periods "." .
@Swordfish: Wow, I guess it's back to the lab for this. For one thing, I never tried minimizing it while running. Big problems there upon reopening it. I have no idea what's going on there; might have something to do with the thread I started in the program. Other stuff warrants looking into as well.
Yes, it's not only a CPU hog but a memory hog as well (the listview here is the culprit). I'm getting about 25% CPU usage here. (Windows 7-64: what's your OS?)
@Hutch: That doesn't apply here. I'm not searching for extensions at all; I just treat the filename as a string and compare the search term against it. If there are embedded periods in the name, these will either match or not (probably not if you're looking for, say, ".jpg" files). So the current scheme works pretty well.
I can see how your advice would work well if you do want to check for extensions. As it is, my "exclude" logic can exclude any files matching the search terms entered, which may or may not be extensions.
Quote from: NoCforMe on August 20, 2022, 08:44:02 AM
@Swordfish: Wow, I guess it's back to the lab for this. For one thing, I never tried minimizing it while running. Big problems there upon reopening it.
maybe need to process WM_PAINT messages?
I'll keep playing with it, and let you know if I find any other oddities.
Quote from: swordfish on August 20, 2022, 08:47:07 AM
maybe need to process WM_PAINT messages?
Don't know where you get that; nowhere in my code do I need to process that message. The only place that does any painting is my owner-drawn listbox, and there I just use the Windows-supplied handle to a DC. So it's something else.
Quote from: NoCforMe on August 20, 2022, 08:52:27 AM
Don't know where you get that
Because after minimize, then maximize the text display not updating but the program is still running. (As evident in taskmgr) So hmmm. Or maybe dc handle you mentioned getting corrupted somehow?
No, because that code is in the "exclude" dialog which isn't even up when the rest of the program is running. For sure something's getting corrupted, though ...
Oh no, I've created a monster!
Quote from: NoCforMe on August 20, 2022, 09:14:14 AM
No, because that code is in the "exclude" dialog which isn't even up when the rest of the program is running.
:rolleyes: oops my bad. Of course you are correct there.
How about disallow minimizing and maximizing.
Does covering the window with another program affect your programs window? I'm on my iPad out and about can't check that myself... I'll look at that later though.
Quote
Oh no, I've created a monster!
Oh no!!! Not really though. Just fix the small problems first, tackle the hardest problem later.
For the 'Browse for folder' issue - you probably figured out already...
;=====================================
; Browse command
;=====================================
do_browse:
;***** Now using GetOpenFileName(): *****
could be a problem. Unless you select a file then parse the full path and retrieve the folder name from that...
I haven't seen any other problems other than those already noted.
No. Believe me, I've been over this ground many, many times.
I've tried several methods to get just folders instead of files. The method I settled on involves rigging
GetOpenFileName() so that it only returns folders, not files. This rigging involves
- Subclassing the GetOpenFileName() dialog
- Setting up a "fake" buffer that I can manipulate to get folders instead of files
- Setting up an "impossible" "filter" for files that'll never be satisfied
Complicated but it works. Except that now, some files are creeping into my Select Folder dialog. Dunno what's up with that ...
I got this technique from an article posted on the web. Don't have it at the moment but will post a link to it later.
Back to the drawing board ...
Any reason to not use SHBrowseForFolderA()?
Yes, I tried it and did not like it at all. Much more complicated, for one thing.
Here's the page (https://www.codeproject.com/Articles/20853/Win32-Tips-and-Tricks#browse2) on rigging GetOpenFileName() to deliver folders. Explains why this is a better method.
What? I've never had any problems using it. From the Masm32 library - header there because part of masm32.lib
; #########################################################################
.386
.model flat, stdcall ; 32 bit memory model
option casemap :none ; case sensitive
include \masm32\include\windows.inc
include \masm32\include\shell32.inc
include \masm32\include\user32.inc
include \masm32\include\ole32.inc
cbBrowse PROTO :DWORD,:DWORD,:DWORD,:DWORD
.code
; #########################################################################
BrowseForFolder proc hParent:DWORD, lpBuffer:DWORD, lpTitle:DWORD, lpString:DWORD
; ------------------------------------------------------
; hParent = parent window handle
; lpBuffer = 260 byte buffer to receive path
; lpTitle = zero terminated string with dialog title
; lpString = zero terminated string for secondary text
; ------------------------------------------------------
LOCAL lpIDList :DWORD
LOCAL bi :BROWSEINFO
mov eax, hParent ; parent handle
mov bi.hwndOwner, eax
mov bi.pidlRoot, 0
mov bi.pszDisplayName, 0
mov eax, lpString ; secondary text
mov bi.lpszTitle, eax
mov bi.ulFlags, BIF_RETURNONLYFSDIRS or BIF_DONTGOBELOWDOMAIN
mov bi.lpfn, offset cbBrowse
mov eax, lpTitle ; main title
mov bi.lParam, eax
mov bi.iImage, 0
invoke SHBrowseForFolder,ADDR bi
mov lpIDList, eax
.if lpIDList == 0
mov eax, 0 ; if CANCEL return FALSE
push eax
jmp @F
.else
invoke SHGetPathFromIDList,lpIDList,lpBuffer
mov eax, 1 ; if OK, return TRUE
push eax
jmp @F
.endif
@@:
invoke CoTaskMemFree,lpIDList
pop eax
ret
BrowseForFolder endp
; #########################################################################
cbBrowse proc hWin :DWORD,
uMsg :DWORD,
lParam :DWORD,
lpData :DWORD
invoke SetWindowText,hWin,lpData
ret
cbBrowse endp
; #########################################################################
Quote from: NoCforMe on August 20, 2022, 10:18:38 AM
Much more complicated, for one thing.
Nah. C'mon you've been writing code a lot longer than me
Well, I may have to go that route because guess what? my browse-for-folder thing
never worked correctly anyhow. (Just downloaded the earlier .zip I posted of the program. It always showed files, after the folders: I just never noticed ...)
This is turning into a quite interesting project ...
OK, here's one thing I really really don't like about your code. As I said, I tried using this method, and ran into the same problem you have here.
You see that line in your code
mov bi.pidlRoot, 0
Well,
pidlRoot is the member of the BROWSEINFO struct you use to set the starting point from the root folder to start browsing. Except that you're not setting it to anything useful here, so every damn time you start from the root and have to drill down to where you want to be. Pain in the ass. At least with my method it starts the browse from where you left off the last time, which is what most users would expect.
I never figured out how to use this member to start where I want to. Maybe I can do that w/some more research.
Hmm; maybe just found that. On that page I linked to earlier:
QuoteIt would be nice if the browser dialog opens with the current path already selected. Here's how you do it:
int CALLBACK BrowseCallbackProc( HWND hWnd, UINT uMsg, LPARAM lParam,
LPARAM lpData )
{
if (uMsg == BFFM_INITIALIZED)
SendMessage(hWnd, BFFM_SETSELECTION,TRUE, lpData);
return 0;
}
g_SHBF_Folder=_T("C:\\Program Files");
TCHAR path[_MAX_PATH];
BROWSEINFO info={NULL,NULL,path,_T("title"),BIF_USENEWUI,BrowseCallbackProc,
(LPARAM)g_SHBF_Folder};
SHBrowseForFolder(&info);
where
g_SHBF_Folder is the starting point you want. (Probably Unicode so you have to deal w/that, but not a deal-breaker.)
Don't give up though, it looks promising.
I would disable the minimize/maximize buttons of the window (to avoid first issue), use SHBrowseForFolderA (to fix the folder issue), uncomment the null string handling (for the crash issue).
Then work on why the program is CPU hungry (~50%)
Well, I've been playing with this for almost 4 hours now (off and on) and I'm sure you've been at it for longer... So..... ZZZzzzz time for a rest
Quote from: NoCforMe on August 20, 2022, 10:30:10 AM
pidlRoot
I never figured out how to use this member to start where I want to. Maybe I can do that w/some more research.
Ask on the forum, I never minded starting from root myself though.
Upon a google search for pidlRoot:
You can use SHParseDisplayName to receive a pidl for a folderfrom...
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/32da371f-d6cb-4a97-a679-da2b7fbcf468/browseinfo-how-to-initailize-pidlroot-with-a-string-not-a-special-folder-id?forum=vcgeneral (https://social.msdn.microsoft.com/Forums/sqlserver/en-US/32da371f-d6cb-4a97-a679-da2b7fbcf468/browseinfo-how-to-initailize-pidlroot-with-a-string-not-a-special-folder-id?forum=vcgeneral)
So, ok... I guess doing all of this makes it a little more complicated. But no harm in trying
I've never done that, but I might just burn the midnight oil tonite and make a test piece to try it.
Quote from: NoCforMe on August 20, 2022, 06:39:26 AM
Attached is the latest version of my FindIt! program which uses this "new" control to exclude files from a search. (I've been using it with search terms like .jpg, .exe, etc. Program doesn't need wildcards, like *, just text.)
The exclude listbox works fine, compliments, but its functionality seems not implemented
Re "doesn't need wildcards", most users would search for *.txt or similar and be very surprised not to find any files :sad:
For comparison, I attach my version. Some differences:
- wildcard search, e.g.
*.as?|*.inc|*.rc (finds/searches text in *.asm, *.asc, *.inc and *.rc files)
- if the "text" edit is empty, find all files, otherwise only those that contain "text"
- hitting Return or clicking Go! starts the search
- window is fully sizeable
Plus keep in mind that you're now in Unicode-land. No more simple zero-terminated ASCII strings.
(Easy to convert both ways, but a pain in the ass to have to do it.)
Quote from: NoCforMe on August 20, 2022, 11:41:42 AM
Plus keep in mind that you're now in Unicode-land.
Oops - you are right. Corrected - see new attachment in the post above :thumbsup:
SetStatus$ Cat$(Str$("%i files found in ", filesFound)+NanoTimer$())
StringBuild res$
For_ ecx=0 To Files$(?)-1
Let res$=Str$("#%__i\t", ecx)+Files$(ecx)+CrLf$
Next
StringBuild
uSetWin$ hResults=res$ ; Unicode, please