Thanks Exoity, what I some what dislike is, spending hours absorbed in c++ where I'm in a very protective mind set for how I code, then going into C# where I'm not required to be as watchful, sometimes causes me to loose that focus when I go back into c++. I'm not sure if this makes any sense or not? I can tend to get a bit lazy when working in c# because I know I can get away with it, but when I go back to c++ I don't want to be in that same mind set. Considering I will be spending a good chunk of time with tools and my engine, I was trying to stay with just c++ if I could, taking advantage of .net forms.

You do not need to use Xna in C#. If you have a form you can get a hwnd, write a C++ D3D renderer and a thin C++/CLI layer then write the app in C#?

Umm sorry for my constant questions. I know I can get XNA in a Form window in less than 10 minutes and have a map able editor in about 30 minutes with just tiling to a grid (Mid you the code would be messy). I'm finding maybe using C++ will just cause more of a headache than needed for tools development. I have no problem using C++ for the engine side of things, maybe I should just stop being so one sided to just C++ and jump on board to a RAD language for my tools.

I don't really need to use C++ for the tools because I'm outputting all of the data in files which will be loaded into the engine and put to work. Heck, I could use BASIC and still accomplish the same task. My main issue is that GDI+ is usually too slow. I require some heavy graphic drawing in my editor, this is why I was thinking of XNA.

The one thing I hated about programming was the endless options, it's not like breathing.

If I find myself unable to leave c++, I guess wxWidgets with OpenGL would be an option.

I've had a hard time moving on to programming a project using several languages, even though I've learned enough C# to make a game in that language.

It's good to be a polyglot. You learn a lot about your primary language, if you also know well other languages. Mastering C# will help you with using OO features in C++, as well as with new C++ 2011 features. C++ is really not object "oriented", it just allows you to use objects. Also, if you want to write fast C, it's good to know assembly
OK, if you have to work with 5+ languages, then you are spread thin. If it's below that number, you'll be fine.

IMO:
C++/CLI is really ugly (it's basically C#, but with really cumbersome syntax), and should only be used in the rare cases where you want to plug some engine code into your tools (i.e. just use it when you're gluing C++ and C# code together).

Huh. C++/CLI looks like C# to you? C++/CLI is not a language of itself, it is C++ with support for CLR objects. If you want to consume or create CLR objects, you have to use CLR data types in System:: namespace. Within methods you are free to use std:: or boost::. The C++/CLI syntax for .NET types is quite similar to std vectors. To remind you of the type of variable you use, CLR objects use ^% operators instead of *&.

You can also define which files within your VC++ project have CLR support (/clr switch). I usually create ManagedClass.cpp and NativeClass.cpp. For NativeClass.cpp I remove CLR support in Release build and add SSE2 optimizations.

With Reflector you can also see your compiled .NET code as Managed C++ (old syntax). It speeds up the translating from C# to C++.

As to the main question: should you use C++/CLI as a major development language. My answer is NO.
C++/CLI doesn't even have IntelliSense in VS 2010. Visual Assist X gives you that support though. C# is the language of choice for .NET development, C++ for native. C++/CLI gives you much faster interop than P/Invoke, as C++/CLI knows how to work with both CLR and C++ data types. But mind you, tight loops should be either in CLR or in native, the context switch isn't free (although it is faster than using P/Invoke).

I didn't say it looks like C# - I said it's got a very cumbersome syntax compared to C#.

e.g. in C++/CLI you've got [font="Courier New"]ref class[/font]/[font="Courier New"]value struct[/font] instead of [font="Courier New"]class[/font]/[font="Courier New"]struct[/font], and you've got [font="Courier New"]^[/font]/[font="Courier New"]%[/font] instead of C#'s automatic reference handling.
i.e. it can do everything that C# can (which is why I said it's like C#), but the syntax for doing so is a lot more verbose than C#'s.
Also, it is indeed a language of itself (ECMA-372). There's certain programs which are valid under ISO C++ but are not valid when compiled under C++/CLI (mostly due to the new keywords).

You said: it's basically C#, but with really cumbersome syntax
It is CLR, but the syntax is different. Otherwise you could also say that it's basically VB.NET.

C++/CLI might be formally a separate language, but in VS 2010, you only have C++ listed as a language. Then you can select ATL, CLR or MFC C++ projects. As for certain programs not compiling under CLR: you can specify CLR support on file level, or even only on a code block using #pragma managed, #pragma unmanaged. You can't switch this way between C# and VB.NET

If you love C++ you should definitely stick with Qt.
I made a leveleditor myself with Qt and I have to say that it worked pretty good.

What you also should not overlook is that Qt has one of the best documentations I've ever seen.

What does QT use for rendering graphics to the screen?

For example, if I clicked at (16, 32) on a bitmap, could I have a graphic drawn at that location. This is pretty much all I need, which is easy to do in GDI+ but very slow at the moment. I just need a buffer pretty much and I'll use my normal way of exporting locations for objects, ect... plus an array for the tile locations.

I'll check out the QT website some more, I did watch some youtube videos and must same I'm impressed with how fast I had seen a window with buttons and text boxes up and running.

You do realize that absolutely none of those technologies are exclusively tied to C++, right? OpenGL, DirectX, wxWidgets, all of the have C# bindings available.

I will agree with the decision you are coming to 100% though, using C++ for tools is mostly a dumb thing to do, especially if your end result is a language independent file.

You bet, they're just APIs. I mean I could honestly make a level editor with C++ and say SDL or SFML, using a custom gui I'll create like I've done in the past. However, it takes a long time to get this done, but once complete it's working and good to go, and not too hard to make improvements. What I'm attempting at doing here is moving with the times. C++ has been my language of choice for a long time, however RAD will save me a ton of time in the future. I'm planning a lot of new projects in the coming years, and will be offering some services for others, therefore I'm trying to pick the right route for tools development now.

I don't believe I will ever sway away from c++ for many more decades to come, unless it becomes obsolete with some crazy new technolgoy and is unusable (which I doubt will happen in half my life time).