1) The ui becomes offset and to be able to interact with the UI elements you need to move the mouse to some odd place.
The ui becoming offset could suggest that your viewport is wrong. So just for safety you could set the viewport straight after you change its size ..
But when you say that you need to move the mouse to some odd place. hmmm.. Can you put up some screenshots of that ? Is the place where you have to click where you would expect the element to be if it were being rendered in the correct place ? That might suggest that you ui code is wrong, either rendering or hit detection, but maybe not as well.
3) Normally, when you put any program into a FULLSCREEN mode your mouse is unable to leave it, but with our game... it can... why?
I can move my mouse to the second display when i switch to fullscreen mode, so I would say that it's normal behaviour. I used to know how to handle that issue with XNA, but I haven't yet worked it out with SlimDX. I think how I did it in XNA was actually just monitor the mouse position and limit it to the window bounds with a setmouseposition() function. I'll look into this for both of us.
However, it looks like you only set the client size of the window when in windowed mode. I'm pretty sure it's necessary that you also set the size of the window when in fullscreen mode. ResizeBuffers will only resize your backbuffer; it's probably get squashed back down to fit on the form surface.
I don't set the window position in fullscreen mode, and I'm pretty sure it works properly. Edit - checked this, and because I'm using SwapChainFlags.None it just adopts the desktop resolution. Just learnt something about resizing the 'front buffer' ... I tried setting the form manually, but that just won't work, it can and will ignore the width height values you pass in. Instead, use
swapChain.ResizeTargets()Which will also resize your window, and fire a Resize event, so that your backbuffers can adjust.