C# - web or winforms?
-
Yeah, this is kind of the scenario I was suspecting. With MFC and C++, I have a language that won't tell me "no" regardless of what I'm trying to accomplish. However, there are much more jobs out there these days for C# than there are C++ / MFC. I was curious as to whether client side C# would be as fun as C++ always has been, or if it would be as incredibly limiting as browser based development. From your description, it sounds like even native app development with C# is still akin to working with one hand tied behind your back compared with C++. I'd truly like to get excited about the C#, but it's really hard to go backwards in power and flexibility.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Having gone through this myself, I'm gonna say it's a case of being used to doing things in wrong, screwed-up ways in MFC. Then when you try it in C#, the method is totally foreign to you, and C# will not let you play your old games, at all. In a lot of cases, you simply can't do things the old way, and this freaks out a lot of programmers, who then go off and say C# sucks. Yes, some things are different in C#, requiring you to take a new approach. When you re-think the problem and try a more object-oriented approach, usually the C# way ends up being much more elegant.
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles. -
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Christopher Duncan wrote:
My initial interest in C# was due to the vast improvements it made in web development over classic ASP
You make it sound like C# is a web programming language. It's not. It's one of the languages you can use with ASP.Net, but as a language, C# stands on its own.
Christopher Duncan wrote:
how many of you are using C# for client Windows app development
I am using it for that, and for several other things, a screensaver, a link-checker and sitemap tool, and a DB-enabled customer service app for a loan company. See my web site for examples.
Christopher Duncan wrote:
does everyone tend to stay in a web browser?
C# has very little to do with that. It is a fully featured language all by itself. It is associated with programming libraries like ASP.Net and .Net Frameworks, but it's not tied to those permanently. The choice to do something as a web application is driven by other considerations, and a desire to use C# should not affect that decision too much.
"Quality Software since 1983!"
http://www.smoothjazzy.com/programming.html - freeware tools and articles. -
John Cardinal wrote:
I think the whole concept of c# being first and foremost an asp.net thing is bizzarre in the extreme
Just a guess, but it probably came about from the first version of C# / Winforms. Version 1.0 of anything usually leaves a lot to be desired, and back in those days it wasn't a given that the .NET framework was installed on a machine. So, it wasn't an obvious out of the box replacement for MFC. On the web side, however, the difference between classic ASP and C# / ASP.NET is nothing short of monumental, making web development almost feel like real programming. In any event, it's good to see so many people I respect using C# for desktop development. Perhaps it's time to find that old bathing suit and take a deeper plunge... :)
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
We have a very large, very successful commercial application that is written in c# and has a winform interface, an asp.net interface, remoting, an accounting application interface and is used globally in over 50 countries, but I won't anger the lounge gods by posting a link to it here. ;) Suffice to say there is really no good reason not to use C# for most desktop apps these days. Even Linux and Mac platforms are supported through MONO.
-
We have a very large, very successful commercial application that is written in c# and has a winform interface, an asp.net interface, remoting, an accounting application interface and is used globally in over 50 countries, but I won't anger the lounge gods by posting a link to it here. ;) Suffice to say there is really no good reason not to use C# for most desktop apps these days. Even Linux and Mac platforms are supported through MONO.
I assume you have your business and communication logic in one layer and simply designed two separate UI layers for the desktop and web interfaces?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
My personal experience... I've been using MFC for years, and I recently decided to write my first significant client app in C#/.NET. I have to say that I'm really pleased so far. There's is just so much more that's done for you already, and it really minimizes the amount of code you have to write/maintain. I would say that if your client app is heavily based around file access, UI, databases, or networking... then give C# a try. But if your app relies on a lot of direct memory access and processing type behaviors, then perhaps stick with C++/MFC. You could always try managed C++ and use forms in that way, but it just seems strange to me, personally.
-
I assume you have your business and communication logic in one layer and simply designed two separate UI layers for the desktop and web interfaces?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Yup. In fact it's definitely not perfected yet. We designed and wrote a rough business object library at first, then developed it and the winform UI layer in parallel up to release. Then I wrote the asp.net UI layer. Doing a second UI after the initial one was completed resulted in not noticing some redundancies in the UI layer. Next time around I'm going to introduce another layer which resides between the UI and the business object layer and acts as a more UI centric interface to some of the methods in the business object layer. There is a lot of housekeeping and UI centric features that are common to both asp.net and winform UI's but don't really fit in the business object layer. I highly recommend you check out Rockford Lhotka's CSLA book for more on this if you are interested: http://www.lhotka.net/cslanet/default.aspx[^] It's open source (I've modifed it quite extensively for my purposes) but it really gives you everything you need to know to properly stratify applications, goes into remoting, asp.net and winform ui's, scaleability etc. IIRC it presents three different interfaces to the same application.
-
Marc Clifton wrote:
I'm hoping to migrate the UI and DB parts to C#, is a tool that analyzes switch rings for communication satellites, which needs to be as fast as possible.
I would love to see more performance critical apps written in C#.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
Captain See Sharp wrote:
I would love to see more performance critical apps written in C#.
The real question is would users want to use them. C#, and dotNET in general, has many advantages over native code but, in general, performance and resource usage are not amongst them.
Steve
-
Having gone through this myself, I'm gonna say it's a case of being used to doing things in wrong, screwed-up ways in MFC. Then when you try it in C#, the method is totally foreign to you, and C# will not let you play your old games, at all. In a lot of cases, you simply can't do things the old way, and this freaks out a lot of programmers, who then go off and say C# sucks. Yes, some things are different in C#, requiring you to take a new approach. When you re-think the problem and try a more object-oriented approach, usually the C# way ends up being much more elegant.
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles. -
I have found C# and .NET 2.0 to be really easy and fun to work with. Sometime when you are programming away you may not be aware of a class or some API that you need that is in the .NET framework and end up using p/Invoke. I like C# more than C++ because it makes sense to me. Everything seem consistent and logically organized. I always found C++ to be confusing. cout << "Test"; Things like that just does not seem the correct way to make a console input/output class. Why is it named cout instead of something like ConsoleOut? Why do I have to use an overloaded operator when I could use ConsoleOut.Println("Test"); ? Why must they name namespaces "std"??? Thats why I like C#. Its clean, organized, logical, and it seems pretty fast for a managed language. C# even has full support for pointers.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
Captain See Sharp wrote:
cout << "Test"; Things like that just does not seem the correct way to make a console input/output class
This syntax has advantages over something like this:
Console.Write(“Test”);
One is that you can chain multiple writes together. Like this for example:
int res = /*Some calculation*/;
cout << “The answer is = “ << res;The other is that it enables the use of manipulator functions. i.e.
cout << “In hex that is: “ << hex << res;
The biggest advantage is that it allows the mechanism to be extended. For example:
class CMyClass
{
};
ostream& operator<<(ostream &stm, const CMyClass &rhs)
{
stm << “CMyClass”;
return stm;
}
// Now I can write code like this:
CMyClass mc;
cout << mc;This is a lame example but hopefully you’ll get the idea. In a way a similar result can be achieved in dotNET by overriding the
Object.ToString
method but using the C++ method allows the stream mechanism to be extended without modifying the stream classes or the type you’re streaming. This is often a very useful property and an example of the Open Closed Principle[^] It's easy to remember once you get used to it: think of the "<<" as arrows pointing in the direction of information flow.Captain See Sharp wrote:
Why is it named cout instead of something like ConsoleOut?
To save typing the longer "ConsoleOut" all the time I'd wager.
Captain See Sharp wrote:
Why must they name namespaces "std"???
Namespaces can have any name.
std
is just thenamespace
the standard C++ library is in.Steve
-
My initial interest in C# was due to the vast improvements it made in web development over classic ASP. However, for client apps I instinctively reach for C++ simply because of the years I've been doing it. I was wondering how many of you are using C# for client Windows app development rather than for browser based scenarios. Is C# / Winforms suitable for serious client side development, or does everyone tend to stay in a web browser?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
I began tinkering with WinForms first, with no knowledge of web programming. I wanted some apps, so I made them, and I found myself making nicer GUI's than necessary because its so easy. Great. I then quite upset when I made a website. I reckon most of the provided GUI bits don't work properly with Firefox, and don't render nicely in the Design View. eg. When I put an in, it needed a 'margin' tweak to obey form layout, and I can't see the items within the table panels in either the Form Outline or the properties window. Dreadful. Also I'm a bit upset about CSS not rendering nicely in the Design View, when using themes. All in all I find it hard to believe that VS2005 was designed for Web Apps at all, other than an afterthought, after building the excellent Windows App side of things.
A chance to die; to turn to mode - bowie
-
Captain See Sharp wrote:
cout << "Test"; Things like that just does not seem the correct way to make a console input/output class
This syntax has advantages over something like this:
Console.Write(“Test”);
One is that you can chain multiple writes together. Like this for example:
int res = /*Some calculation*/;
cout << “The answer is = “ << res;The other is that it enables the use of manipulator functions. i.e.
cout << “In hex that is: “ << hex << res;
The biggest advantage is that it allows the mechanism to be extended. For example:
class CMyClass
{
};
ostream& operator<<(ostream &stm, const CMyClass &rhs)
{
stm << “CMyClass”;
return stm;
}
// Now I can write code like this:
CMyClass mc;
cout << mc;This is a lame example but hopefully you’ll get the idea. In a way a similar result can be achieved in dotNET by overriding the
Object.ToString
method but using the C++ method allows the stream mechanism to be extended without modifying the stream classes or the type you’re streaming. This is often a very useful property and an example of the Open Closed Principle[^] It's easy to remember once you get used to it: think of the "<<" as arrows pointing in the direction of information flow.Captain See Sharp wrote:
Why is it named cout instead of something like ConsoleOut?
To save typing the longer "ConsoleOut" all the time I'd wager.
Captain See Sharp wrote:
Why must they name namespaces "std"???
Namespaces can have any name.
std
is just thenamespace
the standard C++ library is in.Steve
I understand. I was just trying to point out that .NET although more verbose is easier to learn and discover what you need. It takes longer to remember all the abbreviations and little things in C++.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
-
I understand. I was just trying to point out that .NET although more verbose is easier to learn and discover what you need. It takes longer to remember all the abbreviations and little things in C++.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
I guess it a bit of a "religious debate" but I've never had any trouble remembering "cout", "cin" or "std" and what they mean. Your mileage may vary. If I had to find faults in C++ and the standard library they wouldn't even make it on the list.
Steve
-
I guess it a bit of a "religious debate" but I've never had any trouble remembering "cout", "cin" or "std" and what they mean. Your mileage may vary. If I had to find faults in C++ and the standard library they wouldn't even make it on the list.
Steve
Stephen Hewitt wrote:
I guess it a bit of a "religious debate" but I've never had any trouble remembering "cout", "cin" or "std" and what they mean. Your mileage may vary. If I had to find faults in C++ and the standard library they wouldn't even make it on the list.
Although I have never done any serious programming in C++ I found it easy and natural to use cout, cin, and easily remembered std and the various #includes needed to to basic things. I was just trying to point out the elegance of C# compared to C++. I would very much like to develop some apps in C++ but dealing with the Windows API or MFC is a pain. I also do not like making heavy use of pointers, they are hard to avoid in C++. In C# pointers a very useful for large array coping and image editing and I only need to use them in certain scenarios. I can create a window with a very small amount of code that is very easy to understand. I'm not against C++ at all but I think C# is the way to go for general purpose applications, especially with C# 3.0 on the way. I cant wait to use C# 3.0.
using System.Windows.Forms;
namespace SeeSharpProgram
{
class Program
{
static void Main()
{
Application.Run(new TestForm());
}
}
class TestForm : Form
{
public TestForm()
{
this.Title = "Test Form";
this.Width = 640;
this.Height = 480;
}
}
}█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
-
Stephen Hewitt wrote:
I guess it a bit of a "religious debate" but I've never had any trouble remembering "cout", "cin" or "std" and what they mean. Your mileage may vary. If I had to find faults in C++ and the standard library they wouldn't even make it on the list.
Although I have never done any serious programming in C++ I found it easy and natural to use cout, cin, and easily remembered std and the various #includes needed to to basic things. I was just trying to point out the elegance of C# compared to C++. I would very much like to develop some apps in C++ but dealing with the Windows API or MFC is a pain. I also do not like making heavy use of pointers, they are hard to avoid in C++. In C# pointers a very useful for large array coping and image editing and I only need to use them in certain scenarios. I can create a window with a very small amount of code that is very easy to understand. I'm not against C++ at all but I think C# is the way to go for general purpose applications, especially with C# 3.0 on the way. I cant wait to use C# 3.0.
using System.Windows.Forms;
namespace SeeSharpProgram
{
class Program
{
static void Main()
{
Application.Run(new TestForm());
}
}
class TestForm : Form
{
public TestForm()
{
this.Title = "Test Form";
this.Width = 640;
this.Height = 480;
}
}
}█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
In C++ there are many ways you could do this depending on what framework your using (MFC, ATL, WTL, Qt, etc…). Some would be just as short and easy to understand. There’s no rule that says you have to use straight Win32 API.
Steve
-
In C++ there are many ways you could do this depending on what framework your using (MFC, ATL, WTL, Qt, etc…). Some would be just as short and easy to understand. There’s no rule that says you have to use straight Win32 API.
Steve
Stephen Hewitt wrote:
In C++ there are many ways you could do this depending on what framework your using (MFC, ATL, WTL, Qt, etc…). Some would be just as short and easy to understand. There’s no rule that says you have to use straight Win32 API.
Yes, but there are also things such as properties, indexers, delegates(easier and more functional than raw function pointers), iterators with foreach and creation of enermable classes with the yield keyword. There are also things such as cross language interoperability, metadata, reflection. It all adds up to be a great tool to develop your applications on, even with C++. I'm not really saying C# is better, I'm saying that the CLR is a great foundation to build upon in any language.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
-
Stephen Hewitt wrote:
In C++ there are many ways you could do this depending on what framework your using (MFC, ATL, WTL, Qt, etc…). Some would be just as short and easy to understand. There’s no rule that says you have to use straight Win32 API.
Yes, but there are also things such as properties, indexers, delegates(easier and more functional than raw function pointers), iterators with foreach and creation of enermable classes with the yield keyword. There are also things such as cross language interoperability, metadata, reflection. It all adds up to be a great tool to develop your applications on, even with C++. I'm not really saying C# is better, I'm saying that the CLR is a great foundation to build upon in any language.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
I've got nothing against dotNET in general or C# in particular. There is little doubt that may programmers find life easier with these tools than with C/C++. On the various language features such as, “iterators”, “foreach” and what have you note that C# and C++ have a different philosophy here. In C# such things are first class language features but C++ goes down a different path: make the language flexible enough so that such things can be implemented in libraries and have a standard library which contains the most generally useful. Third parties can also produce such libraries as can the programmer himself. For example, the STL has a well developed iterator concept and the Boost library provides a foreach[^] construct you can use to iterate over collections. C++ is a very flexible langauge in that respect.
Steve