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.
Related
I'm using SDL2 (specifically, a C# wrapper of SDL2 (SDL2-CS) but it has all the same features and functionality) and am trying to make a game editor with it. Everything's going really well, but there's one piece of functionality I'd really like. That's to make one specific window always appear on top of its parent window, while making the parent window inaccessible. When the window is minimized and you open it, it opens and focuses on the child window. When you try to access the parent window, it flickers and you hear a windows error message.
I know how to manually focus on a window, but I don't know how to make a sort of "link" like that between two windows, where window A is inaccessible until window B is closed.
I know the Windows Forms equivalent is Form.ShowDialog(). That's what I want, but currently the way it works is like Form.Show(). To clarify, I'm not using Windows Forms or any other library/framework. I'm using pure SDL2; this was just an example.
I'm looking to implement this using pure SDL2.
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.
I have an interesting case to solve:
I have a native (winapi) application, which uses MDI. This application allows me to extend itself with a simple scripting language. The scripts are launched on different thread than UI thread (although I can get the UI thread ID with appropriate functions). The scripting language also allow me to launch any c++ code (through LoadLibrary).
What I would like to achieve is to create a new window inside this application, which could host WPF and "attach it" as a MDI child window to MDI client (mdi area). Also, I would like this window to properly "talk" to MDI area, for example update list of windows in mdi menu.
So far, my first guess was to just create a WinForms window, host WPF inside, and then try to make it mdi child window by setting MDI client as it's parent (because my hosting application is not written in c#, I only have a handle, so I did this with User32.SetParent() P/Invoke). This worked almost well, after I attached my script thread to GUI thread, but I had few problems with it: the MDI menu with active windows did not update, the window did not interact correctly (it stayed on stop when it shouldn't etc.).
Then, I tried to set flags (style, exStyles) with SetWindowLongPtr. It changed my window's behavior a bit, but that was still not it.
Now I'm considering using CreateMDIWindow function, or doing it by SendMessage, according to docs sending message should create a window, even if I send it from different thread. The problem is, that this way would give me a native handle only, and I could not find (yet) any way of hosting WinForms / WPF inside it.
I'm curious if anyone tried to do something similar and had any results with it? Which way would be the best - trying to create a WinForms window and add it to MDI client, or create a native window and try to host WinForms in it (any particular way of doing that)?
Most answers for this question I have found are dealing with situation where hosting application is managed, so you can just set .MDIParent property, which won't work in this case I'm afraid.
Assume i have an empty form 100px by 100px at 0,0 coordinates on the screen. It has no border style. Is there any way to have this positioned BEHIND the desktop icons?
I would assume this would involve the process Progman because thats what contains the desktop icons. But no matter what i try... getting window handles and changing parents etc, i cant seem to get the window to appear behind the icons.
Any ideas?
Essentially you want to draw on the desktop wallpaper. The desktop hierarchy looks like this:
"Program Manager" Progman
"" SHELLDLL_DefView
"FolderView" SysListView32
It's the SysListView32 that actually draws the desktop icons, so that's what you have to hook. And you can't just stick your form on top of it; you have to grab a WindowDC to that handle and draw on the DC.
It can be done - it has been done, but you're going to be using a lot of interop. Forget about doing this with a traditional Winforms Form. I don't think I've even seen it done in C#, although somebody did it in python, if that helps. I'm not a python coder myself, but the code is pretty short and easy to understand.
There is a solution to this problem, at least for Windows 8. I postet it in form of an article on CodeProject, so you can read about it here:
http://www.codeproject.com/Articles/856020/Draw-behind-Desktop-Icons-in-Windows
This works for simple drawing, windows forms, wpf, directx, etc. The solution presented in that article is only for Windows 8.
Google-fu led me to this MSDN forum question:
http://social.msdn.microsoft.com/Forums/en/winformsdesigner/thread/c61d0705-d9ec-436a-b0a6-6ffa0ecec0cc
And this is a blog post regard the major pitfalls with using GetDesktopWindow() or dealing with the desktop handle (as per your other question: C# Position Window On Desktop)
http://blogs.msdn.com/oldnewthing/archive/2004/02/24/79212.aspx
You also don't want to pass GetDesktopWindow() as your hwndParent. If you create a child window whose parent is GetDesktopWindow(), your window is now glued to the desktop window. If your window then calls something like MessageBox(), well that's a modal dialog, and then the rules above kick in and the desktop gets disabled and the machine is toast.
Anyway, I suspect that it probably CAN be done, but whether you should is another question.
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.