The MASM Forum Archive 2004 to 2012

I can't find anything in the SDK help or elsewhere on how to open such a window.

It seems to me there ought to be a function that takes as input size, position, etc. and path, and returns on success a pointer to the selected path/filename string.

Can anyone help?

Thanks, ral

Search the forum for GetOpenFileName and GetSaveFileName.

removed the code in this post - see my next post

Quote from: jj2007 on June 25, 2011, 08:58:21 PM
Search the forum for GetOpenFileName and GetSaveFileName.

Thank You!
Exactly what I wanted.

dedndave:

This looks great.  It will take a while to digest.

Thank you, ral

here is a link to the same code - but simplified for better understanding
it also includes the FnAlloc and HFree routines

http://www.masm32.com/board/index.php?topic=16800.msg139721#msg139721

Ah.  I have it working.  Thanks to jj2007 and dedndave.

Now the next question.  How about a tip on how to get the (or any) dialog window to appear initially in a specified location?

you can use the MoveWindow function (simple)
or SetWindowPos (more complicated - more controls)

works for any window - all you need is the handle to the window
in some cases, you get the handle, by whatever means, then use GetWindowRect to get the current position and size
then use MoveWindow or SetWindowPos, as needed

one way to get the handle of the specific dialog you are talking about is to write a simple hook for it
there are a variety of other methods used to get window handles
EnumWindows
EnumChildWindows

some handles are a little harder to get - like menu handles and balloon tips   :P

Excellent!  Looks eminently doable.  Thanks

Quote from: dedndave on February 07, 2012, 04:10:16 AM
you can use the MoveWindow function (simple)
or SetWindowPos (more complicated - more controls)

works for any window - all you need is the handle to the window
in some cases, you get the handle, by whatever means, then use GetWindowRect to get the current position and size
then use MoveWindow or SetWindowPos, as needed

one way to get the handle of the specific dialog you are talking about is to write a simple hook for it
there are a variety of other methods used to get window handles
EnumWindows
EnumChildWindows

some handles are a little harder to get - like menu handles and balloon tips   :P

if you write a hook procedure for GetSaveFileName or GetOpenFileName,
you simply put the address of the hook procedure in the OPENFILENAME structure, lpfnHook member
in the hook, you should be able to trap the WM_INITDIALOG message and set the position
the dialog window handle is one of the parameters passed to the hook proc

i was playing with some code for this

i noticed one thing that i had not noticed before
in my original code, i used NULL for the hWndOwner member - meaning the dialog has no parent window (actually, the desktop is the parent)
doing this allows the dialog to pop up outside of the parent window coordinates
i wanted to assign a parent window so that i could use parent client coordinates as a reference
when i changed the hWndOwner member, the dialog pops up at client (parent) coordinates 0,0
maybe this is what you were trying to achieve to begin with

Here is a nice example

I think it was from Gunner

i like it   :P

here is one that sets the initial position of the Open File dialog box

1.  I want to set the position relative to my main window - I had already seen this and used its handle instead of NULL.
2.  Ultimately I want to set the position as near the current position of the mouse cursor as possible, or more precisely, in the position that minimizes the distance to the first displayed item in the file list.

Thanks, ral

Quote from: dedndave on February 07, 2012, 05:59:36 PM
i was playing with some code for this

i noticed one thing that i had not noticed before
in my original code, i used NULL for the hWndOwner member - meaning the dialog has no parent window (actually, the desktop is the parent)
doing this allows the dialog to pop up outside of the parent window coordinates
i wanted to assign a parent window so that i could use parent client coordinates as a reference
when i changed the hWndOwner member, the dialog pops up at client (parent) coordinates 0,0
maybe this is what you were trying to achieve to begin with

you can use GetCursorPos to get the mouse cursor position
it wouldn't be very simple to get the location of the first item on the list, however   :P
still, you can estimate it close enough
set the hWndOwner member back to NULL
let me see if i can get you close - give me a few minutes.....

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

