using OpenFileDialog

  • Thread starter Thread starter Burt
  • Start date Start date
B

Burt

I am new to VC++ and .NET, so this is a pretty basic question...

I want to use OpenFileDialog. Where is the header for it?

And in general, how do I find the right header to include in cases like this
within .NET? I would thought that

#include <OpenFileDialog.h>

would do the trick, but there ain't no such beast apparently.

Quite a few example programs I find on the net use

using namespace System::Windows::Forms

but I am told that 'System' is not a namespace. This is unmanaged code, so
I don't think I can use namespace?
 
Burt said:
I want to use OpenFileDialog. Where is the header for it?
...
but I am told that 'System' is not a namespace. This is unmanaged code,
so ...
Click to expand...

You are writing an unmanaged application and what to use .Net's
OpenFileDialog? Wouldn't you be better of with the likes of
GetOpenFileName() in an unmanaged code?

Regards,
Will
 
Apparently so, now that I know about it... :-)

Sure wish MSDN would provide pointers like that. This seems to do exactly
what I was looking for. thanks!
 
Burt said:
I am new to VC++ and .NET, so this is a pretty basic question...

I want to use OpenFileDialog. Where is the header for it?

And in general, how do I find the right header to include in cases like this
within .NET? I would thought that

#include <OpenFileDialog.h>

would do the trick, but there ain't no such beast apparently.
Click to expand...


..NET facilities are not placed in headers/.cpp files but in dlls.

Quite a few example programs I find on the net use

using namespace System::Windows::Forms

but I am told that 'System' is not a namespace. This is unmanaged code, so
I don't think I can use namespace?
Click to expand...


namespaces can be used in both managed and unmanaged code (have you heard of namespace
std?), try placing:

#using <mscorlib.dll>
#using <System.dll>
#using <System.Data.dll>
#using <System.Drawing.dll>
#using <System.Windows.Forms.dll>
#using <System.XML.dll>


Those will be sufficient for a typical GUI application. However VC++ should use them
implicitly for you.


You can compile unmanaged code together with managed code by using /clr.
 
Burt said:
Apparently so, now that I know about it... :-)
Click to expand...

I'm glad you found what you need.
Sure wish MSDN would provide pointers like that. This seems to do exactly
what I was looking for. thanks!
Click to expand...

You are welcome.

Some rambling ...

1) I think I heard that there are "millions" of pages on MSDN. Keeping it
straight in magnetic or gray matter is a huge undertaking. :-)

Google is good at that sort of thing so I tend to use it to find things on
MSDN. Just append

site:msdn.microsoft.com

to a google query.

2) If you don't find what you need, or if you don't go there first, come
back here. Chances are that someone will help you out.

3) It is usually best to describe _what_ you want to do and not _how_ you
want to do it. I was about to answer the question you asked when I realized
you probably didn't want to go down that path.

4) Due to personal bias and experience, I don't usually suggest MFC
solutions to problems. But _you_ might want to look at its CFileDialog class
as it probably best approximates the .Net class you happened on in the docs

Regards,
Will
 
William DePalo said:
Some rambling ...

1) I think I heard that there are "millions" of pages on MSDN. Keeping it
straight in magnetic or gray matter is a huge undertaking. :-)

Google is good at that sort of thing so I tend to use it to find things on
MSDN. Just append

site:msdn.microsoft.com

to a google query.
Click to expand...

Good suggestion. I'll keep it in mind. I often find references to MSDN
in my Google searches even without adding the site though.
2) If you don't find what you need, or if you don't go there first, come
back here. Chances are that someone will help you out.
Click to expand...

I was delighted to have the answer in under an hour. :-)

I used to frequent the programming lounges that related to my work (Mac
for 15 years, Java for 7 years, etc). I have been pretty much out of
the game for the past 3 years though (dot-bomb bit me, and suddenly my
35 years of experience was a liability rather than an asset), and am
just getting back into it. This is my first foray into Windows
programming via C++. I've written several Java apps for Windows though.
3) It is usually best to describe _what_ you want to do and not _how_ you
want to do it. I was about to answer the question you asked when I realized
you probably didn't want to go down that path.
Click to expand...

