Prev: Applying windows 7 theme in MFC application
Next: "Window Explore": implement "tree view" and "Folder view"
From: Joseph M. Newcomer on 21 Sep 2009 02:10
See below...
On Sat, 19 Sep 2009 22:37:01 -0700, Daum <Daum(a)discussions.microsoft.com> wrote:

>I used the way below which are from internet and it works.
>
>But I don't know if it is the best way.
>
>Thanks
>
>-Daum
>
>#include "shlobj.h"
>#include <string>
>
>bool GetFolder(std::string& folderpath,
****
It is usually a Bad Idea to mix CString and std::string, and there is no discenable
advantage in MFC code for using std::string
> const char* szCaption = NULL,
****
char is obsolete. Do not use it. Why not use a CString?
****
> HWND hOwner = NULL)
>{
> bool retVal = false;
>
> // The BROWSEINFO struct tells the shell
> // how it should display the dialog.
> BROWSEINFO bi;
> memset(&bi, 0, sizeof(bi));
>
> bi.ulFlags = BIF_USENEWUI;
> bi.hwndOwner = hOwner;
> bi.lpszTitle = szCaption;
>
> // must call this if using BIF_USENEWUI
> ::OleInitialize(NULL);
****
This should happen back in your InitInstance handler
****
>
> // Show the dialog and get the itemIDList for the
> // selected folder.
> LPITEMIDLIST pIDL = ::SHBrowseForFolder(&bi);
>
> if(pIDL != NULL)
> {
> // Create a buffer to store the path, then
> // get the path.
> char buffer[_MAX_PATH] = {'\0'};
****
char is obsolete.
****
> if(::SHGetPathFromIDList(pIDL, buffer) != 0)
> {
> // Set the string value.
> folderpath = buffer;
> retVal = true;
> }
>
> // free the item id list
> CoTaskMemFree(pIDL);
> }
>
> ::OleUninitialize();
>
> return retVal;
>}
>/////////////////////////////////////////////////////////////////////////////
>// CDialogCreateVolume message handlers
>void CDialogCreateVolume::OnCreatVolumePath()
>{
>
> CString folderPath;
> std::string szPath("");
****
Using std::string has no value in MFC code, so why bother with it?
****
>
> if (GetFolder(szPath, "Select a folder.") == true)
*****
It is remarkably silly to compare a bool value to a bool literal! The bool value BY
ITSELF is testable! Comparing it to == true is like writing
if(a > 0 == true)
****
> {
> folderPath = CString (szPath.c_str());
****
It would be so much simpler if you just used a CString!
****
> MessageBox(folderPath);
> }
> else
> {
> MessageBox("No folder selected!\n");
> }
>}
>
****
This is pretty much what everyone does. But stop using char as if it is a useful data
type in this context (it is obsolete) and don't use std::string in MFC code.
joe
****
>
>"Daum" wrote:
>
>> My dialog box has a combo box that gets a path string from key board input.
>>
>> Also, the dialog box has a push button that pop-ups browsing folder dialog
>> so that users can select a path using a mouse instead of key board input.
>>
>> Q) How to make pop-up the browsing folders? I believe the "browsing folder"
>> dialog is already built in by MFC.
>>
>> Q) Also, how to get the user selection from the pop-ups browsing folders?
>>
>> Thank you so much for the help.
>>
>>
>> - Daum
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Giovanni Dicanio on 21 Sep 2009 11:27
Joseph M. Newcomer ha scritto:

>> if (GetFolder(szPath, "Select a folder.") == true)
> *****
> It is remarkably silly to compare a bool value to a bool literal! The bool value BY
> ITSELF is testable! Comparing it to == true is like writing
> if(a > 0 == true)
> ****

Hi Joe,

I think that programming style is very personal thing (like writing style).

I read that Dave Cutler's (the programming guru father of NT) style is
defined as "Cutler Normal Form" or CNF.

According to CNF, it is good to do explicit comparisons for booleans, e.g.

if ( foo != FALSE )
...

You can read about that in some comments in this blog post (the author
of the blog is a developer lead on the User Mode Driver Framework [UMDF]
team at Microsoft):