Thanks, dedndave!

This will take a while to digest.

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

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

without uxtheme and with
(http://img846.imageshack.us/img846/7342/uxtheme.png)

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

Quote from: dedndave on February 10, 2012, 01:35:27 AM
well - with the manifest, InitCommonControlsEx allows for xp "uxtheme" appearance of buttons, etc

Even if the flags are all 0?

Quoteno 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

QuoteEven 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
        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

QuoteYour 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

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

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

Quote from: dedndave on February 10, 2012, 01:56:58 PM
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

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.

Quote from: Gunner on February 11, 2012, 01:36:37 AM
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.

Quote from: Gunner on February 11, 2012, 01:36:37 AM
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

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

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

QuoteProblem 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

reading further....

QuoteProblem 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

Quote from: Gunner on February 11, 2012, 02:51:12 AM
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.

Quote from: dedndave on February 11, 2012, 03:53:56 AM
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

Quote...the list control isn't a direct child of the dialog, it's a grandchild. ... the main dialog has a child window whose class name is
SHELLDLL_DefView; this, in turn, contains the list control of files and folders ... 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

So to get the handle of the dialog window you have to

invoke GetParent,[esp+4]
invoke GetParent,eax?

Your code, tranfigured (mangled) by me, works, sort of - it (looks like it) moves the dialog window, but also destroys some of its features.

Empirical programming indeed.  But I would never have thought of any of the article stuff on my own.

Thanks, ral

Quote from: raleeper on February 11, 2012, 10:44:42 AM
So to get the handle of the dialog window you have to

Code Select Expand

invoke GetParent,[esp+4]
invoke GetParent,eax?

No, that gets the handle of the parent of the dialog (or at least, it is the parent of  the dialog, ie the original window, that is moved when the whole routine is run.)

Thanks, ral

ok - it is a bit confusing - lol

when you install a hook for an Explorer-style Open File dialog, the hook is actually to a child window of the dialog box
so, you use GetParent to find the handle of the dialog box that appears on the screen
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646931%28v=vs.85%29.aspx

QuoteIf you provide a hook procedure for an Explorer-style common dialog box, the system creates a dialog box
that is a child of the default dialog box. The hook procedure acts as the dialog procedure for the child dialog.

Paul goes on to say that the listview control is a child of a child of that dialog   :P
so, we use GetParent, GetDlgItem, and GetDlgItem again, to get the handle to the listview control
however, to get that far, we have to wait for the listview to be created - lol

once you have the handle to the listview control,
you can just use GetWindowRect and assume the first file is near the upper left corner

Quoteit (looks like it) moves the dialog window, but also destroys some of its features.

this is just a matter of picking the right flags
the style you see is the one i prefer   :bg
the one you may be used to has a few network shortcut links on the left side

as for what is in the Dlgs.h file, Paul gives you that info

Quote...lst2 (value 0x0461...

that seems to be the only one that is pertinent to our code

Hutch has placed that EQUate in the windows.inc file
lst2 EQU 461h
i don't know if there is an EQUate for the listview ID (1) - if there were, i think Paul would have mentioned it
i don't see it in Dlgs.h

Quote from: dedndave on February 11, 2012, 12:52:38 PM
ok - it is a bit confusing - lol
...
i don't see it in Dlgs.h

Your post is in digestion.

Thanks, ral

didn't have time, yesterday
had some things to take cre of
maybe i'll have time, today   :P

well - after looking at Paul's code a little more, i think there may be a better way
his code relies on the fact that messages sent via PostMessage are not handled until the queue is otherwise empty
and, while i like that plan for testing code or for playing around, i don't like it as much for a real-world application
i don't want to second-guess how and when messages are pulled from the queue   :P

i have searched around for more information on the SHELLDLL_DefView window class
in this case, MSDN doesn't seem to be the best source
but, there is plenty of material, as it is the same class as that used by the Desktop window
i suppose they use it for Open and Save File dialogs because the network shortcut links are probably handled much the same as Desktop icons

after doing some reading, i also found that the hierarchy may be different for win7, if using something like the Aero theme
so - we can avoid some potential problems by planning our code, accordingly

"normal" hierarchy
Open File dialog window
+ SHELLDLL_DefView (ID = lst2 = 461h)
  + listview control (ID = 1)

possible win 7 hierarchy
Open File dialog window
+ WorkerW window (ID unknown)
  + SHELLDLL_DefView (ID = lst2 = 461h)
    + listview control (ID = 1)

anyways, i think we can look for WM_NOTIFY messages sent from child to parent until we get one we want

Quote from: dedndave on February 12, 2012, 07:18:05 PM
well - after looking at Paul's code a little more, i think there may be a better way
his code relies on the fact that messages sent via PostMessage are not handled until the queue is otherwise empty
and, while i like that plan for testing code or for playing around, i don't like it as much for a real-world application
i don't want to second-guess how and when messages are pulled from the queue   :P

i have searched around for more information on the SHELLDLL_DefView window class
in this case, MSDN doesn't seem to be the best source
but, there is plenty of material, as it is the same class as that used by the Desktop window
i suppose they use it for Open and Save File dialogs because the network shortcut links are probably handled much the same as Desktop icons

after doing some reading, i also found that the hierarchy may be different for win7, if using something like the Aero theme
so - we can avoid some potential problems by planning our code, accordingly

"normal" hierarchy

Code Select Expand

Open File dialog window
+ SHELLDLL_DefView (ID = lst2 = 461h)
  + listview control (ID = 1)

possible win 7 hierarchy

Code Select Expand

Open File dialog window
+ WorkerW window (ID unknown)
  + SHELLDLL_DefView (ID = lst2 = 461h)
    + listview control (ID = 1)

anyways, i think we can look for WM_NOTIFY messages sent from child to parent until we get one we want

And the one we want is CDN_INITDONE?

Thanks, ral

well - not exactly
if we receive any notification from the listview control, we know it has been created and has size
at that point, we can use GetWindowRect to get it's location

thing is - we have to temporarily subclass any parent windows in the hierarchy   :'(
we will sublass the Open File dialog and wait for a notification from either a "WindowW" or "SHELLDLL_DefView" class window
if it's a WindowW class window, we subclass that until the SHELLDLL_DefView class window is created
then, we subclass that and wait for a notification from the listview control
once that happens, we can calculate and set the position of the Open File dialog   :P

at least - that's the plan, for now
i may come up with something a little simpler

dedndave:
I ought to be able to figure this out, but I don't understand the first line below (from your SmallOFN.asm):


        cmp dword ptr [eax].OFNOTIFY.hdr.code,CDN_FILEOK
        jz      OHook1


As I read the documentation, eax (lParam from WM_NOTIFY) is a pointer to an NMHDR structure the members of which are:

   HWND   hwndFrom;
   UINT_PTR idFrom;
   UINT   code;

So I would expect the line to be:

        cmp dword ptr [eax].code,CDN_FILEOK

or

        cmp dword ptr [eax+8],CDN_FILEOK


Where am I going wrong?

Thanks , ral

your code would also work
in fact, the assembler actually generates code that looks like your last example:
        cmp dword ptr [eax+8],5  ;CDN_FILEOK EQU 5
however, i try to follow the documentation   :P

the CDN_FILEOK notification passes a pointer to an OFNOTIFY structure
the first member of that structure is an NMHDR structure, named "hdr"

CDN_FILEOK:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646857%28v=vs.85%29.aspx

QuotelParam
    A pointer to an OFNOTIFY structure.
    The OFNOTIFY structure contains an NMHDR structure whose code
member indicates the CDN_FILEOK notification message.
    The OFNOTIFY structure also contains a pointer to an OPENFILENAME
structure whose lpstrFile member specifies the address of the selected file name.

OFNOTIFY:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646836%28v=vs.85%29.aspx

Quotetypedef struct _OFNOTIFY {
  NMHDR          hdr;
  LPOPENFILENAME lpOFN;
  LPTSTR         pszFile;
} OFNOTIFY, *LPOFNOTIFY;

the NMHDR structure is used this way for many notification messages
in some cases, they don't pretty it up with a structure definition   :bg
they just say "a pointer to an NMHDR structure, which is followed by..."

i haven't played with the GetOpenFile/GetSaveFile functions for a while
it could be that my code that parses the added extension is unnecessary   :P
these functions have a lot of variations, which explains the size of the OPENFILENAME structure - lol

for the lpstrDefExt member of the OPENFILENAME structure, i pass a pointer to the string: 'txt',0
my thinking there is; if the user enters no extension at all, the default will be used
i could probably avoid the problem by using a NULL value for that member

well - it seems i may have found a better way   :P
not sure how well it will work under win 7, though

i wrote some test code that subclasses the Open File dialog box
the DlgProc looks like this
OfnDlgProc PROC hwndDlg:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

        cmp     uMsg,WM_NOTIFY
        mov     eax,nCount
        jnz     ODPr90

        inc     eax
        jz      ODPr90

        mov     nCount,eax
        INVOKE  GetDlgItem,hwndDlg,lst2
        or      eax,eax
        jz      ODPr90

        INVOKE  GetDlgItem,eax,1
        or      eax,eax
        jz      ODPr90

        push    ebx
        push    eax
        mov     ebx,ustr$(nCount)
        pop     eax
        mov     nCount,-1
        INVOKE  MessageBox,NULL,ebx,uhex$(eax),MB_OK
        pop     ebx

ODPr90: INVOKE  CallWindowProc,hDlgPrev,hwndDlg,uMsg,wParam,lParam
        ret

OfnDlgProc ENDP

while no WM_NOTIFY messages are received from either the lst2 control or the listview control,
those controls are present when the first WM_NOTIFY message is received   :P

got it up and running
i need to do some clean-up - tomorrow   :P

playing with this thing, this morning...

it seems to work ok, but...
if i move the main window down to the lower right corner of the screen
then, open file...
i can catch a brief glimpse of the open file dialog window as it is drawn in the upper-left corner of the screen, before it is moved
this happens when hwndOwner is set to NULL
if i use the main window as the owner, the box is drawn inside the client area (same coordinates - 0,0)
however, the box does not seem to like being moved to a location with negative client coordinates
i want to play with that some more - seems like it ought to work

i can use ShowWindowAsync to hide the window until it is moved, which helps a little, but does not eliminate it
i may be able to set hwndOwner to the main window, then change the parent to HWND_DESKTOP with SetParent   :P

in reading the SetParent documentation, i noticed a neat little trick...

QuoteIf this parameter is HWND_MESSAGE, the child window becomes a message-only window.

i can see where that could be useful   :U

ok - there is no problem with moving the window when hwndOwner is set to the main window
i had merely miscalculated the position   :P
that makes things kind of simple

this is a great technique
once you have the handle to the open file dialog listview control, you can do some fun stuff, like...
set the view mode (list, details, icons, tiles, thumbnails)
set the listview background colour
you can even put a background image in there, if you like   :bg
(no - not a picture of you, but a grey-shade logo might be cool)

we need someone to test it under windows 7 with aero glass theme
the open file dialog box is supposed to come up with the first listview item under the cursor

one thing i do in there, is un-subclass the dialog when done
that step could probably be skipped - there is no harm in leaving it subclassed, really
i set a flag (OfnFlag) to indicate the move has been done

Ral: thanks for starting this thread - i had fun and learned a lot   :U

EDIT: updated the attachment in post #52

That looks cool, Dave :U

Minor suggestion: Details preselected, sorted by date (youngest files on top) :thumbu

thanks, Jochen

funny you should say that about details, youngest on top
i have that exact setting as my default mode in explorer   :P
it took a little getting used to - and sometimes, i have to change it to alpha-name, but i like it so far

Quote from: dedndave on February 15, 2012, 09:36:48 PM
funny you should say that about details, youngest on top
i have that exact setting as my default mode in explorer   :P

Standard settings for developers who create and save a new version once a day ;-)

well i sent a message...
        INVOKE  SendMessage,hOfnLv,LVM_SETVIEW,LV_VIEW_DETAILS,0
but, i can't figure out how to force it to update
if i right-click in the listview, it refreshes in detail mode, so i know the message is getting received   :P
i was playing with LVM_UPDATE and LVM_REDRAWITEMS, but i am not sure what to use for wParam and lParam

well - this is kinda hokee, but it does work   :P

        INVOKE  SendMessage,hOfnLv,LVM_SETVIEW,LV_VIEW_DETAILS,0
        INVOKE  PostMessage,hOfnLv,WM_RBUTTONDOWN,MK_RBUTTON,0
        INVOKE  PostMessage,hOfnLv,WM_RBUTTONUP,0,0
        INVOKE  PostMessage,hOfnLv,WM_LBUTTONDOWN,MK_LBUTTON,0
        INVOKE  PostMessage,hOfnLv,WM_LBUTTONUP,0,0

there must be a better way

You tried sending this to the list view parent?
   ODM_VIEW_DETAIL   EQU 0702Ch
   invoke SendMessage, hLvP, WM_COMMAND, ODM_VIEW_DETAIL, 0

no luck, there - i must be doing something wrong
i don't find much in the way of documentation for ODM_VIEW_DETAIL   :(

in fact, Paul DiLascia's article that i mentioned before, is the only place i see it - lol

hang on - i sent the message to the dialog
it needs to go to the SHELLDLL_DefView window

that works - thanks, JJ   :U

let me do some cleanup, then i'll post

ok - cleaned up version

i included both - one with list view and one with detail view, for comparison

again, we need someone to test this with windows 7 aero glass theme
the Open File dialog should open with the first file in the list under the cursor
much appreciated   :U

Quote from: dedndave on February 16, 2012, 02:39:24 AM
that works - thanks, JJ   :U

That's what I use in RichMasm's WM_NOTIFY/CDN_FOLDERCHANGE handler...

You can comment out
;        INVOKE  SendMessage,hOfnLv,LVM_SETVIEW,LV_VIEW_DETAILS,0

that sets the style for the listview control
i take it the WM_COMMAND message takes care of that, then ?

Some final thoughts (now that I have this working pretty much as I want):

1. I probably couldn't have done it without the helpful posts by dedndave and others.

2. My original objective was to move the dialog window to (a function of) the current position of the mouse cursor.  I soon realized that I didn't care where the mouse cursor was; what I wanted was to move both box and mouse to a place on the screen where it would not cover up anything, or if that were not possible, at least nothing important.  (My method of finding an appropriate location is peculiar to to my large program and has no general application).

3. Later I'll work on 1) changing the size of the file list (up to a limit, it should be just large enough to show all the items in the folder without scrolling), 2) changing the initial keyboard focus from the text entry box to the file list (so that a file can be selected without using the mouse), and 3) adding a places bar.  Sources to which I was led by the mentioned helpful posts contain clues for doing this, but for now I am satisfied.

Thank you very much.
Robert

Quote from: ragdog on February 07, 2012, 06:37:11 PM
Here is a nice example

I think it was from Gunner

Hi I have seen this thread ...and I tried this and I get 2 errors
Line 172 CDN_SELCHANGE
Line 185 CDN_FILEOK

I tried fixing this with any value but the Icons will not display ? why?


I tried
CDN_SELCHANGE  EQU "what ever #"
CDN_FILEOK EQU "what ever #"

LOL I actually had a real # value there

I found this thread :
http://www.masm32.com/board/index.php?PHPSESSID=d23245e28ff6e99889e99b38593d683c&topic=10497.0
Thank you

This guy has crazy values for them here : http://code.google.com/p/analog-box/source/browse/abox/trunk/system/win32A_imp.inc?r=22#5029

by the way you could down load the whole source code for this MASM example

he has:

  ;// Notifications when Open or Save dialog status changes
        CDN_INITDONE            EQU 0FFFFFDA7h
        CDN_SELCHANGE           EQU 0FFFFFDA6h
        CDN_FOLDERCHANGE        EQU 0FFFFFDA5h
        CDN_SHAREVIOLATION      EQU 0FFFFFDA4h
        CDN_HELP                EQU 0FFFFFDA3h
        CDN_FILEOK              EQU 0FFFFFDA2h
        CDN_TYPECHANGE          EQU 0FFFFFDA1h

From CommDlg.h

Quote#define CDN_FIRST   (0U-601U)
#define CDN_LAST    (0U-699U)

// Notifications from Open or Save dialog
#define CDN_INITDONE            (CDN_FIRST - 0x0000)
#define CDN_SELCHANGE           (CDN_FIRST - 0x0001)
#define CDN_FOLDERCHANGE        (CDN_FIRST - 0x0002)
#define CDN_SHAREVIOLATION      (CDN_FIRST - 0x0003)
#define CDN_HELP                (CDN_FIRST - 0x0004)
#define CDN_FILEOK              (CDN_FIRST - 0x0005)
#define CDN_TYPECHANGE          (CDN_FIRST - 0x0006)
#if (NTDDI_VERSION >= NTDDI_WIN2K)
#define CDN_INCLUDEITEM         (CDN_FIRST - 0x0007)
#endif // (NTDDI_VERSION >= NTDDI_WIN2K)


#define CDM_FIRST       (WM_USER + 100)
#define CDM_LAST        (WM_USER + 200)

So who knows where that person gotten those values from.

Quote from: Gunner on March 12, 2012, 11:05:10 PM
So who knows where that person gotten those values from.

From CommDlg.h?

include \masm32\include\masm32rt.inc
Crazy_INITDONE EQU 0FFFFFDA7h
Crazy_SELCHANGE EQU 0FFFFFDA6h
Crazy_FOLDERCHANGE EQU 0FFFFFDA5h
Crazy_SHAREVIOLATION EQU 0FFFFFDA4h
Crazy_HELP EQU 0FFFFFDA3h
Crazy_FILEOK EQU 0FFFFFDA2h
Crazy_TYPECHANGE EQU 0FFFFFDA1h

CDx_FIRST = -601
CDx_INITDONE =(CDx_FIRST - 0000)
CDx_SELCHANGE = (CDx_FIRST - 0001)
CDx_FOLDERCHANGE = (CDx_FIRST - 0002)
CDx_SHAREVIOLATION =(CDx_FIRST - 0003)
CDx_HELP = (CDx_FIRST - 0004)
CDx_FILEOK = (CDx_FIRST - 0005)
CDx_TYPECHANGE = (CDx_FIRST - 0006)

.code
start:
print str$(Crazy_INITDONE), 9
print str$(CDx_INITDONE), 13, 10
print str$(Crazy_FOLDERCHANGE), 9
print str$(CDx_FOLDERCHANGE), 13, 10
print str$(Crazy_FILEOK), 9
print str$(CDx_FILEOK), 13, 10
inkey "ok"
exit
end start


-601    -601
-603    -603
-606    -606

Yeah I guess some people feel fancy using hex.

I used those values last night and they worked ....nice example Gunner  :U I was looking for something with icons in it ...looks like it also gets the icons from an .exe

CDN_FILEOK              EQU 0FFFFFDA2h
CDN_SELCHANGE           EQU 0FFFFFDA6h

P.S
here is were you can down load that whole source code or just the app to see what it does


http://code.google.com/p/analog-box/downloads/list