I didn't even realize there were separate frameworks for managed and
unmanaged code until this thread. I thought that was just a compiler
flag that redefined Object constructors/destructors to manage memory for
me. Shows how little I know about this new game... I've only been in it
for 2 weeks. :-)

In this case, I knew I wanted to open a file, so I Googled and found
OpenFileDialog. Looked reasonable, so I went to use it and hit a
completely unexpected wall. I never even thought that might not be the
right Class for unmanaged code.
4) Due to personal bias and experience, I don't usually suggest MFC
solutions to problems. But _you_ might want to look at its CFileDialog class
as it probably best approximates the .Net class you happened on in the docs
Click to expand...

I have no choice in the matter. The client has almost 10 years of
legacy code that is being enhanced for version 10. There is some C#
work being done on new subsystems, but the section I am in uses VC++
MFC, so that is what I need to learn quickly.
 
Burt said:
I have no choice in the matter. The client has almost 10 years of
legacy code that is being enhanced for version 10. There is some C#
work being done on new subsystems, but the section I am in uses VC++
MFC, so that is what I need to learn quickly.
Click to expand...

In case you are interested in .NET C++ programming by using VC++ 2003, a very nice book is
http://vig.prenhall.com/catalog/academic/product/0,1144,0134373774,00.html


It is basic to intermediate level and covers all/most .NET features, including multithreading.


If you can wait for VC++ 2005 though, my suggestion is wait and learn about that (of
course the .NET knowledge migration from VC++ 2003 to 2005 is easy, but if you can wait
for about 6 months and are permitted to use 2005 in your job, then why not learning about
2005 directly and its new features).
 
Ioannis Vranos said:
In case you are interested in .NET C++ programming by using VC++ 2003, a
very nice book is
http://vig.prenhall.com/catalog/academic/product/0,1144,0134373774,00.html


It is basic to intermediate level and covers all/most .NET features,
including multithreading.


If you can wait for VC++ 2005 though, my suggestion is wait and learn
about that (of course the .NET knowledge migration from VC++ 2003 to 2005
is easy, but if you can wait for about 6 months and are permitted to use
2005 in your job, then why not learning about 2005 directly and its new
features).
Click to expand...

Our product will be shipping before VC++ 2005 is out, so I can't wait.
I will likely make that migration when the time comes, but I need to get
up to speed fast now.

What I really miss is the equivalent of "The Java Developer's Almanac"

http://www.amazon.com/exec/obidos/ASIN/0201752808/qid=1114285237/sr=2-1/
ref=pd_bbs_b_2_1/002-0551388-0066406

I wore my copy out so badly the pages were falling out, and i had to buy
a new copy -- and that one is pretty ragged now too. A simple,
small-type condensed listing of every Class and every method in Java
Swing. The parameters are listed, but no statement of what the Class or
method does or how to use it.

I find that I often turn to it to see the methods that are available.
They are so intuitively named that I rarely have to look up how to use
them or what they do. Just the name and parameter list is enough.

I had expected MSDN to be able to fill that role Online, but it takes an
exorbitant amount of time to reach such a simple list of methods in many
cases.

This new wrinkle of managed vs unmanaged code frameworks now has to be
absorbed by my tired brain too. The client had tried managed code, but
found it was so massively slow that the developers couldn't stand it,
let alone what customers would have said. They then changed to
unmanaged code, and performance is quite acceptable.

That was all done prior to my arrival though. I only hear of it as
"lessons learned" over the past few months.
 
Burt said:
This new wrinkle of managed vs unmanaged code frameworks now has to be
absorbed by my tired brain too. The client had tried managed code, but
found it was so massively slow that the developers couldn't stand it,
let alone what customers would have said. They then changed to
unmanaged code, and performance is quite acceptable.

That was all done prior to my arrival though. I only hear of it as
"lessons learned" over the past few months.
Click to expand...


I am not sure there is so much penalty of managed vs unmanaged code, especially with C++.
Managed DirectX vs unmanaged has a time-cost of about 2% (that is, it has 98% of the
efficiency of the unmanaged DirectX).


In regular applications personally I do not see any difference at all.
 
Back
Top