If one needs some sort of state in a dialog function, it seems you need some sort of static variable. For example, the hook procedure for GetOpenFileName provides the dialog function with the address of the OPENFILENAME structure on its WM_INITDIALOG call but not on any subsequent calls and the OPENFILENAME structure contains a place for lCustData which could be used to pass information between the dialog procedure and the GetOpenFileName caller. If the dialog function needs either of these states, it seems the only alternative is a static or global variable.
+1
A:
You can use SetProp in WM_INITDIALOG like this KB recommends, or SetWindowLongPtr(..,GWLP_USERDATA) if you have custom controls (template)
Anders
2010-08-30 15:26:32
Im torn. I could give you -1 for mentioning the horrible horrible SetProp API. Or +1 for mentioning the correct way: SetWindowLongPtr with GWLP_USERDATA (or DWLP_USER).Im going with the +1 :)
Chris Becke
2010-08-30 15:49:48
@anders: Is the GWL_USERDATA and GWL_USER data not used by any of uSoft software? I.e. can I assume I can use it?
Mike D
2010-08-30 20:29:13
@Mike D: That is why I said custom controls (in your template), not sure if it is a good idea to set it on the dialog itself or the controls created by MS
Anders
2010-08-30 22:22:07
@Chris Becke: SetProp is what MS tells you to use, ?WLP_USER* on a window you did not create is a bit risky. The only "horrible" thing about SetProp is that you have to remember to remove the prop so you don't leak ATOMs.
Anders
2010-08-30 22:26:40
All the shell dialogs, common and user controls and system dialogs do not use either GWL_USERDATA or DWL_USER. Microsoft has been quite good at ensuring that application programmers have a reliable place to store a context pointer. Problems only typically occur when attempting to sub or superclass some other user made window.
Chris Becke
2010-08-31 05:47:32