C / C++ / MFC

Re: GetOpenFileName hangs [modified]

3-Nov-07 19:01

Use SHGetFolderPath[^] to get the path of that folder.... then build a filename

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</A>

GetOpenFileName hangs

andrew_dk3-Nov-07 12:31

andrew_dk

3-Nov-07 12:31

I have a simple dll that creates a dialog box with a button on it. The dll is loaded via LoadLibrary by the main application. The dialog box is created when the dll is loaded (ie. in response to DllMain being called with dwReason == DLL_PROCESS_ATTACH). The button when clicked runs the following::

<br />
OPENFILENAME ofn;<br />
TCHAR szFileBuffer[_MAX_PATH + MAX_FNAME + MAX_EXT];<br />
memset(&ofn, 0, sizeof(OPENFILENAME));<br />
szFileBuffer[0] = _T('\0');<br />
ofn.lStructSize = sizeof(OPENFILENAME);<br />
ofn.hwndOwner = hwnd;<br />
ofn.lpstrFilter = _T("Text files (*.txt)\0*.txt\0\0");<br />
ofn.nFilterIndex = 1;<br />
ofn.lpstrFile = szFileBuffer;<br />
ofn.nMaxFile = (_MAX_PATH + MAX_FNAME + MAX_EXT);<br />
ofn.lpstrTitle = _T("Select File");<br />
ofn.Flags = OFN_FILEMUSTEXIST | OFN_HIDEREADONLY | OFN_EXPLORER;<br />
if(GetOpenFileName(&ofn))<br />
{<br />
	...<br />
	return true;<br />
}<br />

If I call this code from within a standard .exe, everything runs fine. However when run from the dll it hangs. The problem is the hwndOwner. If I set this to NULL or to the value passed to the dialog box procedure the process hangs. If I set it to some invalid HWND value GetOpenFileName returns an error value but the process does not hang. Any ideas would be hugely appreciated.

Peter Weyzen3-Nov-07 18:44

Re: GetOpenFileName hangs

3-Nov-07 18:44

Microsoft publishes a "best practices" document (here)[^] which spells out all of the do's and don't of writing a DLL. Read it!

The gist is -- "do as little as possible in DllMain". If you want your DLL to do something, create a function entrypoint.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</A>

andrew_dk3-Nov-07 19:57

andrew_dk

3-Nov-07 19:57

Perfect, fixed. Didn't realise this was the case. Thanks for the information, much appreciated.

Header files #include problem

Oliver1233-Nov-07 11:10

Oliver123

3-Nov-07 11:10

Two classes X and Y.

I want to #include X.h in Y.h
I want to #include Y.h in X.h

I can do one, but not both. I understand that there is a "self-referencing" situation happening here.

What I don't understand is how I can work around this.

What am I trying to do?
Instances of both X and Y are created by an instance of class Z.
I would like X to have a pointer to instance of Y.
I would like Y to have a pointer to instance of X.

In X I have a function that takes Y* as a parameter. Z executes it and that's how I get Y* into X.

In Y I have a function that takes X* as a parameter. Z executes it and that's how I get X* into Y.

This works when Y.h is included in X.h
OR
This works when X.h is includd in Y.h

It will not work with both #includes.

Ideas? Work arounds?

Thanks

David Crow3-Nov-07 11:56

David Crow

3-Nov-07 11:56

Oliver123 wrote:
What I don't understand is how I can work around this.

Check out the #pragma once directive.

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Bram van Kampen3-Nov-07 12:39

3-Nov-07 12:39

What you need is a Foward Declaration. e.g.

<br />
  class Y;<br />
  class X{<br />
       .<br />
       .<br />
       .<br />
       Y* m_pY;<br />
       .<br />
       .<br />
       .<br />
  };<br />
<br />
  class Y{<br />
       .<br />
       .<br />
       .<br />
       X* m_pX;<br />
       .<br />
       .<br />
       .<br />
};

The First Line: class Y; informs the compiler that thrte will be a class named Y, whatever it's nature. You cannot use the class at that stage, because the compiler does not know what's in it, and for instance the size in memory would be unknown. The compiler has enough information though, to allow you to use a pointer to an instance of type class Y . This method og allowing a forward declaration was included in the language precisely to get around the deadlock situation you described.
Hope this is of help. Smile | :)

LateNightsInNewry

Oliver1233-Nov-07 13:58

Oliver123

3-Nov-07 13:58

I did this, and it successfully compiled.

Passed a pointer to class Y into class X.
Passed a pointer to class X into class Y.

When I try to use Y* in X, the compiler says Y is undefined.
When I try to use X* in Y, the compiler says X is undefined.

