• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Application Frameworks!

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    #11
    Originally posted by TheMonkey
    I'm getting biased towards C++ / MFC but it's so over-#defined Everything is a fecking macro.
    MFC is pretty good if you want Word (i.e. document/view on a file, toolbars etc.). If you're doing a simple app there's a lot to be said for just forgetting the framework and writing a win32 app from scratch. And you don't have to use the macros.

    Every Java app I've ever seen has been clunky, and it's interesting to hear that winforms isn't any good either.
    Will work inside IR35. Or for food.

    Comment


      #12
      Originally posted by VectraMan
      MFC is pretty good if you want Word (i.e. document/view on a file, toolbars etc.). If you're doing a simple app there's a lot to be said for just forgetting the framework and writing a win32 app from scratch. And you don't have to use the macros.

      Every Java app I've ever seen has been clunky, and it's interesting to hear that winforms isn't any good either.
      Might try that.

      I just dug out my Visual C++ 6 CD and started installing. I seem to remember from back in '98 that poking directly at the win32 api was very verbose.

      I'm hovering around mingw, visual c++ and lcc with no firm decision so far.

      My objective is to ship an exe ONLY for this application (and possibly a Nullsoft Installer package) that works on win98+. I'm going to pack it with UPX. Inspiration is from uTorrent, but the subject matter is considerably different! (uTorrent info here: http://blogs.zdnet.com/Ou/?p=153 )

      As for the winforms, they are extremely slow generally. Unbearably in some cases. There is no way to get the performance that really large GUI apps require in .Net.

      Btw this is a hybrid of Textpad on Windows and TextMate on Mac, seeing as Helios has not released a new minor version of TextPad for over 2 years now.
      Last edited by TheMonkey; 7 November 2006, 14:18.
      Serving religion with the contempt it deserves...

      Comment


        #13
        Originally posted by TheMonkey
        As for the winforms, they are extremely slow generally. Unbearably in some cases. There is no way to get the performance that really large GUI apps require in .Net.
        There is no good reason for that - IMO Microsoft people who were responsible for WinForms made a really bad work, unlike CLR/C# folk.

        Comment


          #14
          Originally posted by TheMonkey
          I just dug out my Visual C++ 6 CD and started installing. I seem to remember from back in '98 that poking directly at the win32 api was very verbose.
          Yes, but as usual with these things you wrap them up in a few classes and then it gets easy. MFC is probably a better way to go, but sometimes it gives you crap you don't want and is hard to get rid of. A dialog app is usually the way to go for simple apps.

          Good to know that my MFC skills aren't entirely been replaced by .NET. I always thought .NET was going to be an easy way of having the responiveness of a proper native application running in the browser, but interacting with a back end server (like Java was meant to be). Instead both technologies seem to have been relegated to glorified server scripting engines, spewing out clunky old HTML. It all seems like a step backwards to me.
          Will work inside IR35. Or for food.

          Comment


            #15
            Originally posted by AtW
            There is no good reason for that - IMO Microsoft people who were responsible for WinForms made a really bad work, unlike CLR/C# folk.
            Indeed!

            Originally posted by VectraMan
            Yes, but as usual with these things you wrap them up in a few classes and then it gets easy. MFC is probably a better way to go, but sometimes it gives you crap you don't want and is hard to get rid of. A dialog app is usually the way to go for simple apps.
            Yeah been there got the T-Shirt. I am an ex-C++/MFC guru who managed to avoid much of the Win32 API thanks to some nice abstraction layers the guys I was working with had created!

            Originally posted by VectraMan

            Good to know that my MFC skills aren't entirely been replaced by .NET. I always thought .NET was going to be an easy way of having the responiveness of a proper native application running in the browser, but interacting with a back end server (like Java was meant to be). Instead both technologies seem to have been relegated to glorified server scripting engines, spewing out clunky old HTML. It all seems like a step backwards to me.
            Yeah I agree entirely. I HATE HTML with a passion. It's such a clunky crappy way of doing things.

            ClickOnce / RunOnce or whatever it is called is supposed to do that, but there's so much uber-security to get round to do it.

            I also wish people would stop pushing 99% of their ideas across the web. It's never going to work as well like that.

            Btw, I've found another option - use C++ and wxWindows, then it's cross platform !
            Serving religion with the contempt it deserves...

            Comment


              #16
              Originally posted by TheMonkey
              Yeah been there got the T-Shirt. I am an ex-C++/MFC guru who managed to avoid much of the Win32 API thanks to some nice abstraction layers the guys I was working with had created!
              I did Win32 before I ever did MFC, so I've always been able to see through MFC. It's my experience that most MFC people have an over inflated idea of what it actually is; a lot of it is just a very thin wrapper of the API functions. Stuff like:

              pWnd->ShowWindow(SW_SHOW)

              instead of

              ::ShowWindow(hWnd, SW_SHOW);

              Very few functions add anything at all, and all the functions that interact with controls just call SendMessage. In fact the whole message routing is a bit of a bodge and doesn't interact with C++ in the way that C++ people tend to think it does.

              But I digress..

              Btw, I've found another option - use C++ and wxWindows, then it's cross platform !
              I was trying to think of that earlier. I don't know what that's like, but any cross platform system has got to have some overheads and limitations.
              Will work inside IR35. Or for food.

              Comment


                #17
                Originally posted by VectraMan
                I did Win32 before I ever did MFC, so I've always been able to see through MFC. It's my experience that most MFC people have an over inflated idea of what it actually is; a lot of it is just a very thin wrapper of the API functions. Stuff like:

                pWnd->ShowWindow(SW_SHOW)

                instead of

                ::ShowWindow(hWnd, SW_SHOW);

                Very few functions add anything at all, and all the functions that interact with controls just call SendMessage. In fact the whole message routing is a bit of a bodge and doesn't interact with C++ in the way that C++ people tend to think it does.


                But I digress..
                Yeah but it takes away a lot of the repetitive runes you have to cast every time you want to create something for example - CreateWindow[Ex] for example.

                Originally posted by VectraMan
                I was trying to think of that earlier. I don't know what that's like, but any cross platform system has got to have some overheads and limitations.
                I'm investingating. I think the effect is minimal - I've used wxPython before which is basically a bridge as follows and it's VERY fast:

                Python (bytecode vm) <--> wxPython (native dll) <--> wxwindows (native dll) <--> raw win32

                I'd say it was faster than Winforms / GDI+ in .Net 2.0
                Serving religion with the contempt it deserves...

                Comment


                  #18
                  You guys.

                  WPF and .NET 3.0 is all you need.

                  http://wpf.netfx3.com/

                  All that other crap is sooooooo 20th Century.

                  PS here is an Open Source equivalent RIA technology http://www.openlaszlo.org/

                  http://www.openlaszlo.org/lps/exampl...=html&lzr=swf7
                  Last edited by DimPrawn; 8 November 2006, 08:31.

                  Comment


                    #19
                    Originally posted by DimPrawn
                    You guys.

                    WPF and .NET 3.0 is all you need.

                    http://wpf.netfx3.com/

                    All that other crap is sooooooo 20th Century.

                    PS here is an Open Source equivalent RIA technology http://www.openlaszlo.org/

                    http://www.openlaszlo.org/lps/exampl...=html&lzr=swf7
                    Another excuse to build application-specific inconsistent UIs. Just what we need!
                    Serving religion with the contempt it deserves...

                    Comment


                      #20
                      Originally posted by DimPrawn
                      WPF and .NET 3.0 is all you need.
                      Actually that sounds quite good. If I manage to get some time off soon, I think I'll do some learnding.
                      Will work inside IR35. Or for food.

                      Comment

                      Working...
                      X