using createdirectory in .net

[mohamed123]

Hi

How to use an unmanager api function CreateDirectory in VC++.NET ie.

a managed code application ?

regards

[darwen]

You shouldn't be using raw API calls in a .NET app/library if there is an equivalent in the .NET library.

You should use


System::IO::Directory::CreateDirectory


Darwen.

[mohamed123]

thanx for that
i had searched the docu of msdn but was lost in wildnerness

i have another question

of how to call a Form2 eg. from Form1 ??

in mfc terms , i create a dialog2 and want to call it from the main dialog !!!!

in the vc++.net , i feel like i ve start from scratch , since there is no similarity between MFC and .NET library
pity :confused:

[mohamed123]

tja

got it working

its the same as normal syntax

but one thing confuses me still

the implementation are all done in header file eg. Form1.h

and Form1.cpp just , runs a thread

i googled for documentation on this issue but did not find any thing

could anyone explain this w.r.t normal C++ . ( i.e header defines class and
cpp files implement those class )

:)

[darwen]

Implementation in C++ can either be in a C++ file or in the class definition (inline).

In fact in native C++ any templated classes need to have their implementations inline.

Generally speaking for all classes I put its implementation in a cpp file and the class definition in a .h file - because this aids readability.

I have noticed that when designing forms in C++/CLI using the IDE the code which is generated is all put in the class definition - and is highly unreadable to me.

If you're writing a pure .NET WinForms application I'd highly recommend using C# instead of C++/CLI. The code the IDE generates for forms is far more readable and it'll stop you from getting so confused.

Also I find developing in C# is much quicker and easier than using C++/CLI.

Darwen.

[mohamed123]

Good that i understood the same as you ( w.r.t using IDE in a VC++.NET project)

:rolleyes:

So before i ve been programming with VC++ 6.0 IDE ( ofcource MFC)

It is true what u said that developing a compeletely a windows app is more easier ( lots of support from microsoft with C# )
and its getting difficult to work with VC++.NET

and another thing i realised was that syntax ( as microsoft calls it Manager C++) is different in VC++.NET 2003 as to VS++.NET 2005/2008 which makes it more confusing

Does it mean , future windows application is gonna be with C#

and end of C++ from microsoft

I feel VC++.NET is introduced by microsoft , only is only usable for portability issues between old native C++ code and new .NET libraries

?

:ehh: :confused:

[darwen]

Does it mean , future windows application is gonna be with C#

and end of C++ from microsoft


No and no.

Firstly, the world is moving to C# for windows application - or at least the GUI side of things.

However there are a significant number of MFC applications which most companies would find unprofitable to move to C#. So MFC will still exist for a long, long time to come.

This is NOT the end of C++ from Microsoft. Native C++ is still faster than .NET code so for heavily computationally expensive operations C++ is still the preferred choice. For instance I still use C++ for time-critical operations.

Darwen.

[mohamed123]

Yes thats what i meant

Naitve C++ is not from microsoft

I meant that C++ from microsoft as you said is not computationally efficient
so better off use C++ may be with MFC and NOT .NET libraries

And for typlical windows applications use C# with .NET

It is true that lots of code has been generated with MFC in the years before
so microsoft must support it

So for performance perspective better use C++ ( if in windows use MFC apps and not .NET )

From windows gui apps use C# with .NET

Am i correct ? :)

[darwen]

So for performance perspective better use C++


Not really. I tend to write the computationally expensive routines in a dll in C++ and then interface with them from C# using P/Invoke.

I write all my GUI work now in C# - and write C++ in native dlls when necessary.

Bear in mind .NET isn't slow by any means. The C++ routines I write are bitmap manipulations for real-time video replay which means they need to be very, very fast. For most applications I'd say pure .NET (C#) is fine.

Darwen.