Windows Explorer-style "browse for file" window

[dedndave]

notice - it may change from one OS to another - and certainly with different OFN dialog styles
we may need a better way to get the location of the first item on the list
even so, it will be fairly close   :P

[raleeper]

Thanks, dedndave!

This will take a while to digest.

[raleeper]

dedndave:

Why include this in your smallofn2:

<code>
;initialize common controls

xor     edi,edi   ;EDI = 0
push    edi
push    sizeof INITCOMMONCONTROLSEX
INVOKE  InitCommonControlsEx,esp</code>?

And why don't 2 dwords pushed remain on the stack?

Thanks, ral

[dedndave]

well - with the manifest, InitCommonControlsEx allows for xp "uxtheme" appearance of buttons, etc

without uxtheme and with


as for the stack....
i want to create space on the stack for the MSG structure
actually, when i register the window class, i leave the WNDCLASSEX structure on the stack, as well
that makes room for the MSG structure in the message loop
no need to balance the stack in _main, because ExitProcess takes care of it for you   :P

[raleeper]

well - with the manifest, InitCommonControlsEx allows for xp "uxtheme" appearance of buttons, etc

Even if the flags are all 0?

no need to balance the stack in _main, because ExitProcess takes care of it for you   :P

Ah.  I thought perhaps this was some MASM32 feature I missed.  I guess a version of Invoke could be devised that would cleanup the stack for cases where the first data item is the data size (size of  stack frame?) and the parameter is "esp".

Your code contains a lot of provocatively instructive stuff.

Thanks, ral

[dedndave]

Even if the flags are all 0?

yes - lingo says that InitCommonControlsEx need not be executed at all - it just needs to be referenced
i prefer to execute it   :P

Code Select Expand

        dd InitCommonControlsEx

the extra flags are needed only if you use one of the special features that require them

no need to balance the stack if i need some space, anyways - lol

Your code contains a lot of provocatively instructive stuff

many of the forum members wouldn't call it that   :bg
i prefer to try things that are different - not just copy/paste what someone else has written
whether it's good or bad, i learn more that way

[raleeper]

Is there a way to set the position of the mouse cursor?

This would be an alternative, maybe better, way of accomplishing what I want to do with the openfilename dialog box and would have other uses.

Thanks, ral

[later]
Wait - it looks as if SendInput may be the key, and I'm investigating that now.
My question was premature.  I don't need help yet.

Sorry, ral

[dedndave]

you can use SetCursorPos
however, that isn't very desirable
and - you still have the same problem - where is the first item in the list ?   :P

[raleeper]

you can use SetCursorPos
however, that isn't very desirable
and - you still have the same problem - where is the first item in the list ?   :P

I could have sworn that "setcurs" was one of the things I searched for in the SDK documentation, but no.

I don't see any problem yet.

And I would be just as happy, on reflection, with putting the cursor in the middle of the dialog window.

I've just started debugging the hook proc as incorporated in my program.

Thanks, ral

[Gunner]

Yeah, that was from me :-)  It was for a tutorial I wrote for another site.

You can set the initial directory that GetOpen displays, and you can set the initial file.  Also, anything that you can do with a "normal" listview that you have in a progam, can be done with the listview in GetOpen/SaveFileName.  You can get ALL of the control ID's that windows uses for its dialogs from the Dlgs.h header file.

[raleeper]

Yeah, that was from me :-)  It was for a tutorial I wrote for another site.

You can set the initial directory that GetOpen displays, and you can set the initial file.  Also, anything that you can do with a "normal" listview that you have in a progam, can be done with the listview in GetOpen/SaveFileName.  You can get ALL of the control ID's that windows uses for its dialogs from the Dlgs.h header file.

Yeah, that was from me :-)  It was for a tutorial I wrote for another site.

You can set the initial directory that GetOpen displays, and you can set the initial file.  Also, anything that you can do with a "normal" listview that you have in a progam, can be done with the listview in GetOpen/SaveFileName.  You can get ALL of the control ID's that windows uses for its dialogs from the Dlgs.h header file.

I don't seem to have Dlgs.h.  Is it included in the MASM32 package? The help file doesn't contain "header files" or any of about 8 other things I tried.

Anyway, where might Dlgs.h be found?

Thanks, ral

[Gunner]

A .h file is a C header file, the dlgs.h comes with the PSDK for one.

[dedndave]

it isn't as simple as you might think   ::)

here is an article i found by Paul DiLascia
http://msdn.microsoft.com/en-us/magazine/cc164009.aspx

Problem number one is getting hold of the list view. Several readers have asked me
about this because it turns out to be non-trivial. As you can discover using Microsoft®
Spy++, the list control isn't a direct child of the dialog, it's a grandchild. Figure 1 is a
screen capture from Spy++ that reveals the true window hierarchy of the file open
dialog. As you can see, the main dialog has a child window whose class name is
SHELLDLL_DefView; this, in turn, contains the list control of files and folders.
(I first mentioned SHELLDLL_DefView in my January 2002  column.) The ID of the
SHELLDLL_DefView is lst2 (value 0x0461, defined in dlgs.h), but it's not a listbox or
list control. The real SysListView32 is a child of SHELLDLL_DefView, with child ID=1.

shouldn't be too hard, from there
if i have time, i will see what i can do tomorrow   :P

[dedndave]

reading further....

Problem number two is that the combined list control/SHELLDLL_DefView
window doesn't exist yet when your dialog gets WM_INITDIALOG. It
doesn't even exist when you get CDN_INITDONE, despite the fact that
this message is supposed to mean that the open dialog has finished initializing.
Oh well. This is empirical programming at its best: the only way to discover
what Windows does is to conduct an experiment—or read MSDN®
Magazine, of course! Figure 2  shows a test dialog I wrote to convince
myself that the list control doesn't exist. CMyOpenDlg has a function called
SetListView that does what its name claims. This function also displays
TRACE diagnostics indicating whether it was able to find the list control.
As the TRACE stream in Figure 3 shows, the list view doesn't exist when
either WM_INITDIALOG or CDN_INITDONE arrives. In both cases, GetDlgItem
returns NULL. So what can you do? The simplest workaround is to have your
dialog post a message to itself:

neat trick   :U

[raleeper]

A .h file is a C header file, the dlgs.h comes with the PSDK for one.

Thank you.  I do have it, in C:\Program Files\Microsoft Platform SDK\Include\.

Sorry to be obtuse.