|
Heres the deal:
I was looking at a control this guy made, its a menu control but behaves in a way I have never seen.
- You place his menuProvider control on a form (in design mode).
- You place the standard .NET mainMenu control on the form as well.
Now, You can add menuEntries to the .NET mainMenu control -- but in the properties panel it has a new property that ties it to the menuProvider. This standard non-subclassed .NET mainMenu has a new custom property?
How?
Did I miss a huge chunk about programming windows controls where you can modify properties of standard delivered objects?
Matthew Hazlett
Windows 2000/2003 MCSE
Never got an MCSD, go figure...
|
|
|
|
|
It sounds like he used the IExtenderProvider interface, which is implemented by the ToolTip and HelpProvider controls that you may have used already. Take a look at the docs here[^].
John
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek.
|
|
|
|
|
As the first reply said, he is using an IExtenderProvider. This is a common approach to providing functionality without having to redefine the types you want to extend. The HelpProvider is one example, as is the ToolTip and ErrorProvider components.
There's several good articles here on CodeProject about them, too. Try the following search[^]. There's a lot of good tips / ideas in these implementations as well.
I've also seen these things used for menus to provide images. While many people extend MenuItem and owner-draw the icons, some have used an IExtenderProvider so that you don't have to break the designer trying to use derivative (or completely custom) classes. I created one some time back to provide column sorting for a ListView on any column without going to the usual trouble of providing your own IComparer implementation and overriding key functinality. The provider does it for you.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I am currently writing a DockingManager which can be implemented by a form and controls Control dervied clases which also implement my IDockingControlled interface.
The user can drag the control to the desired side of the form which they want the control to dock to or they can drag it away from the sides to have it floating. All this works.
However when the control docks to the side of the form, if the form is larger than the control then the control is resized and the controls original size is drawn fine, however the extra area form the resize flashes as if the control is being constantly redrawn and undrawn in the area.
Does anyone have any idea what the problem could be?
thanks
|
|
|
|
|
So when you dock a control, the control is resized or it's not? You said "the control is resized and the controls original size is drawn", but also mentioned in several places that's it's resized. Is it resized or isn't it?
If it's being resized, first make sure that your painting operations (if any) don't invalidate the entire region and only invalidate the regions that need re-drawing. Another thing to look into is double-buffering the painting of these controls if you're writing them yourself. See the Control.SetStyle method and ControlStyles enumeration documentation for more information on this.
Also, if you can, make use of a Control's Dock property, which makes resizing a control dynamically a little smoother. You can resize it yourself but make sure you do it quickly without a lot of calculations. This most likely isn't the problem, but it's something to keep in mind.
If this doesn't help you, some code snippets might be helpful to see what's going on. With what you provided, it's a little difficult to determine exactly what's wrong.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Just a guess, but it sounds like you could have an infinite loop going on in the size changing event handler code. Put breakpoints on your SizeChanged and/or Resized handlers to see if they are repeatedly being called.
John
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek.
|
|
|
|
|
it is. I think that when you set the Dock property in a control it constantly tries to resize the control to be the width of the container.
|
|
|
|
|
We have a very large multi-threaded Visual C++ product and are trying to migrate it, in manageable pieces, to C#. In many of these pieces a new C# form can be written to replace a similar C++ dialog. However, to ensure that the C# form gets overlapped properly, does not get hidden behind its parent etc. we the new C# win form dialog to be parented from whatever C++ window it was created. I haven't seen a way to accomplish this so I am hoping someone here might offer some advice or point me to an information source. Thanks in advance.
|
|
|
|
|
If you know the class name of the window, you can use FindWindow to find the handle of the window in question, assuming you can interop that function in C#. Then pass that handle as the parent of the window you create.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Thanks Christian.
I actually know the window handle of the parent.
The problem ( I think ) is how do I convert a C++ window handle into something that I stuff into a C# form's parent property? Or is there a better way to solve this problem?
|
|
|
|
|
See my post[^] below. One way would be something like this (should only work in-proc, though):
Form f = (Form)Form.FromHandle(hWndParent); ...where hWndParent is an IntPtr that wraps the native HWND.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
One important thing to understand is that the .NET Framework Class Library (FCL) pretty much encapsulates native APIs like those in Windows Management, Common Controls, GDI+, various COM libs, and more. A "C# window" (keep in mind that C# is just a language that uses the FCL and targets the CLR) is still tied to a Window resource, so it has an HWND (see the Handle property).
If you simply call Form.ShowDialog without any parameters (or with null), the FCL uses the native GetActiveWindow API. If the would-be parent is active, then you don't need to do anything else. If you want to parent the Windows Form to a different parent, you need to use that would-be parent's HWND to get an instance of an IWin32Window. You should be able to use Control.FromHandle and pass the native HWND to get a Control reference, which implements IWin32Window. Pass that to ShowDialog then to re-parent it.
One other option you might consider is Managed C++. If you already have a good VC++ code base, Managed C++ might be a better way to go for an interim. Even without using the managed extensions, you can throw-on the /clr switch and have a managed (mixed mode, mostly native) application. If you added a few __gc class in there to encapsulate your native Windows, you would have a little more flexibility with interop'ing with C# since all languages targeting the CLR compile down to IL (unless they contain native instructions like a mixed mode MC++ assembly), so it doesn't matter what the source language of an assembly is.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks Heath.
That's exactly what I was looking for.
|
|
|
|
|
Hello again Heath;
Could you have left out a step in your explanation?
Calling Form.FromHandle(myhwnd) returns null.
I have verified the CWnd.m_hWnd value passed by the C++ code in the debugger and also verified the validity of the passed hwnd by finding the window handle in Spy++. I have inspected the hwnd coming into the C# code as an IntPtr and see that it is the same as was passed from C++.
Any ideas?
|
|
|
|
|
Managed code can't communicate across application boundaries (for which a process is definitely one of them) so you might not be able to get the CLR to wrap an externally defined HWND, but this is all in the same process, right?
If that doesn't work, then you may be stuck with the parameterless ShowDialog implementation.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Very interesting idea! I personally have no idea off the top of my head (although Heath might), but my best guess would be you'd have to write a custom Designer class (or something else that implements IDesigner).
Let me look a bit more into it, and maybe I'll dig something up...
Jeremy Kimball
|
|
|
|
|
Nope, you're right. Some of the IDesigner implementations (like the ControlDesigner let you capture notification messages. See ControlDesigner.WndProc for more information.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
You extend ControlDesigner with your own designer class and override it.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
You don't. The designer host "hooks" your messages and routes them through the designer. Read about the ControlDesigner[^] in the .NET Framework SDK.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
|
|
I have a Hashtable. I need to go through it and delete some of the entries.
The problem it as soon as I delete an item the enumerator becomes invalid and the program crashes on enumerator.MoveNext. Do you know a way around this?
Here is the code:
<br />
IDictionaryEnumerator enumerator = table.GetEnumerator(); <br />
while (enumerator.MoveNext())<br />
{<br />
if (IsSubfolder(virtualFolder, enumerator.Key as String))<br />
{ <br />
table.Remove(virtualFolder); <br />
}<br />
}<br />
|
|
|
|
|
You could split it into two loops: One to mark those entries for deletion, then one to delete all marked keys...
Also, I'm not positive, but I believe a construct like this would work...
foreach( string key in table.Keys ) {
string value = (string)table[key];
if( ... ) {
}
}
Jeremy Kimball
|
|
|
|
|
No, foreach is a compiler "alias" that gets the enumerator and enumerates the collection (rather, the IEnumerable implementation). Doing that is the same as what he was doing originally.
Your first idea is one way of solving it, though.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
*sigh* yup, you're right...I said earlier, my brain is broke today 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
