I get really annoyed with programs where the order of yes|no buttons on dialog boxes is inconsistent.

Sometimes people did that intentionally, to prevent people from clicking YES accidentally.

Sorry the ignorance, but is WPF the so called Windows Forms on C# .Net or is it another stuff Im not aware of?

Sorry the ignorance, but is WPF the so called Windows Forms on C# .Net or is it another stuff Im not aware of?

WPF = Windows Presentation Foundation

It's kind of Forms successor - using XML to do control layouts and painting using a lot of reflection to talk to the underlying .NET code. Because of that, UI designers have a lot more control over how the program looks and animates, while being able to (somewhat) keep the UI design separate from the code underlying it.

Forms is basically a Win32 wrapper (that hasn't been updated in a while) whereas WPF is more like Flash or Silverlight. In fact, you can't use the traditional Win32 debugging tools to watch messages and such for the controls since WPF is doing all the rendering and controls itself.

The Modern UI/WinRT system that Windows 8 and 10 have is an evolution of WPF in some respects.

This. Mac UI development is effectively equivalent to how it would be on Windows if the Win32 API didn't exist, and WPF was your baseline API.

And note that's roughly how it evolved on the Mac side as well. The Win32-style C++ APIs existed in the form of Carbon up until about 4 years ago, when they were finally fully deprecated in preparation for the move to 64-bit.

I was under the impression that it was the other way around, and Carbon was basically like emulating Win32 on top of something else.

You can still create child views manually for your buttons and handle layout yourself.. but when using the graphical builder in Xcode a bunch of code is automatically generated that handles it. Without that it's not that different from Win32, can still create child-windows and handle their events manually as well as override the repaint methods etc.

I was under the impression that it was the other way around, and Carbon was basically like emulating Win32 on top of something else.

Carbon was a pretty straight port to OS X of the existing 'classic Mac' C/Pascal APIs. Some of the functionality underlying both Carbon and Cocoa was provided as part of a lower layer (CoreFoundation, CoreGraphics, etc), but much of Cocoa originally built on top of Carbon.

For years you had to reach through Cocoa to Carbon if you wanted to accomplish exotic things (like replacing system menus or capturing input from other windows). Since Carbon was deprecated, that functionality has all migrated into either Cocoa itself or the *Foundation APIs.

You can still create child views manually for your buttons and handle layout yourself.

You can indeed create all your Cocoa widgets in code, and ignore the interface builder entirely. However, you still have access to all the auto-layout and data-binding functionality Cocoa provides out of the box - so I'd say it's a far cry from the Win32 approach.

but when using the graphical builder in Xcode a bunch of code is automatically generated that handles it

It's not so much generating code as it is generating data. Yes, interface builder does generate API stubs for your code to integrate with, but all the UI widgets are serialised into XML (or sometimes binary), and then the code which loads these files at runtime auto-wires references into the API stub hooks.

In this respect the system is far more analogous to how the Android UI framework works, than to traditional C++/Java UI designers which generate code to implement the entire UI.

Proper UI frameworks are very nice to you. Not sure why people continue to muck around with legacy APIs like Win32, when newer (and better) alternatives are widely available...

Well, there's still a lot of legacy software out there that has to be maintained and rewriting the UI in a new framework is rarely high on a list of priorities (unless there's a serious issue).

But yeah, if you start writing a windows UI in Win32 today, you're insane.

WPF = Windows Presentation Foundation

It's kind of Forms successor - using XML to do control layouts and painting using a lot of reflection to talk to the underlying .NET code. Because of that, UI designers have a lot more control over how the program looks and animates, while being able to (somewhat) keep the UI design separate from the code underlying it.

