News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

I invented a new type of Windows control (List/Edit)

Started by NoCforMe, August 18, 2022, 09:17:53 AM

Previous topic - Next topic

NoCforMe

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?
Assembly language programming should be fun. That's why I do it.

quarantined

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.


jj2007

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 for your inspiration ;-)

NoCforMe

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.
Assembly language programming should be fun. That's why I do it.

NoCforMe

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.
Assembly language programming should be fun. That's why I do it.

quarantined

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)

NoCforMe

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.
Assembly language programming should be fun. That's why I do it.


jj2007

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:

NoCforMe

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.)
Assembly language programming should be fun. That's why I do it.

quarantined

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

NoCforMe

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.
Assembly language programming should be fun. That's why I do it.

quarantined

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?

quarantined

In Browse for folder, folders can't be selected but files can. odd that.

hutch--

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 "." .