Robert van Herk wrote:
I guess you are right, but the strange thing is that this was already the case in the original code. The hwnd of the tree view and the pointer to the browseinfo structure are copied into a global variable, so at least my code is not worse here :-).
Well, existing code doesn't necessarily need to be a nice and clean implementation as it may have been at some point more important to get anything workable into the CVS tree than having nothing at all.
By the way, isn't it so that a copy of shell32.dll gets loaded for each application anyway? If so, then the variable is at least application local, and, c'mon, who is going to show two modal browsing dialog boxes at the same time :-)?
I'm not sure if the shell32 dll is really loaded multiple times in Windows.
However I can definitely see your point here but since the functions are all internal to shell32 at this point and can accept any parameters you may like, I would consider it a cleaner solution to allocate a structure on the stack which contains such helper variables together with the pointer to the user supplied BROWSEINFOA structure and pass its pointer as custom long variable to the dialog procedure instead of lpbi only.
In the end it mist probably wouldn't really matter for practical use since it is a modal dialog, but who knows who is going to extend on that API at some point and stumbling over this.
Rolf Kalbermatter