"Pedantic Coder : Where do braces go?"
http://blogs.msdn.com/peterwie/archive/2008/02/04/pedantic-coder-where-do-braces-go.aspx

BTW: He has also some interesting points about HN as well:

http://blogs.msdn.com/peterwie/archive/2008/10/13/pedantic-coder-hungarian-notation.aspx

All in all, I think that the very important aspect of programming style
is *consistency*, *coherence*.
I mean: I think that a project that uses a mix of different uncoherent
coding styles (like using some style for braces in some part of code and
a different style in other parts of code, or sometimes indentation to
eight spaces, and to four spaces somewhere else, etc.) is not quality code.

My 2 cents,
Giovanni


From: Joseph M. Newcomer on 21 Sep 2009 14:13
See below...
On Mon, 21 Sep 2009 17:27:53 +0200, Giovanni Dicanio
<giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote:

>Joseph M. Newcomer ha scritto:
>
>>> if (GetFolder(szPath, "Select a folder.") == true)
>> *****
>> It is remarkably silly to compare a bool value to a bool literal! The bool value BY
>> ITSELF is testable! Comparing it to == true is like writing
>> if(a > 0 == true)
>> ****
>
>Hi Joe,
>
>I think that programming style is very personal thing (like writing style).
>
>I read that Dave Cutler's (the programming guru father of NT) style is
>defined as "Cutler Normal Form" or CNF.
>
>According to CNF, it is good to do explicit comparisons for booleans, e.g.
>
> if ( foo != FALSE )
> ...
****
Just because Dave Cutler likes it does not mean it is completely silly.
****
>
>You can read about that in some comments in this blog post (the author
>of the blog is a developer lead on the User Mode Driver Framework [UMDF]
>team at Microsoft):
>
>"Pedantic Coder : Where do braces go?"
>http://blogs.msdn.com/peterwie/archive/2008/02/04/pedantic-coder-where-do-braces-go.aspx
****
Nobody really understands braces. The only correct form of braces, which should be
enforced by the language is
if(expression)
{ /* named block */
...
} /* named block */

The matching names of the named blocks should not be done as comments but should be
first-class ideas in the language. Optional, but highly encouraged. Anyone who "knows
where braces go" who has not read AT LEAST Lindsey & Norman's book on cognitive
psychology, and preferrably advanced works in the field, like Newell & Simon, is talking
nonsense. I spent several years studying cognitive psychology with people like Lee Gregg,
Alan Newell and Herb Simon, and my first PhD dissertation attempt was in cognitive
psychology of programming. But it turns out I would have needed three more years of study
to finish it, and my student stipend ran out in about a year. So I did a thesis on
optimizing compilers. I then spent three years post-doc studying it. My brace style is
based on fundamental principles of human cognition, or, more specifically, an analysis (by
the experts) on what we are *not* good at (nested control structures and braces, large
amounts of state management, and concurrency). C++ handles the large amounts of state by
reducing it to small amounts of per-object state; I use rule-based precondition analysis
to avoid deep nesting, and I use named blocks to handle the nesting-logic problem, and I
try to avoid ever writing code that requires synchronization. My attitudes are founded on
fundamental principles of human information processing, not just a casual set of "I like
this way better" arguments.

