You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
Yes, those are Window Class names, and yes they were in the provided Windows' header files somewhere, and both should still be there somewhere, as they are the classnames for the standard status bar control ("msctrls_statusbar32") and listview control ("syslistview32")
They "belong in" (and used to come from) the Commctrl.Inc file
the original demo (which i left in place) demo'd the use of "text callbacks" with a listview control.
i have enhanced this program by adding a few features...
- instead of using a manufactured array for the data, we show a text file. if a file name is entered on the command line, that file is loaded; if no file is specified, the user is prompted to select one.
- included the logic to allow the file to be either pc or unix delimited (totally transparent.. that is, you don't care).
- added compile-time option to preserve blank lines yes/no.
- added a column for the 'line number'
- added a status bar
- the actual text of the file is presented as though it were being printed on greenbar paper. (i miss greenbar).
- added a keyboard interface to supplement the mouse interface supplied by the listview control. the keyboard handler handles the up and down arrows and the pageup/pagedown keys.
maybe someone else will take a look at handling the horizontal scroll (right/left arrows).
basically, i've turned this demo into "yet another text file viewer." but since there are already enough of these, i tried to make sure the 'instructional' part of the demo was enhanced, too. in addition to new features, i did a dew extra things with the source code:
- cleaned it up, a lot; datanames, yes, but more particularly, the comments.
- supplied a modified form of the powerbasic-created "openfiledialog" procedure (in comdlg32.inc). this version ("openfiledialogcentered") centers the dialog on the desktop.
"openfiledialogcentered" uses the same parameters as the original "openfiledialog" procedure, so it may be 'dropped in' to any program. (i personally never use the "openfiledialog" procedure; mostly because that procedure presents the window in the upper-left-hand corner of the screen, which imnsho looks cheap and ugly).
- i changed all the "sendmessage" calls to the listview control to use the "listview_xxxx" macros.
- i eliminated all global and static variables. the code is completely re-entrant and thread-safe; all you'd have to do to actually use this same window proc with multiple windows in the same program is change the wm_destroy handler (unless you are running this window in its own thread, in which case you could use the the wndproc exactly as written).
what inspired me to do this is a spate of recent threads here dealing with both "memory management" and the ongoing 'concern' many seem to have about 'speed.'
while for a simple file viewer with 'not too many' lines of text you'd probably just store the text of the file in the listview control and not bother with callbacks, for a very large file it does take some time to load all that text to a listview control. the file filtering used is extremely quick: the first view screen appears much more quickly than it would were you to load each line of text to the listview control.
on the memory management: the file data are stored in a global handle allocated on wm_create; that handle is stored in the four-byte "gwl_userdata" integer available for programmer use with any window (or dialog, or control). each time text is needed by the control, that handle is retrieved, a pointer obtained and the text is copied to the windows-supplied buffer. the only "non-instant" response time i got was when doing either a "page up" or a "page down" either by mouse or keyboard. i have a 400 mhz machine with no special video card; best guess is anyone with a modern machine will not even notice.
other instructional points for those who have not done this kind of thing before:
- shows how to pass (and get) a parameter into a createwindowex call. i pass the name of the file to be displayed as a parameter in the createwindowex call.
- shows how to disallow selection of rows in a listview control.
- shows "there is life without global and static variables. while some static datanames might have been useful, e.g., the height of the status bar and the number of lines in the file, neitther of which change during the life of the program, i made a conscious decision to incur the very slight performance hit as the cost of making the code re-entrant.
- i needed to get the height of a listview item, so i created the function listview_getitemheight. i had a very hard time either listview_getitemrect and listview_getsubitemrect to work correctly, so i found another way.
= shows how to use an 'ambiguous-length' asciiz ptr, e.g., "dim psz as asciiz ptr [no "* length"]." all you really need to remember about this data type is that the target of an asciiz ptr variable ("@psz") is "all characters from current address up to but not including the first $nul." when the file data are filtered, the routine essentially creates a 'big string' which is $nul-delimited.
- shows how to effectively utilize the "lparam" programmer-use integer provided by the listview control and most other controls. the lparam stored with each listview row is the offset from the start of the file data for that line's text; by setting the asciiz ptr variable to the address of the string data, we can use the 'ambiguous length' asciiz ptr to directly reference the data.
caution
if using a newer commctrl.inc you may have some problems, as the long/dword comparisons require equality checks, and many of the listview notifications are "negative" when cast as long integers. i <u>think</u> i have all comparisons done with select case as long which uses a full 32-bit comparison.
using dialogs
you can make this software work with a dialog created with createdialog[indirect][param] or dialogbox[indirect][param] or the 'ddt' syntax dialog new.. control add...
but...
note that under the wm_notify handler specific values must be returned to windows.
with "sdk-style" dialogs you set the return value using "setwindowlong hwnd, %dwl_msgresult, value." i "think" with ddt the ddt engine sets this value equal to the return value of your dialog callback procedure function.
you will probably also need to replace instances of get/set windowlong %gwl_userdata with %dwl_userdata (sdk) or dialog set/get user nnn (ddt).
mcm
[this message has been edited by michael mattias (edited may 30, 2005).]
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Leave a comment: