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!
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.
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.
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.
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.
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 !
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.
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:
Comment