So, when using forward references, where does the compiler eventually get the definition of Y so it can be used as Y* in X? Is there some type of ordering of what is presented to the compiler?

Thanks

Peter Weyzen3-Nov-07 19:13

3-Nov-07 19:13

Just to add a little more confusing detail:

If you just reference the object by pointer or reference (either inside the class data or in a function declaration) then you can get away with just a forward reference.

In these cases the size of the object is fixed -- the size of a pointer. And since you're not using the other class, it needs to know nothing about the functions in it...

If you declare an instance of class or override an class -- then you must include the header. In this case, the compiler needs to actually know something about the object to compile (like the size of the other class, what virtual functions it has, ... )

Sorry if this is a little confusing. The gist is -- don't include the header until the object is actually used. And always try to use a forward declaration.... if you can.

Oh, and always use "#pragma once" too

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</A>

Vaclav_4-Nov-07 5:30

Vaclav_

4-Nov-07 5:30

<blockquote class="FQ"><div class="FQA">Peter Weyzen wrote:</div>Sorry if this is a little confusing. The gist is -- don't include the header until the object is actually used. And always try to use a forward declaration.... if you can.</blockquote>

I always get myself into trouble by not keeping track of #include statements and try to resolve it by adding my #include statement into stdafx.h header.
Sometime it makes even more mess.

My question - is this a good way to code in MFC ?
For extreme - could one do all class forward declarations in stdafx.h?

Peter Weyzen4-Nov-07 6:36

4-Nov-07 6:36

I think you'd do the best service if you "crafted" each header to include only what it needs. It should be able to stand on it's own....

But you should decide what that is -- for your project. There's no perfect way to do it.

One of my bosses would always complain about how long the project took to build. So, being the boss that he was, he demanded that all headers got included into stdafx... this caused them all to be precompiled and sped up the build.

The downside was that everything got built all the time as you changed headers....

It wasn't a particularly great style -- not something I thought highly of -- but it was the way we did things at that job.

Do what's works for you and your work environment.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</A>

Bram van Kampen4-Nov-07 11:49

4-Nov-07 11:49

Vaclav_Sal wrote:
For extreme - could one do all class forward declarations in stdafx.h?

Vaclav_Sal wrote:
My question - is this a good way to code in MFC ?

Answers: No!, and Bad Practice!

Keeping Track of things is one of these things we have to do when writing code. Planning your Code and File Organisation is an important part of your design process.

Regards, Smile | :)

Bram van Kampen

Bram van Kampen4-Nov-07 11:11

4-Nov-07 11:11

Your compiler reads your source file line by line. the #include directive means exactly that: 'include' It is conceptually as if at that point the entire file to be included is copied and pasted to the location of the #include directive. What the compiler digests is your cpp file, with at all levels the #include directives removed and replaced by the contents of the file to be included. This is one of the functions of the Pre-Processor. (Note that the compiler proper knows nothing about header files, it compiles the cpp file after the Pre-Processor has expanded it.) So, the ordering of things depends on the ordering of your #include file directives, and on the order of the statements in your header files.

Similar Sample with Line Numbers:

1  class X;<br />
2  class Y{<br />
3   X* m_pX;<br />
4  };<br />
5  class X{<br />
6   Y* m_pY;<br />
7  };

The Class X is forward declared at line 1
The forward Declaration is used in line 3
The Class Declaration for class Y is completed on line 4
The Class Declaration for class X starts on line 5;
The Class declaration for class X uses class Y on line 6.This can be done without a forward declaration, because class Y is fully declared after line 4.
The Class Declaration for X completes at line 7.
If you try to do anything of the kind of *m_pX before the end of line 7 you get an error, you dereference something that has not been completely declared.

Hope this clarifies things.

N.B. A Note about '#pragma once'
It is not difficult to end up with a 'spagetti' of include files, and at some stage inevitibly a file would be included twice. This gives all sorts of problems, and the compiler usually chokes on this, but this situation is often hard to unravel.
The directive '#pragma once' tells the preprocessor to check if the particular file has already been included, and, if so to ignore the #include directive.

Best of Luck Smile | :)

Bram van Kampen

Oliver1234-Nov-07 11:33

Oliver123

4-Nov-07 11:33

The fog begins to clear a bit.

Question: In your example, all the statements are in one file. However, VC++ creates individual header files for each class. To emulate what you have shown, we would have to control of the order in whch the header files are presented to the compiler. Correct? Can we give the compiler the header.h files in the order it needs them while still maintaining the very convenient system of one header file per class? Is there a way to do this?

Thanks

Bram van Kampen4-Nov-07 12:17