|
I have been searching the web, doing a lot of reading. I see that C# and .NET are common. I see very little about VC++ and MFC. Yet the VC++ forum has the highest turnout it seems. Is it advisable for a beginner at programming to start with MFC or should I learn C# now. I was thinking I'd learn Windows programming with MFC, and then later move up to Visual Studio.net and C#. Am I thinking wrong?
Which brings up the next question, how does C# relate to Windows Programming. If VC++ uses C++, then what do you program C# with, Visual Sudio.net? Is C# drastically different than C++? If I learn C++, will C# be totally different. I know C# is more portable, but is it difficult to learn once you learn C++ well?
Ok, enough questions...I'd really appreciate any info on this, thanks, Dave
"The man who reads nothing is better educated than the man who reads nothing but newspapers."- Thomas Jefferson
|
|
|
|
|
I would recommend learning both C# and C++. C# is moving forward rapidly, and is being used both for applications and web design (ASP.NET). It is not radically different from C++, but more similar to Java. C++ will still be used for high-performance computing and applications that require speed, such as presentations, image/video processing, servers etc. Desktop applications are candidates for C#, but C++ will still be predominant for a while yet (that's my opinion anyway). MFC is not good (and never has been) but it will remain in use for a long time.
If you want a book to help with C#, "Inside C#" (2nd ed) by Tom Archer is brilliant.
I'm learning C# at the moment and I don't find it particularly difficult. I know C++ very well, so I can pick up C# reasonably quickly, but don't expect it to take a few days - it will take a decent amount of time.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan,
Can I do everything with C# that I can do with MFC? I'm a bit confused on this. If I'm correct (and please let me know if I'm not), C# is just a language like C++. MFC is something exclusive to Microsoft Windows (and is not a language). So what has replaced MFC if C# is just the language? What program do Microsoft programmers use now to develop their XP programs? Thanks.
|
|
|
|
|
Anonymous wrote:
If I'm correct (and please let me know if I'm not), C# is just a language like C++.
Yes, although they're a bit different. C++ is a compiled language and the executable file can be directly executed. C# is compiled to an intermediate code, similar to Java, which is then interpreted by the .NET runtime when the program is executed.
Anonymous wrote:
So what has replaced MFC if C# is just the language?
The .NET framework class libraries, although there is no document-view built in (well, not that I've found anyway  ).
Anonymous wrote:
What program do Microsoft programmers use now to develop their XP programs?
Visual Studio.NET, although you can use SharpDevelop[^] for C# development, which is free. You'll have to download the .NET framework SDK in this case, though.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
|
 Thanks
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
So what has replaced MFC if C# is just the language?
The .NET framework class libraries, although there is no document-view built in (well, not that I've found anyway ).
I think at present Ms is using ATL to replace the MFC call in the VC.NET
|
|
|
|
|
Anonymous wrote:
What program do Microsoft programmers use now to develop their XP programs?
There is no single "program" they use. One thing is for certain though, for larger projects it's not built from an IDE!
Latest NT5 (I know you asked about XP, but since it's only a point-release I don't expect much to *actually* have changed on this front) service pack apparently (for at least some parts) used an in-house hacked VC6 compiler + linker (linker version 6.1 to be precise), and it seems more and more of the user-mode OS components are built with VC6 why I can't believe they'd be so stupid as to do it in VB or C# for NT 5.1 (XP).
The really critical stuff, kernel mode, still uses older but proven tools. It might be a hacked version from VC5 (linker version 5.12), but I think it's actually a completely different line of tools that have gotten upgraded - since the code generated from that compiler bears little resemblance with code generated by the VC5 compiler.
Then we have other areas, like Office, where I know at least earlier the Excel team used their own compiler.
Having expidited the cash-cows - since MS is a rather large company I think you can find all kind of languages and tools. Even that the languages used (in order of popularity) are mainly C, C++ and assembler - with C# probably somewhere between C++ and assembler. Probably closer to assembler in terms of LOC.
But as for what "program" they use - the question can't be answered. There simply is no silver bullet (a single "program") to fit all needs.
The majority of the code is still C and C++ though, and that won't change anytime soon.
|
|
|
|
|
Ryan,
Can I do everything with C# that I can do with MFC? I'm a bit confused on this. If I'm correct (and please let me know if I'm not), C# is just a language like C++. MFC is something exclusive to Microsoft Windows (and is not a language). So what has replaced MFC if C# is just the language? What program do Microsoft programmers use now to develop their XP programs? Thanks.
|
|
|
|
|
Ryan Binns wrote:
and is being used both for applications
I am wondering does C# have the same problem as Java?? As a result of the Virtual Machine and symbols imbeded in the executable any Java program can easily be decompiled back into source code. Sure you loose the comments and end up with cryptic variable names but the class and member names stay the same. This is one reason (along with performance) that we have avoided Java in the past.
John
|
|
|
|
|
Yes, it's just the same, except that variable names are preserved as well. However, obfuscators are available that make the decompilation process almost useless. CP advertises one, and there are a few free ones available.
I wouldn't avoid C# because of it - just use an obfuscator.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
However, obfuscators are available that make the decompilation process almost useless.
I see... I have seen some of the code that is produced by obfuscators. It is almost impossible to follow...
John
|
|
|
|
|
John M. Drescher wrote:
I have seen some of the code that is produced by obfuscators. It is almost impossible to follow
That's the whole point!  yeah, I know you know 
It basically becomes just as difficult as decompiling a standard Win32 application.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Don't care, C# replaces Visual Basic and not C++. There was always more information about VB than about C++ and MFC. Now part of VB, database and WEB programmers are moving to C#, making a lot of noise. C++ Windows programmers remain with Windows API or MFC programming.
C++ is language specification; Visual C++ is Microsoft C++ implementation.
C# is both language specification and implementation.
MFC is not language, it is kind of library.
C++ is portable. MFC is not portable. C# is portable only in theory, actually it works only in Windows.
|
|
|
|
|
Alex Farber wrote:
C# replaces Visual Basic and not C++.
I disagree. C# is more similar to C++ than VB.NET, and both VB.NET and C# have been pushed very strongly by MS, while C++.NET has received almost no attention.
Alex Farber wrote:
Now part of VB, database and WEB programmers are moving to C#, making a lot of noise.
And C++ programmers as well...
Alex Farber wrote:
C++ Windows programmers remain with Windows API or MFC programming.
Some will, some won't. Most who switch to C# will retain the ability to program in C++. C++ is available under .NET, but hasn't received much attention. Most C++ programmers who use .NET will probably use C# because it's being pushed a lot harder by MS.
Alex Farber wrote:
C# is portable only in theory, actually it works only in Windows.
Not quite. It also works under Macs and FreeBSD.
[sorry about the other post. The damn thing submitted before I'd finished]
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
while C++.NET has received almost no attention.
It is not pushed by the Microsoft marketing machinery. But it is widely used to access any DOT-NET thingies in C++ applications. But as this is silent work, simply done and not advertised publically, you do not hear a lot about it.
Ryan Binns wrote:
Most C++ programmers who use .NET will probably use C# because it's being pushed a lot harder by MS
We will see in a few years time .
Right now, there seems to be some sort of 'play around' phase: everyone tries C# out and reports its problems and findings. Only then project managers will decide what to use.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
Hello,
I am developing an MFC dialog which registers a callback with a certain library. This library will call back at intervals giving new insformation to the dialog. This information should be displayed on the dialog's controls.
The callback comes from a different thread than the thread of my dialog, so my question is:
What method should I use to update my dialog? Should I send messages to the main thread and it do the work, or is it OK to update my controls from within the callback?
I appreciate your input.
Jeremy Pullicino
C++ Developer
Homepage
|
|
|
|
|
Jeremy Pullicino wrote:
Should I send messages to the main thread and it do the work, or is it OK to update my controls from within the callback?
It's perfectly OK to update your controls from a second thread. However, you can't use MFC to do it. You have to use the straight Win32 API to do it. Luckily, updating controls generally uses MFC wrappers that are fairly thin wrappers over the API, so it's not much more work.
Sending messages to the main thread will work just as well, and will allow you to use MFC.
Basically, you can do what you like, depending on whether you want to be able to use MFC or not.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
It's perfectly OK to update your controls from a second thread. However, you can't use MFC to do it. You have to use the straight Win32 API to do it.
Thanks for the feedback.
Just out of curiosity - why can't I use MFC to update my dialog from the second thread?
Jeremy Pullicino
C++ Developer
Homepage
|
|
|
|
|
Jeremy Pullicino wrote:
why can't I use MFC to update my dialog from the second thread?
MFC uses thread-specific data internally. Using MFC objects created in one thread in another thread uses inconsistent internal data, and can cause catastrophic errors, hence MFC incorporates checks to prevent this.
Just for a test, create a window in one thread and do this in another thread:
ASSERT(CWnd::FromHandlePermanent(pWnd->m_hWnd) == pWnd) In a single-threaded application, this will work perfectly as expected, but if pWnd was created in a different thread, FromHandlePermanent() will return NULL because the window map is thread-specific data, and the ASSERT will be triggered.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
|
I want know how i can add highlight and change the text font in a DOC/VIEW application derived from a CRichEditView.I would be glad if anyone could help me out.
|
|
|
|
|
Hi all,
I have a list control with checkboxes and multi-select style.
when i select several items, and then check 1 fo the selected items, i expect the rest of the items to be checked as well...by default it doesn't happened
any1 knows a style of list to fix my problem?
thanks in advanced,
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
YaronNir wrote:
any1 knows a style of list to fix my problem?
There isn't one. You will have to do this yourself whenever the user clicks on an item. Use GetSelectedCount() and GetNextItem() to loop through the selected items and set them all to the state you want.
If you're not using MFC, use the LVM_GETSELECTEDCOUNT and LVM_GETNEXTITEM mesages.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
thanks for the reply!
i am not using MFC, so i will use the LVM_ messages you've mentioned.
you said to catch the user clicks on the item. but what if the user select the item via the keyboard???
is there a certain message that item was selected? no matter how (keyboard or mouse?)
thanks again
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
