1. OpenFileName - Details as default
Using win32lib via Enhanced IDE as my development platform, is there a way to
ask that the open file name dialog box be opened with the Details view as the
default, and with the resulting view sorted on either file name or in date order
(by user choice)? I would have thought that one of the OFN flags would specify
the view or the sort order, but I haven't found anything that indicates it to be
so.
http://msdn2.microsoft.com/en-us/library/ms646839(VS.85).aspx
is pretty detailed. It seems that the right way to do this is to specify a hook
procedure with the flag OFN_ENABLEHOOK. win32Lib's getopenfilename procedure
allows me to set the flag. However, once that is done, I am a bit lost. It looks
like the lpfnHook needs to be set with a pointer to a hook procedure and then, at
some point, change the view (probably with an appropriately placed
ListView_SetView(hListView,LV_VIEW_DETAILS)
It doesn't appear that the lpfnHook item is exposed to me. But I'm just guessing
at 1/2 of this.
Thanks
Mike
2. Re: OpenFileName - Details as default
Mike777 wrote:
>
> Using win32lib via Enhanced IDE as my development platform, is there a way to
> ask that the open file name dialog box be opened with the Details view as the
> default, and with the resulting view sorted on either file name or in date
> order
> (by user choice)? I would have thought that one of the OFN flags would
> specify
> the view or the sort order, but I haven't found anything that indicates it to
> be so.
>
> <a
> href="http://msdn2.microsoft.com/en-us/library/ms646839">http://msdn2.microsoft.com/en-us/library/ms646839</a>(VS.85).aspx
>
> is pretty detailed. It seems that the right way to do this is to specify a
> hook procedure with the flag OFN_ENABLEHOOK. win32Lib's getopenfilename
> procedure
> allows me to set the flag. However, once that is done, I am a bit lost. It
> looks like the lpfnHook needs to be set with a pointer to a hook procedure and
> then, at some point, change the view (probably with an appropriately placed
>
>
> ListView_SetView(hListView,LV_VIEW_DETAILS)
>
> It doesn't appear that the lpfnHook item is exposed to me. But I'm just
> guessing
> at 1/2 of this.
>
> Thanks
>
> Mike
What you are asking for, which is documented in nan MSDN forum post, is to
directly interact with a dialog box, which are black boxes by dsign.
If there is consolidated significant demand for such things about the standard
Windows dialogs, like color or font picker, find/replace boxes etc, I'll consider
including some stuff in 70.5, or 71.0 if tehnical hurdles are many, which I
suspect.
The following will attempt to explain how to go about that issue, and assumes
some familiarity with Win API programming.
The lpfnHook member isn't exposed directly, but it will in the next version
using getOpenFileNameEx().
The prototype for the OfnProcHook placeholder routine is given in MSDN. You have
to design an Euphoria function with a compatible arg list and set the lpfnHook
member to call_back(routine_id(the_routine)).
As the arg list shows, this function will receive messages. The one of concern
to us is WM_INITDIALOG. wParam is a control handle from the dialog, probably the
Ok button. The lParam won't matter here.
As you figured, we need to know the handle of the listview in the box so as to
send it an LVM_SETVIEW message. Problem is, disalog boxes are designed to hide
the controls they display. Technically, we are going to hack at the std dlgbox.
We have a control handle. From there, GetParent() will provide the handle to the
dialog box. Perhaps we need to call it several times checking the class, but I
don't think so, if the returned control is indeed a button.
Now we have to scan the box whose handle we just reckoned for the listview.
Since this listview is obviously tab stoppable, there is a way to get it, which
is the GetNextDlgItem(hDlg,hCtl,bPrevious) API. Since you don't know whether he
listview is created before or after the Ok button (I bet before), call it first
with bPrevious=1, but be prepared to use 0 if no listvie was found (starting from
hCtl again).
For each succesful return of the function, we check its class name using
GetClassName() and hope to identify a listview. That's how I'd go about it - NOT
TESTED. Btw, the function should return w32True tfor the initial focus to be set.
The method I have seen on the MSDN forum is to use WinSpy to infer the id of the
listview (not a win32lib id!), then call GetDlgItem() on that and retrieve the
handle. A third method would be to check the resource files of a C compiler and
extract the id from there - then convert to handle as above.
If you read till there, you can do it.
CChris
3. Re: OpenFileName - Details as default
Adding to my previous reply: for method #3, the files to hunt for appear to be
FileOpen.dlg and dlgs.h. I don't have a C compiler at hand here in office.
CChris
4. Re: OpenFileName - Details as default
CChris wrote:
>
>
> Adding to my previous reply: for method #3, the files to hunt for appear to
> be FileOpen.dlg and dlgs.h. I don't have a C compiler at hand here in office.
Thanks for the information. I'm not up to the challenge at the moment, so I'll
have to put this one on the back burner.
I know that the sort order of the dialog is determined by the OS, which means
the user has both the right and the obligation to set it via whatever tools the
OS provides (no matter how clunky and inconvenient they might be). In windows,
that is simply done via any explorer window, setting the sort order for a
particular folder the way you want, and selecting Tools|Folder Options|View|Apply
to All Folders. Now, subsequent calls to any dialog that lists files will be
sorted the way you previously set the OS to. So much for sort order.
However, even though the OS allows you to set the view to "details" and will use
that setting when further explorer windows are opened, the getopenfilename dialog
box ignores the OS setting when it comes to the view.
It has to be doable in some sense (such as the method you described) because
some programs maintain a view which is inconsistent with the operating system's
settings. For example, most Microsoft Office programs do this routinely. Some
fairly major software providers don't (Adobe is one that comes to mind).
Obviously, the folks in the Office group have access to methods that other
software developers will never see, so it comes as no surprise to me that Office
has some usability improvements that are basically off limits to others.
Thanks
Mike
5. Re: OpenFileName - Details as default
- Posted by Larry Miller <larrymiller at sasktel?net>
Feb 07, 2008
-
Last edited Feb 08, 2008
Mike777 wrote:
>
> Using win32lib via Enhanced IDE as my development platform, is there a way to
> ask that the open file name dialog box be opened with the Details view as the
> default, and with the resulting view sorted on either file name or in date
> order
> (by user choice)? I would have thought that one of the OFN flags would
> specify
> the view or the sort order, but I haven't found anything that indicates it to
> be so.
>
> <a
> href="http://msdn2.microsoft.com/en-us/library/ms646839">http://msdn2.microsoft.com/en-us/library/ms646839</a>(VS.85).aspx
>
> is pretty detailed. It seems that the right way to do this is to specify a
> hook procedure with the flag OFN_ENABLEHOOK. win32Lib's getopenfilename
> procedure
> allows me to set the flag. However, once that is done, I am a bit lost. It
> looks like the lpfnHook needs to be set with a pointer to a hook procedure and
> then, at some point, change the view (probably with an appropriately placed
>
>
> ListView_SetView(hListView,LV_VIEW_DETAILS)
>
> It doesn't appear that the lpfnHook item is exposed to me. But I'm just
> guessing
> at 1/2 of this.
>
> Thanks
>
> Mike
I found a link to an article in MSDN Magazine that shows how this can be done.
There is some code in C++/MFC. I don't understand the code very well but there
are others on the forum that do.
http://msdn.microsoft.com/msdnmag/issues/04/03/CQA/
Larry Miller
6. Re: OpenFileName - Details as default
Mike777 wrote:
>
> CChris wrote:
> >
> >
> > Adding to my previous reply: for method #3, the files to hunt for appear to
> > be FileOpen.dlg and dlgs.h. I don't have a C compiler at hand here in
> > office.
>
> Thanks for the information. I'm not up to the challenge at the moment, so
> I'll
> have to put this one on the back burner.
>
> I know that the sort order of the dialog is determined by the OS, which means
> the user has both the right and the obligation to set it via whatever tools
> the OS provides (no matter how clunky and inconvenient they might be). In
> windows,
> that is simply done via any explorer window, setting the sort order for a
> particular
> folder the way you want, and selecting Tools|Folder Options|View|Apply to All
> Folders. Now, subsequent calls to any dialog that lists files will be sorted
> the way you previously set the OS to. So much for sort order.
>
> However, even though the OS allows you to set the view to "details" and will
> use that setting when further explorer windows are opened, the getopenfilename
> dialog box ignores the OS setting when it comes to the view.
>
> It has to be doable in some sense (such as the method you described) because
> some programs maintain a view which is inconsistent with the operating
> system's
> settings. For example, most Microsoft Office programs do this routinely.
> Some
> fairly major software providers don't (Adobe is one that comes to mind).
> Obviously,
> the folks in the Office group have access to methods that other software
> developers
> will never see, so it comes as no surprise to me that Office has some
> usability
> improvements that are basically off limits to others.
>
> Thanks
>
> Mike
Don't you remember about the disclosures M$ had to make on its shell API as part
of a settlement, in 2004 I think? So Office developers do have access to a couple
things we don't know about. Actually we can, since you can always access a dll
function by number, but they have the docs...
Btw, I spied on a few file open windows using winspy. One of them used an
ownerdrawn list box, and the other two used a listview, but with different ids. I
just stopped there: you have to dynamically locate the LV, and it's not always a
LV.
CChris
7. Re: OpenFileName - Details as default
Larry Miller wrote:
>
> Mike777 wrote:
> >
> > Using win32lib via Enhanced IDE as my development platform, is there a way
> > to
> > ask that the open file name dialog box be opened with the Details view as
> > the
> > default, and with the resulting view sorted on either file name or in date
> > order
> > (by user choice)? I would have thought that one of the OFN flags would
> > specify
> > the view or the sort order, but I haven't found anything that indicates it
> > to
> > be so.
> >
> > <a
> > href="http://msdn2.microsoft.com/en-us/library/ms646839">http://msdn2.microsoft.com/en-us/library/ms646839</a>(VS.85).aspx
> >
> > is pretty detailed. It seems that the right way to do this is to specify a
> > hook procedure with the flag OFN_ENABLEHOOK. win32Lib's getopenfilename
> > procedure
> > allows me to set the flag. However, once that is done, I am a bit lost. It
> > looks like the lpfnHook needs to be set with a pointer to a hook procedure
> > and
> > then, at some point, change the view (probably with an appropriately placed
> >
> >
> > ListView_SetView(hListView,LV_VIEW_DETAILS)
> >
> > It doesn't appear that the lpfnHook item is exposed to me. But I'm just
> > guessing
> > at 1/2 of this.
> >
> > Thanks
> >
> > Mike
>
> I found a link to an article in MSDN Magazine that shows how this can be done.
> There is some code in C++/MFC. I don't understand the code very well but there
> are others on the forum that do.
>
> <a
> href="http://msdn.microsoft.com/msdnmag/issues/04/03/CQA/">http://msdn.microsoft.com/msdnmag/issues/04/03/CQA/</a>
>
> Larry Miller
The .NET stuff is as obfuscated as ever, but the C++ part is straightforward.
The dialog box has more hierarch than what you can expect. Its core is a
component from a class called SHELL_DefView, that's where the engine is. The
listview I was hinting at is a child from that dialog, and interacting directly
with it is not productive.
Instead, you have to send that window the WM_COMMAND message with the right id.
So we are left with:
1/how to find the window handle;
2/how to send it the message;
3/which id to pass.
1/ Windows won't tell us the handle for its dialog box. The way to go is as I
mentioned earlier: enable a hook procedure for the dialog box, process the
WM_INITDIALOG message there and get the parent of the control whose handle is in
wParam. Now wrap the GetDlgItem() API and ask that handle about the id called
"lst2". lst2 is defined in dlg.h as #0461. (The original code doesn't do this,
because it doesn't get the WM_INITDIALOG message directly, so it posts itself a
custom message and then sends WM_COMMAND on processing it).
2/ Since WM_INITDIALOG is sent "immediately before the dialog is displayed" (it
would trigger a w32HOpen event), sendMessage() will fail on a child. You have to
wrap PostMessage() in kernel32.dll and use that instead. The difference is that,
this way, the message is processed when all other are.
3/ The command codes are listed in the code from the article Larry proided us
with a link, and are as follows on XP:
ODM_VIEW_ICONS = 0x7029,
ODM_VIEW_LIST = 0x702b,
ODM_VIEW_DETAIL= 0x702c,
ODM_VIEW_THUMBS= 0x702d,
ODM_VIEW_TILES = 0x702e
I have no idea on whether these ids vary across Windows versions. They are for
sure undocumented.
Do you now see why ome software developers prefer to implement their own
open/save dialogs?
Thanks, Larry.
CChris
