How to lock a window to another? [winforms] - c#

I'd like my software to display a tutorial window when it first starts up and to have this window appear 'locked' to the right hand side of the main window such that, whenever I move the main window, the child will follow. How can I accomplish this?

As mentioned by John Gietzen, you'll need to trap the movement of your main window and reposition the child window.
However, this will break down if the user moves the child window directly.
If you want to enforce that the two stay together always, you'd be much better trying to put these into a single window. Having two windows and trying to override the normal Windows behavior is probably not a clean approach - it will be more confusing than just trying to make a single "normal" window.

Generally, you will need to trap the OnMove event for the parent window and relocate the child window.
I do not believe that there is a WinAPI way to do this, so it will be a bit of manual coding.

As John Gietzen says, there's no way to get Windows to do this for you, and if you do it by handling OnMove events you'll get a lag when the user moves or resizes the main window.
An alternative is to widen the main window and put the tutorial window within it, down the right hand side.

Related

Change application name shown in Windows 10 taskbar [duplicate]

I develop with VS2010 in C# and I would like to create a WPF Window which have a taskbar text different from the Window title.
The property Title set both the window title and the taskbar text. Is there a way to set them separatly?
First, let me reinforce what Cody Gray said in both his answer and comment - this is non-standard behavior, and you should have a darn good reason for doing this.
That being said, I would take a nearly opposite approach to Cody's point #1. I would create a window WindowStyle set to None, and recreate the title bar (which could include the icon, your "pseudo-title," minimize, maximize, and close buttons, and perhaps even the standard Windows menu. You will also need to handle resizing (which can be done by setting ResizeMode to CanResizeWithGrip, but it adds a Grip control to the bottom of your window, which makes it look slightly different than a "normal" window).
The Title property of this window would then be the Title you want to show in the Taskbar, and the "pseudo-title" in the title bar you create would just be a Label or TextBlock bound to whatever you want your window to show.
It is a little complex, but really not too difficult to do. You will probably run into some Gotchas along the way (for instance, how the Window looks on different OS's or with different Windows themes applied). The nice thing is that it requires no Interop, and a majority of it can be attained using XAML only.
There are lots of examples online (here is one I picked at random).
Again, you'll have to decide if it is worth the effort to create a non-standard behavior. YMMV.
Basically, you have two options:
Draw the taskbar button yourself, rather than letting Windows handle it. This is actually reasonably simple, as far as owner drawing things goes.
Manage two different forms/windows simultaneously. You'll need to create a hidden main window that will appear on the taskbar and own your second window. Your second window will be visible, display its own caption on its title bar, and contain your actual user interface, but won't show up on the taskbar (set its ShowInTaskbar property to "False"). You'll have to write code to show the second window whenever the first one is activated using the taskbar.
I recommend that before starting down either one of these paths, you carefully consider whether you really need this "functionality". It's difficult to tell what goes with what if you have what is effectively one window with different names in different places.
try to use this:
http://www.codeguru.com/forum/showthread.php?t=3833
in conjunction with
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/6b97a6de-0480-4339-8ed0-cb7cdb27bd83
The first one works fine for me in classical .NET form application when I have made window without title bar and want some text in task bar icon.
The second one you need to handle low level WIN32 messages in WPF window (but this works only for top level one).

How to make a window manager?

I tried writing code several different times, but I came to an error with each one.
Basically, I'm trying to make "windows" similar to say Explorer, Paint, MediaPlayer, where you could drag then around, interact with them, minimize and close. Of course, if you clicked on a window, the one below it (they can overlap) shouldn't get affected.
I know how to do this, I have a list of the class I call Window, loop through it, and I only interact with the first window to contain the location of the mouse-click. This way, other windows overlap won't get affected.[1]
Next, I had to make it so that two buttons that are overlapping don't get activated when the user clicks in the "intersection of both buttons." I handled this by using the same method I used above.[2]
But the problem I'm facing now is that, if I hold the left click, but then I decide not to click a button, I drag the mouse away from the button, and release the left click, so that the button-click event won't be activated. But, when I remove the mouse from the boundaries of the button, and say, into another.. the new button get activated. Which it should not.[3]
My set up is like this:
I have a class called Window.
In Window, I have a list of the class called Interface (similar to the Control class in WinForms).
And each Interface has a struct in it that contains 4 bools, if the left/right is currently down, and if they were down in the previous processing. (prevLeft, prevRight, currLeft, currRight)
So, I'm ready to discard that (I have not yet, so I still have the source code), but I need a good structure for making an object-oriented type of application. However, I am not using WinForms. I need help with the structure alone, so no actual code is necessary, description is enough. I need to avoid the 3 problems I mentioned above.
Creating your own Window Manager is not an easy task. I know it because I'm making one too ;)
You can use an existing, though maybe not the best solution, like for example Nuclex.UI, which I personally rejected when I first saw it, but if you're not dead set on making your own WM, I suggest to use that or hybrid WinForms-XNA approach.
But if you're really dead set on implementing a custom Window Manager, you have to understand how any other WM works. Since we're talking about XNA, it means Windows, and that means Windows Explorer, which is a great thing to learn from.
You have to recognize how the simplest things work, and it's really not so hard. The hard part is figuring out what logic is updated when, and how to not spend all the CPU on only UI updates. Let me just give you a few hints on how to solve the problems you mention in your question.
To keep track of all windows, I'm using a Dictionary<string, Window>, where Window is a custom class, and the string is its unique name for rare cases where I have to call windows by name. Think of it as a window GUID or Handle. But you can just make it so that a "Form" can only appear once, and store all references in static variables.
To make WM understand what control you're clicking I use rectangles and check if they contain a Point which is at Cursor coordinates and has {1; 1} pixel size, which is probably about the same way it's done in Windows Explorer. To do that your WM needs to know in which order to update the active windows. Usually you'd want to start from the topmost window and continue towards the end of the list of active windows. For that you can just iterate through the list with a foreach loop.
But that's not all, because every window itself is a Container, which means it contains other controls, some of which may even be Containers themselves, like WinForms Panel class. This means you have to iterate through each of the Windows' Children controls. The update order should make sense too - update from the topmost child to the bottommost, recursively for Container controls, in case they also have Containers in them. This basically means you'd want to implement a recursive GetAllControls() method for your WindowManager class that would iterate through all Containers and return a list of all Controls.
Drawing all those Controls should be done in reverse order of updating them, so you can just GetAllControls().Reverse() and iterate through that in a foreach loop.
Where to draw and what to update depends on all the parent containers the current container has and their combined offset from the top-left corner of the game window. I solve this by storing a ParentContainer reference in all children controls to get the appropriate DrawRectangles and update areas via recursive properties.
When you click somewhere on the screen and a click is registered on a Control, make the WindowManager remember that (bool clickRegistered) and not run any OnClick events on any underlying Controls.
Windows Explorer remembers the control you clicked and will activate its OnRelease event if the cursor is then released in the update area of the very same control. So basically Windows Manager only does something when you release the mouse button. You can make your WindowManager and Controls to handle click events differently, like firing an event right after you press the mouse button, i.e. OnMouseDown. But remember that Microsoft aren't noobs and there's a reason for that behavior in Windows Explorer, and it's because if you accidentally press a mouse button somewhere you didn't intend, you can still fix it by moving the cursor outside the pressed control's update area and not run its action.
At this point you might be thinking "Is it really worth implementing all this?" For me the answer was "maybe", because I was a total noob in both C# and XNA at the time I started, and now I know my game, which was originally supposed to use some Window Manager, is going to benefit from my own WM implementation far more than from ready third-party solutions. And besides, it's a great exercise in logic and programming.
But if you'd like to think of yourself as a game developer, you should think in terms of reaching your goal as quickly as possible, i.e. actually making a game, and not the game engine. So in this case, better make use of existing solutions and start selling your product.
Instead of having the structure with the 4 booleans (similar to xna), how about you make a way to tell where the mouse "is." So in a sense, the mouse is in Window number 5 which is Paint, and the user is holding the mouse down on interface/control number 2 which is a button.
That sounds like it could work.

How to detect two windows near each other

I've got an MDI application, which allows users to drag and move windows around the screen. I would like to detect when two windows are near each other, but I am unsure how to go about this. I am using the WPF MDI library to handle MDI, however I am unsure whether it has this functionality built-in.
If not, what would be the standard approach to tackling this issue?
What I thought of doing is - while a window is being dragged, the X and Y co-ordinates of surrounding windows is constantly being checked, to see if they are within close proximity or not. However if I have many windows, this might end up causing some lag. Any ideas?
Just incase anyone looks this up later on - this is the approach which I took:
I added a DoDragDrop event to my source window being dragged and set the other window as the drop target. It might be specific to my requirements, but the end result works perfectly!

Repainting problem with MDI child created by SetParent API

I have a legacy app written in C that consists of a main window and several mdi children opened from menu options. To allow new mdi children to be written in C# I have created a C++ COM interop layer that is called by the C code and in turn calls the C# code. I then use the SetParent API to set the C main window as the new parent of any C# window opened. This seems to work - the C# window behaves like an MDI child of the main window. BUT, the child window does not paint properly and only gets worse if you move other windows over it or move it to the edges of the main window - it gets painted with parts of the other windows or leaves bits of itself lying around as it moves. In addition the screen doesn't respond very well eg you cannot tab from one textbox to another.
Please don't question the architecture of my solution (believe me, this is the only way), but if you've ever seen a problem like this with a child created by SetParent I'd love to hear if you managed to fix it.
Try these things:
Add Application.DoEvents inside a processing loop that is normally running when things go bad.
Try refreshing the MDI forms from within the main form's paint event.
I don't totally understand how SetParent() works; that being said, here's some more things to consider:
In the MSDN community content of the SetParent documentation, Chango V. from Microsoft added that you: "need to call SetWindowPos(SWP_FRAMECHANGED) when changing between null and non-null parent."
Also, are you sure you are actually running the .NET Form message loop? Did you call Application.Run(yourManagedForm), or are you running your own message loop in the C code? If you're running your own message loop, you may need to forward messages to the WndProc method on your managed form after filtering it through PreProcessMessage. You would need to expose an interface to these as they are protected. I don't know how valid this is, though.

WPF: Create your own screen-saver if your running application is 'idle'

Is there a way to create a window (similar to a screen-saver) that will be displayed once your running application is not 'interacting' (or being idle) with the user, meaning to say, no mouse movements happening on the application.
Some of my friends suggested to use a Timer for this one. Any suggestion for a good head start? Thanks.
If your looking to create your own screensaver just create another form. Remove the border from the form. Make it the top most and start maximized. Then you just paint the control to do whatever you want.
Then wire up the form to check if the mouse moves or a key is pressed. You'll need to create a timer that will determine if the screensaver should be shown.
This might help: http://www.codeproject.com/KB/miscctrl/csharpscreensaver.aspx.
There's a similar question on StackOverflow here: How to invoke the screen saver in Windows in C#?.

Categories

Resources