In the late 1960s I worked with a language that had optional block names, that if used
were rigorously enforced by the compiler. It was a wonderful language to program in. You
*never* got lost in the nesting. It wasn't for many years that I finally realized why
they were so valuable (humans can't handle syntactic nesting very well).

This is also why the "don't use return statements" school of thought is so deadly. It
*requires* deep nesting to avoid return statements. Rule-based precondition analysis
avoids that. Splitting functions up so complex nesting is flattened by the call hierarchy
is a related solution. We can handle abstraction quite well, so call-abstraction is
valuable.

Here's a simple test: have you ever, once, had to print out a listing and start marking up
braces to get things to match because there was a missing brace *somewhere*? Or maybe
because the nesting was so deep you lost track of it? If so, this is a sad commentary on
whatever the brace style is that you use. I never have to, I know where my braces are and
what they mean.
****
>
>BTW: He has also some interesting points about HN as well:
>
>http://blogs.msdn.com/peterwie/archive/2008/10/13/pedantic-coder-hungarian-notation.aspx
>
****
I agree with these points. Abbreviations that are subject to misinterpretation are a Bad
Idea. Even Microsoft can't get it right (look at the structure member names like "DWORD
lpstrAlgorithm" to see how absurd this can be!) Again, if you don't understand cognitive
psychology, talking about "prefixes" as having meaning is spouting nonsense. Suffixes
work better because of the way human beings process visual information like text. Decades
of *real* insight into how human beings work argue against silliness like Hungarian
Notation.
****
>All in all, I think that the very important aspect of programming style
>is *consistency*, *coherence*.
>I mean: I think that a project that uses a mix of different uncoherent
>coding styles (like using some style for braces in some part of code and
>a different style in other parts of code, or sometimes indentation to
>eight spaces, and to four spaces somewhere else, etc.) is not quality code.
****
This is usually the result of multiple coders. My code has looked the same for about
forty years, no matter what language I'm writing in. This allows me to concentrate on the
algorithms and ignore accidents of syntax.
joe
****
>
>My 2 cents,
>Giovanni
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Giovanni Dicanio on 21 Sep 2009 17:14
Joseph M. Newcomer ha scritto:

> if(expression)
> { /* named block */
> ...
> } /* named block */
>

Joe: thanks for sharing your experience and ideas.

I like the /* named block */ thing.
But I think that the IDE should provide some form of IntelliSense help:
e.g. when we end typing the opening named block comment, the IDE should
autocomplete with the closing brace } followed by a copy of named block
comment. Without this kind of IDE assistance, commenting that way slows
down the coding process.

Giovanni
From: Joseph M. Newcomer on 21 Sep 2009 19:56
That's exactly what my editor does. What happens is when I type {. it indents properly,
puts a /* */ in, and leaves me in the middle to type the opening comment. When I type
the }. it reaches up, grabs the opening comment, and copies it down. The last time I
asked, it was not possible to do this in VS, and the VS editor implementor looked at me
and said "but why would you want to make character other than control and alt combinations
be programmable?", which demonstrated a TOTAL cluelessness about the reality of actually
building text editors. The point is that the editor must be TOTALLY programmable, EVERY
keystroke can activate a function, for ANY character (control, alt, and regular text),
function key, etc. I have not bothered to see if the recent rewrites of the editor fix
this glaring design defect.

Note that EMACS-class editors were doing this in the 1970s. I have been using change log
editing functions, procedure headers, block naming, etc. since 1977 (that's 32 years). The
syntax of the language changed slightly over the years, but my current editor has change
logs dating to 1985, so I've spent 24 years training it to optimize editing programs. I
have no reason to reinvest this effort in an editor that by comparison is a toy that
wouldn't have been considered as a pre-alpha grade release in the 1970s.

Besides, Intellisense doesn't work well, and only confuses students (for example, by going
for the W forms of the APIs, showing flags such as "4|2", not handling enumerations, etc.)
It is interesting to watch how badly it works with those who discover it for the first
time. I carry a copy of vim around (I hate vi, by the way) just so my students who
complain can install what they think is a usable editor).
joe

On Mon, 21 Sep 2009 23:14:46 +0200, Giovanni Dicanio
<giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote:

>Joseph M. Newcomer ha scritto:
>
>> if(expression)
>> { /* named block */
>> ...
>> } /* named block */
>>
>
>Joe: thanks for sharing your experience and ideas.
>
>I like the /* named block */ thing.
>But I think that the IDE should provide some form of IntelliSense help:
>e.g. when we end typing the opening named block comment, the IDE should
>autocomplete with the closing brace } followed by a copy of named block
>comment. Without this kind of IDE assistance, commenting that way slows
>down the coding process.
>
>Giovanni
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  | 
Pages: 1 2
Prev: Applying windows 7 theme in MFC application
Next: "Window Explore": implement "tree view" and "Folder view"