Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. C# - web or winforms?

C# - web or winforms?

Scheduled Pinned Locked Moved The Lounge
csharpc++winformscomquestion
42 Posts 22 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Christopher Duncan

    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

    J Offline
    J Offline
    Jasmine2501
    wrote on last edited by
    #27

    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.

    H 1 Reply Last reply
    0
    • C Christopher Duncan

      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

      J Offline
      J Offline
      Jasmine2501
      wrote on last edited by
      #28

      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.

      1 Reply Last reply
      0
      • C Christopher Duncan

        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

        M Offline
        M Offline
        Member 96
        wrote on last edited by
        #29

        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.

        C 1 Reply Last reply
        0
        • M Member 96

          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.

          C Offline
          C Offline
          Christopher Duncan
          wrote on last edited by
          #30

          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

          M 1 Reply Last reply
          0
          • C Christopher Duncan

            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

            M Offline
            M Offline
            Mardanian
            wrote on last edited by
            #31

            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.

            1 Reply Last reply
            0
            • C Christopher Duncan

              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

              M Offline
              M Offline
              Member 96
              wrote on last edited by
              #32

              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.

              1 Reply Last reply
              0
              • L Lost User

                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#.

                █▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██

                S Offline
                S Offline
                Stephen Hewitt
                wrote on last edited by
                #33

                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

                1 Reply Last reply
                0
                • J Jasmine2501

                  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.

                  H Offline
                  H Offline
                  huyanping
                  wrote on last edited by
                  #34

                  Good! The key point is how do you use C#. We should obey some new rules. Generally,It's a new approach.

                  hello, life

                  1 Reply Last reply
                  0
                  • L Lost User

                    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.

                    █▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██

                    S Offline
                    S Offline
                    Stephen Hewitt
                    wrote on last edited by
                    #35

                    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 the namespace the standard C++ library is in.

                    Steve

                    L 1 Reply Last reply
                    0
                    • C Christopher Duncan

                      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

                      N Offline
                      N Offline
                      nilotic
                      wrote on last edited by
                      #36

                      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

                      1 Reply Last reply
                      0
                      • S Stephen Hewitt

                        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 the namespace the standard C++ library is in.

                        Steve

                        L Offline
                        L Offline
                        Lost User
                        wrote on last edited by
                        #37

                        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++.

                        █▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██

                        S 1 Reply Last reply
                        0
                        • L Lost User

                          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++.

                          █▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██

                          S Offline
                          S Offline
                          Stephen Hewitt
                          wrote on last edited by
                          #38

                          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

                          L 1 Reply Last reply
                          0
                          • S Stephen Hewitt

                            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

                            L Offline
                            L Offline
                            Lost User
                            wrote on last edited by
                            #39

                            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;
                            }
                            }
                            }

                            █▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██

                            S 1 Reply Last reply
                            0
                            • L Lost User

                              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;
                              }
                              }
                              }

                              █▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██

                              S Offline
                              S Offline
                              Stephen Hewitt
                              wrote on last edited by
                              #40

                              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

                              L 1 Reply Last reply
                              0
                              • S Stephen Hewitt

                                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

                                L Offline
                                L Offline
                                Lost User
                                wrote on last edited by
                                #41

                                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.

                                █▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██

                                S 1 Reply Last reply
                                0
                                • L Lost User

                                  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.

                                  █▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██

                                  S Offline
                                  S Offline
                                  Stephen Hewitt
                                  wrote on last edited by
                                  #42

                                  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

                                  1 Reply Last reply
                                  0
                                  Reply
                                  • Reply as topic
                                  Log in to reply
                                  • Oldest to Newest
                                  • Newest to Oldest
                                  • Most Votes


                                  • Login

                                  • Don't have an account? Register

                                  • Login or register to search.
                                  • First post
                                    Last post
                                  0
                                  • Categories
                                  • Recent
                                  • Tags
                                  • Popular
                                  • World
                                  • Users
                                  • Groups