Forms is basically a Win32 wrapper (that hasn't been updated in a while) whereas WPF is more like Flash or Silverlight. In fact, you can't use the traditional Win32 debugging tools to watch messages and such for the controls since WPF is doing all the rendering and controls itself.

The Modern UI/WinRT system that Windows 8 and 10 have is an evolution of WPF in some respects.

Exactly what is happening with windows UI these days? What is the official "best practice" according to MS these days? WPF seems to have been all but abandonded.

Exactly what is happening with windows UI these days? What is the official "best practice" according to MS these days? WPF seems to have been all but abandonded.

Caveat: I do not work for Microsoft - the below is speculation mixed with personal experience. (And most of my experience is with raw Win32)

From what I can gather there are 5 main UI frameworks for Windows (not counting third parties like QT).

• Win32 - The lowest level API, does almost nothing for you automatically, and has a crappy resource editor. But it's the only one that lets you access almost everything in the OS, though the more recent the item, the more likely it is to use COM instead of raw C.
• MFC - The C++ wrapper around Win32. Not sure how frequently this is updated, I don't do any development with it.
• Forms - The .NET wrapper around Win32. Haven't heard about any update to this in a long time, though MS has put out at least one DLL several years ago that I know of that wraps some of the newer features (like the new folder browser dialog from Vista and newer). It acts kind of like MFC, in that it uses events and objects to communicate to/from the UI.
• WPF - A whole new UI system for .NET using XML for the UI layout and heavy use of reflection to communicate to/from .NET code. By default, makes programs that look very close to (but not quite exactly like) Win32 apps, but everything can be redrawn/animated/whatever by a designer using a Flash-like development tool. Because it doesn't actually wrap Win32 like the other systems, it doesn't use standard controls which means Spy++ won't help you with debugging. Went a long time without a major update, but MS seems to be working on a new version to come out with Windows 10 and MSVC2015.
• "Modern"/WinRT - not sure what the official name is here, but this is kind of WPF 2.0 in that it took a lot of the ideas that WPF had (like XAML) and made it work more efficiently for low-power devices like phones and tablets, and play nice with touch. Actually runs UI in its own thread and has very few to no blocking calls at all in order to try to keep things responsive. Under active development/improvement by MS for obvious reasons. Unlike Forms and WPF, I believe it plays nicely with C++ using the new C++/CX extensions, compiling to native code, as opposed to C++/CLI which builds a managed/native code mix depending on what you're doing.

MS itself seems to be using a mix of the technologies. MSVC is written in WPF and .NET, whereas Internet Explorer 11 seems to still be using Win32 under the hood (which means it's either Win32, MFC, or Forms).

When Im doing custom tools like level and sprite animation editors that export to my engine, I dont give a shit about UI, its all shortcuts (thats how someone who master a tool uses the software anyway, in the end you know all shortcuts and do minimal use of mouse, so why would I, as the only user of my tool, worry about that?)

But sometimes, I need to receive input, like set the duration and choose between options, thats when I need a GUI. Since my tools are all made for my engine with my engine (so that I know how it will look/act exactly etc.) its all native C++.

What I do is create lots of modeless dialog boxes that popup when you click in the element you want to edit.. Its the easiest way. So I create it using VS resource editor..all win 32 mess.

I do that cause Im under the impression that interacting native code with .Net is a frigging monster of its own, so its not worth it.. All the times I start reading on how to do it I go "fuck this shit...too much for too few" and give up on that C++/CLI and DLLs(?) shit...

Using external libs is a nightmare, you basically add stuff to the list of things you need to maintain (new version?..great), plus learn stuff you rather not...

What would you do in my place? Is it easy to interact c++ with .net and Im just a pussy?

I can't really understand half of what you're saying (riddling your comments with profanity doesn't generally help). That said:

I do that cause Im under the impression that interacting native code with .Net is a frigging monster of its own, so its not worth it.

Interoperability between languages is usually going to involve some level of pain, but interoperability between C# and native C or C++ code is relatively low on the pain scale for the domain. If your native code does, or can, expose C bindings you can simply use P/Invoke to make them accessible to C# and thus write your editor GUI code entirely in C#, which is far better suited to the task with Windows Forms or WPF than using Win32 in pure C is. P/Invoke is a bit of boilerplate work, but for the most part is very easy to set up.

If you can't or don't want to involve C bindings, you can write an interop DLL using C++/CLI. This is a little more involved because C++/CLI is largely it's own little language with a lot of odd idiosyncrasies and involves much more of a time investment to learn. It's what underpins wrapper APIs like SlimDX. I wouldn't recommend this route unless you really want to dedicate the time and effort to it.

You can also eschew both of these methods and "interop" your engine and editor code via IPC or sockets, which trades the whole mess of language interoperability details for a different mess (shipping the actual data around is a much bigger issue).

Using external libs is a nightmare, you basically add stuff to the list of things you need to maintain (new version?..great), plus learn stuff you rather not...

It's a lot easier than you seem to make it out to be. It sounds like you're just letting your frustration get in the way of your better judgement. I would advise you to continue working on your current project in the mode you've found works (even if that's the "ugly Win32 dialog" way). As a side project, explore the world of language interop on a project that isn't as important or interesting; it will remove the task from the critical path of your other project which may help alleviate the frustration you're having when things don't immediately work.

What would you do in my place?

Qt - I'm a fan.