We Keep Coding

Creating buttons (all controls Behaviour) in XNA

I am just a hobby programmer.. and even tough I know how, I don't want to mix windows forms and XNA for my level editor.
Has anyone done this before? Are there any examples around how to create "Windows like" controls for XNA, including events like mouse over, click and double-click and even accept keyboard input(if possible using language specific keyboard input)?
Below you find the basic layout of my editor but it needs so much more.

Yeah.
I'm now creating something like that.
See my project on Bitbucket.
I'm making own lib and voxel engine for Minecraft-like game. Just for fun.
So, in GameHelper lib you can fing folders Input (keyboard and mouse input) and GUI (forms and controls with events). I will be happy if it helps you, but there is almost no comment :P
Examples of use you can find in the Player class in main project (see ProcessInput method).
If you need I can give you better examples :)

C# Sidescroller starting advices

since this is my very first time trying to make yet simple but useable sidescroller I'd like to ask some questions and hopefully gather ideas to make a good engine that can change the position of an Image in the form depending on X position of the drawn game character. I'd basically like to recreate just few seconds of a Mario game.
The starting Idea (correct me if it's wrong / poorly performance / whatever) would be to create a picture long in width and whit fixed height and upon the press of, for example, A or D keys, the drawn character moves till a certain X point, after that, character gets locked in place and if the key is still pressed, the background image starts moving.
But the problem there would be the fix for collisions, would be possible to check for the X position of the drawn background picture and set "collisions" accordingly for the character?
Other questions : why picturebox should be avoided at all costs and use the form itself instead ? Placing the greater part of the classes methods inside a timer_tick event is the wrong approach ? I read somewhere that the best way to do games of this kind would be relying on infinite loops in the forms main method, but I simply cannot even think how this could possibly works, taking in count all the times we may need to get out of the loop and do different code in different places.
Any other different ideas/approach and direct links to further explanations would be greatly liked
Edit : yes i'd like to improve with windows forms before moving to xna/unity

Assumption: You want to make a little game and its your first time working with moving graphics and you're working with WindowsForms. Suggestion: try using a more advanced framework such as MonoGame or XNA and working your way through introductory documentation and tutorials. Also WPF has a more advanced graphics platform for doing things like drawing and 3D, you may want to give that a shot.
To expand on my comment a bit.
Windows Forms and GDI (the tech behind drawing) aren't meant for this kind of use. When GDI was created its purpose was essentially drawing lines and fonts on the screen. XNA is a really good framework for learning the basics up to professional design. Unfortunately the XNA framework is no longer supported by Microsoft and as such MonoGame is the recommended development route for managed .NET 3D and 2D game development.
The WPF provides basic access to Direct3D and Direct2D, and has 2D and 3D shapes and animations built into the framework and is what WPF is based on.
But you also have the choice, if need be, to create an XNA component and embed it in a Windows Form as demonstrated in these two tutorials.
XNA in Windows Forms I
XNA in Windows Forms II
Also using a Windows Forms Timer isn't recommended because they are unreliable. The .Net Framework provides a 'Server Timer' and a 'Threading timer' that can be used as well.
If you are really keen on using GDI for a game may I recommend reading about the basics of game programming (I think there are a few XNA docs on the subject) that should guide you on things like the basic run time loop, getting input, and simple physics.

Transitioning from Windows Forms to WPF

For a long time now, I have been stuck with Windows Forms development (started with VB6, and has continued through to C# .NET 4.5), and I have pretty much hit the limit of what Windows Forms can do, both using pure .NET, and special effects with Native Code.
I have tried to learn WPF and XAML, but I get stuck right at WPF's new designer. It really seems very difficult to use in comparison to the Windows Forms designer.
I want to know if there are any alternatives to .NET's WPF designer, that are more suited to Windows Forms developers?

I like to blog about beginner articles for WPF, and there are a few in particular that may help you out:
Understanding the change in mindset when switching from WinForms to WPF
What is this "DataContext" you speak of?
A Simple MVVM Example
To summarize, the biggest difference between Winforms and WPF is that in WPF your data layer (the DataContext) is your application, while in Winforms your UI layer is your application.
To look at it another way, with WPF your application consists of the objects you create, and you use Templates and other UI objects to tell WPF how to draw your application components.
That's the opposite of WinForms where you build your application out of UI objects, and then supply them with the data needed.
Because of this, the designer isn't actually used that much since your application components are designed in code, and the designer is only needed to draw a user-friendly interface that reflects your data classes (typically Models and ViewModels)
And personally, I prefer to type all my XAML out by hand since it's faster and doesn't make as much of a mess as the drag/drop WPF designer does, although I do use the Designer on occasion to preview what my UI will look like.
So to your answer your question about if there's other WPF designers suited for WinForms developers, I would suggest that instead of looking for another designer, instead look to learn how to use WPF in the way it's meant to be used. Using WPF like it's WinForms means you miss out on much of what makes it so great :)

Well although, some people don't agree, I would also recomment to not use the VS designer. At least not to create an interface. If you may want to get a first impression of your implementation without starting the application, it's a good viewer at least as long no sophisticated things like Styles and Templates are used. But, IMHO, its drag and drop result should only be used as prototype and therefore be discarded after it's no longer needed.
Here are some reasons which are important for me not to use it.
The VS designer is working with fix margins and alignments (which is usually not necessary, if you're using the layout controls), means you have to touch many controls, if the requirements are changed. If you're deep in XAML and the WPF mechanics you can create an applications which can be modified with small effort, regarding the look and feel.
Since the designer is generating the xaml, the composition is not optimal and the UI may perform badly. I didn't measure it, it's just a feeling.
A much better alternative is MS Blend, although the start is everything else but easy. Its drag and drop result is much better that the result of the VS designer.
But it's a pretty powerful tool, which helps you to use pretty powerful elements to create a state of the art UI. I recommend to visit at least a short workshop to get an idea of its opportunities.
Back to your question, IMHO, and I think many people agree, get yourself a good book e.g. WPF Unleashed and later, if you want to know more about the details, WPF Pro. There are a lot of features which are different to Winforms. You won't get to know them by using any designer. I think that's the best approach.
Please also consider that there are many frameworks and libraries (e.g. MVVM light, WPFToolkit) out there, which are already solving some common problems. So it's not necessary to reinvent the wheel.

I know this is an old question but for the benefit of anyone else looking at this, I think I should redress the balance a bit - reading some of the other answers, I get the feeling that some of the 'don't use the designer' sentiment comes from not using it properly.
This tutorial is quite good to get you going and answers some of the criticisms in the other posts.
For instance, you can switch from the Winforms-like margin-based layout that is the default when you drop a control, to a more WPF-ish style by right-clicking and selecting 'Reset Layout'
This video covers similar ground.
I still prefer the VS2010 designer on balance - VS2013 seems to be a bit buggy when dragging and dropping onto TabItems **, (which my current project uses a lot) - but the VS2013 Document Outline view lets you move things around in that view too, which can be a real plus.
Really, though, to get the most out of WPF and xaml you need to be reasonably fluent in both the designer view and the xaml view and switching between them; if you shy away from the designer, you are missing out on something that can help you a lot.
** Edit - although this seems to have been improved in Update 3 for VS 2013, and in previews of VS14, to date I still get odd behaviour at times.

First of all, in WPF (XAML) in Visual Studio deisgner, you should always use the xaml code to build you UI and do not drag and drop you control! You need to keep your code clean. You can use Expression Blend to help you, it's more graphic oriented with drag and drop, but it's not free.
It's not a big learning curve, but I think you should learn how to do your xaml by hand instead of searching for alternative.

I've been through this process as you did. Afterwards I was teaching everyone in my company WPF. There are a couple of important lessons I have learned and everybody I know who works with WPF.
If you are working with UI controls in the code behind, .... Then you are doing it wrong. There is absolutely no need for you to deal with UI controls in the code behind.
You do not need the visual developer for clicking on it. You are much more productive by only dealing with XAML.
Use Copy/Paste. Do not trust in your typing capabilities. It will save a lot of headaches.
Think of the XAML just as a window that loks over the data. In the code behind you are changing the data. In XAML you are defining how the UI will interpret the data.
Converters are amazing. As soon as you get a key amount of Converters, your productivity will rocket Sky high. They will take over the role of the crazy amount of control eventhandlers that hide or resize, or what ever about UI,
It makes UI development fun. Especially once you find out how it likes to play along with Asyc processes. It really takes away a lot of the headaches that were caused by Winforms.

Is it practical to port code from Flash to C#?

My goal is to gain a better understanding of the characteristics of C#, and become more comfortable creating simple apps. I am fairly competent with Flash (Actionscript 3), and found an old Tic-Tac-Toe game I'd written. I started wondering about porting this code into a C# application. Not knowing much about C#, I'm wondering how difficult the migration would be.
On the one hand, the underlying game logic is syntactically similar, and therefore would be easy to port.
However, as far as the graphics are concerned, I don't even know where to begin. So far, I've only exposed myself to Windows Forms and Console apps in C#.
I'm wondering if these Flash concepts have similar analogs in C#, or if the procedures and syntax are radically different:
Placing graphic elements on a stage
Rendering lines from start/end coordinates
Event listeners on movie clips
Swapping the image inside a graphic element (or, in my Flash version, nextFrame() in a movie clip)

You may want to try developping your little game using Silverlight. Silverlight applications, coded using C# and Xaml, are pretty similar in form with flash applications, and you should find everything you need without trouble.
So I suggest you download the Silverlight SDK (free) and give it a try.

Firstly, Flash is to WPF (close enough) as ActionScript is to C#.
The WPF/Silverlight model is much more similar to Flex that it is to Flash. Everything is added to the UI tree as a object, even lines.
Likewise, adding event handlers to controls (like a button click) can be done in the "code behind" (the code that lives with the view), but the recommendation is to use the MVVM pattern. If you are new to the concepts of separation of concerns and unit testing, feel free to start with the simpler "code behind" method.
While WPF and Silverlight are very similar, I'd recommend starting with Silverlight as the SDK and available samples are richer. You can easily move onto WPF later on (though porting an application from Silverlight to WPF is not automatic).
Swapping images, as you mentioned, would be done via "Visual States" in Silverlight (or possibly changing the image reference, which is more "hacky").
Have a look at the following links to get started:
Learn # Silverlight.net
Silverlight on MSDN
Shapes and Drawing (Silverlight)

If you're looking specifically to do games and the like, you may wish to look into the free XNA framework. However, there will be differences as Flash gives you far more ability to "set up" things beforehand and modify them.
Placing graphic elements on a stage
If you go the XNA route, you will be drawing sprites using the spritebatch, you tell them where and how to draw and that's where they will go
Rendering lines from start/end coordinates
In windows forms you can do this via a simple System.Drawing call, however if you wish to do this in XNA, you will either have to make a 1 pixel square and stretch/rotate it to what you want, or use 3d primitives (Though this will limit you to a 1 pixel line)
Event listeners on movie clips
Look into delegates, but there isn't really an equivalent for movie clips to my knowledge
Swapping the image inside a graphic element (or, in my Flash version, nextFrame() in a movie clip)
This is fairly simple, depending on what you mean. If you want to, say, animate a sprite. You can do this by moving the source rectangle or changing the texture of the spritesheet. If you mean the screen as a whole, this is mostly handled for you provided you use the spritebatch. In windows forms you'll have to do more of it yourself, but the base concepts are the same.
Overall it's not that bad, but if that doesn't sound appealing check out Silverlight. It's basically C# styled flash so you may find the transition easier.
Good luck and hope this helps.

C#/.NET: Creating Dynamic Visuals in C#

NOTE: I am not exactly sure how to title or tag this question, so if you have any ideas, PLEASE help!
I'm currently envisioning a few possible projects that involve dynamically rendering something (whether it is a point, a line, text, or music notes on a staff, for hypothetical example), but, if I were to undertake these projects, I'm not really sure how to approach this design. What I'm curious about is sort of how programs like Word, or Geometer's Sketchpad, or Finale, create a blank "canvas" and render text, geometry, or music on it, respectively - how can this be done in C#, or in .NET, in general?
First of all, what is the best framework/platform to use: WinForms, WPF, something else? I'm open to many options, as I'm just trying to understand the different ways this can be done.
Next, how can I create such a "canvas" (if we go back to that metaphor) using the different frameworks you answered for part 1? And also, how can I render stuff onto it?
I hope my question isn't too confusing or n00bie. I just don't know how to approach such a prospect. Thanks!
UPDATE: I have now posted a follow-up question which is less broad. I have provided an hypothetical example of what I would like to accomplish. However, I will still accept an answer here, even though my question isn't fully answered.

WPF would probably suit your project well. I like the book Pro WPF in C# 2008: Windows Presentation Foundation with .NET 3.5, it covers most of the topics you're asking about.
You'll probably get better answers with a more focused question. The scope of your question is too large to be answered easily or concisely.

WPF makes it easier to refactor designs for such a project by easily moving shape drawing code between just drawing simple shapes and contents of controls. If you need the richness of custom controls, WPF allows a fairly smooth transition.
Most of the graphics can be defined in XAML which means you can export them from programs like Illustrator or anything that generates the standard SVG vector graphics, via an SVG-XAML converter.
I like WPF Unleashed and it has a nice discussion of 2D graphics and how to use the DrawingContext class for such a visual editor.

Do you know that there's an event called Paint? Everytime Windows OS needs to displays or repaint something on your form, this event is triggered. So, you create a Paint event handler, and everything is possible in that. For eg:
Word: you have a WordDocument data structure with the formatted tags and stuffs, you paint each character/ each word or each block of words one-by-one using a desired brush/paint and font. You might also wanna paint your background and stuff... If, for example the user change the font of 1 particular block, your WordDocument must change something to reflect that font change. And then you do an myForm.Invalidate() to repaint your form (and thus update your font). => Dynamically update your GUI.
Sketchpad: you need datastructures such as Line, Point, Triangle, etc. And then, each time OnPaint is triggered, you paint it dynamically. E.g: myGraphics.DrawLine(..), myGraphics.DrawCircle(..)
Similarly to Finale.
One thing you should do is to handle your data structure and drawing classes carefully, and instead of drawing everything in your OnPaint() method, you create several DrawMe(..) methods in your entity classes, and ask them to draw themselves. E.g: myCircle.DrawMe(..), myScore.DrawMe(..)
Hope that'll help,
Ben

There is no universal answer to your question - it is too generic.
Are you talking about dynamicly created controls, standard UI components (dropdowns, buttons)?
Is it vector graphics - like in drawings, or may be it is 2D image processing - or is it 3D?