I really hate the win api, and never bothered to learn mfc -- .net forms are very simple, and even creating an application without windows or with multiple windows or even an MDI is pretty damn easy.

umm, well most applications have main windows, but applications don't need them of course, and there's nothing to stop a windows application from having many different windows with no apparent parent window, a process can create and own as many windows as it wants -- it's just a usability thing, why would you create a user interface like that? It makes no sense to me.

It's much nicer to have everything in a single container window -- take for instance using adobe photoshop, or macromedia fireworks, and vs 2005 at the same time -- one window to do all of your coding, and another to do your imaging -- they both can have 10 or 20 sub windows, and you could drag them around to fit them both on your desktop and open at once (especially if you have two monitors) and all the child windows move, and they keep their correct relative positions, both main menus are open at the same time;

Why on earth would you trade that for just one main menu being displayed at a time, and having to manually drag all of the child windows around one at a time so that all of your adobe crap was on one side and all of your ide crap on the other?

that's just headache inducing.

why should they have to? why should the ui of a program change because it loses focus?

I'm sorry thats a stupid argument. WPF is Microsoft's new UI frameworks. Why would a UI framework replace a Database product? Had Microsoft released a completely different relational database engine product then i suppose you could try to use that as point, here it doesn't make sense. Sorry for the harsh words, but really even if what I'm saying is still wrong, what you said makes absolutely no sense.

Here this link should be helpful, Its a general introduction to wpf and explains its purposes as well as some sample code.

http://msdn2.microsoft.com/en-us/library/aa663364.aspx
Quote from the article:

The exciting thing i guess about the new setup, is in XAML you can have an artist create your programs UI, and then you simply write code on top of it. No longer do you need an artist to do a mock up for an application and have the programmer attempt to program an identical interface, rather the artist creates the interface and the programmer just creates it's functionality.

There is a large part of web stuff as well, which is i guess where your getting the flash stuff? and tons of additional features and additional shit, and yes you can do all that stuff as well

I guess the biggest reason WPF is not mainstream, is its brand new, its not really finished yet and there has yet to be a killer app to showcase it's potential. But time will tell what will happen. Perhaps it will just be used as an added supplement to existing MFC and .NET forms apps (which will be likely for the immediate future anyway, as developers will want to experiment with it without relying on yet unproven tech) or it will take over completely.

[edit]

I do agree that for smaller projects that windows forms is an ideal replacement for now, and will still be for some time. However for large applications and commercial products, Windows forms does not make sense when there is such a drastic change on the horizon. Of course non of us have the commercial problem, so uh, carry on.

Okay, you're right. I was misdirected about what WPF is.

As far as being used professionally, I'm sure The next version of Visual Studio will have support for it. I wouldn't dream of making a UI without the dialog editor from that app Maybe that's why I don't code Qt apps

I like the Qt designer just fine

Windows API not only includes graphics but everything else as well. In .NET though they did the sane thing and put a lot of those outside of System.windows.forms. But that still leaves the c/c++ api's with much to be desired.

And gtk/gnome has been using cairo now for quite some time.

I think if you examine closely, at least with Excel, that while each document has a taskbar entry, they share one MDI window.

you can get that behavior in windows via the winapi, there's nothing that forces your program closed because a window got closed or didn't get closed, it's just what people who use that OS are familiar with and has become a common coding pattern, and you can also check to see, when the application launches, is it already open? if so then just send it a message to display the window again, and close this instance.

Really, what it sounds like this pattern (the one you describe) prevents you from, is having multiple instances of the same application open, which seems silly.

MSN messenger is a POS (not: point-of-sale) though, so you'd expect it to behave as such, I'm sure there's badly written software for the apple that exists too (not that I would know of any, but if I did, I wouldn't judge the whole apple-ui by them).

I'm not most people -- infact, I don't think anybody is. -- ha, I'm done hijacking this thread for now.

edit: I don't know enough about XAML, but what about animations, moving controls, and other things that would have to be done programatically, how can this be accomplished with a static xml document that defines the interface? or does the XAML just happen declaritively, and still give you .net forms objects to work with on the backside?

What? Most chat applications act the same way, and I like it. You close your contacts list and it goes to the tray. Nothing to not be known here...

I'd say that the windows api has been purposely designed to be incompatible with everything else, to make it hard to port programs to/from anything else. Why else is there a WinMain() instead of just main()?

Got a question Axilmar.. how did you get around the whole issue of using a member function as a CALLBACK. I tried the usual std::mem_fun (borked!) and boost::mem_fn (worked but then couldn't get it cast as DWORD_PTR as needed)... I decided to give up and make it a singleton class.... (edit: with a static method)

I've seen so called solutions.. many of them involve hacking the assembly to add this as the first parameter. apparently its called thunking and apparently mfc does it.

edit2: SO much nasty reinterpret casting in winapi.. it's really absurd. casting things as a DWORD is something really strange and not exactly portable to 64-bit afaik. HWND has been cast to just about everything.