|
I finally got it. PostMessage works with WM_Keydown and WM_Keyup but you must make wParam and lParam type UIntPtr. Thanks for your help. No "ragtag" required!
|
|
|
|
|
Just a quick question,
Is there any way in the Framework that my application can get an event when Windows jumps into and out of full screen mode (EG, a full screen DX or OpenGL application starts/ends)? And if not, is there anything in Win32 to achieve this?
I am aware of the notification in Shell32 for Application Desktop Toolbars, however, that would mean creating a Desktop Toolbar?? Is there any other way?
Thanks!
--
Rob Hutchinson.
|
|
|
|
|
Going into full-screen mode is really two different operations. One is optional, and requires changing the screen resolution (for which you can handle the SystemEvents.DisplaySettingsChanged event). The other is simple creating a dialog with certain window styles set and does not generate any such events. The event I mentioned above (which fires in response to the WM_DISPLAYCHANGE system notification message) is really about the only change you have beside possibly hooking certain APIs based on the graphics engine used. Even if a particular runtime would provide such notification, I really can't help you there.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hy everyone!
I do want to add an item to Outlooks contextmenu. It should be like this:
When rightclicking in Outlook the contextmenu should contain my item to start my programm.
If possible this should only happen when rightclicking Outlook contacts (meaning in the contactitem contextmenu).
When selecting my item my programm should be started. If possible it should also be sent the data of the selected contact, but this isn't a must have but if it is possible it would be wonderfull. 
I had a look in the MSDN, I had a look in the web and found some pages concerning (context) menues, but so far there hasn't been any for solving my problem. 
So if anyone of you knew a page where to look for it would help a lot.
Or if anyone had a sample of a similar program this would help me too.
Thanks!
Stephan.
|
|
|
|
|
You should start by reading Outlook 2003 Technical Articles[^]. You use the DTE (design-time environment) plus the Office interop assemblies (with Office 2003, these come with Professional and larger; for Office XP the official PIAs can be downloaded from http://msdn.microsoft.com[^]) to extend the UI with context menus.
This is for COM-like behavior, though. It's a poor design to just start your application and expect to pass data to it. The command line is pretty much out, unless you want to pass a moniker to the Contact in Outlook with your application then uses. That wouldn't be an easy task, however. DDE is out-dated. The best way is to expose your .NET application as a COM server and do it the right way - the same way as other interoperable applications do with Office (in fact, it's how you're using the Office APIs in .NET or any other environment).
There's lots of documentation in MSDN[^] about all this. Search for articles about extending Office with .NET. While you may not find any specifically for Outlook, there are a lot for Word and Excel that are very similar in nature.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
well we are still using Office 2000 on those machines we do code on.
Well there are different versions available on the machine around us and our aim is to make our proggy work no matter which version of Office might be used, but well, maybe our aim is far too complex.
But anyways: Thanks for the hints. I will look them up and I guess there will also be some kind of "general solution" for all versions of Office. 
Stephan.
|
|
|
|
|
And the Office typelibs are backward compatible, which means if you create the interop assemblies yourself (using tlbimp.exe or VS.NET's Add Reference to a COM library) for an older Office, almost all functionality from that older typelib will work in newer Office systems. This is fundamental to COM when written correctly (and Microsoft most often does; only some interfaces may be deprecated when necessary). So, just create interop assemblies from Office 2000 (the PIAs - Primary Interop Assemblies - from Office XP may in fact work, so long as any CLSIDs didn't changed; IIRC, only new COM objects had new CLSIDs) and use those. They will work with newer Office builds.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Just ran across An Introduction to Programming Outlook 2003 Using C#[^] today on MSDN - something I read daily (as every serious developer should). You should find it helpful.
Don't forget to read Exposing .NET Framework Components to COM[^] in the .NET Framework SDK to know how to correctly expose your .NET components as COM controls, like always declaring a GuidAttribute for classes and interfaces, never changing a published interface (inherit from it), and never using auto-generated class interfaces (.NET is tolerant of this, but COM is not).
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Using the code written by Georgi Atanasov in his article
Customizingthe header control in a ListView[^]
if you use the XP theme by calling:
Application.EnableVisualStyles();
the header control is re-set to the orriginal size rather than being increased. Has anyone found a way to keep the custom header height with the XP theme switched on?
|
|
|
|
|
If you have a question or comment above a specific article, post it on the article's message board at the bottom.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Using the code written by Georgi Atanasov in his article
Customizingthe header control in a ListView[^]
if you use the XP theme by calling:
Application.EnableVisualStyles();
the header control is re-set to the orriginal size rather than being increased. Has anyone found a way to keep the custom header height with the XP theme switched on?
|
|
|
|
|
I have a control wich im trying to draw using its Graphics object in another method , but the control remains blank (just the background color)?
|
|
|
|
|
One problem can be coordinates.
All controls GDI+ drawing is relative to the control not the parent. control.Bounds is in parent coordinates while control.Clientrect is control coordinates (i.e. it will have (0,0) as the top left).
If you make the control bigger, do you see the drawing you were expecting?
Gary
"A fellow with the inventiveness of Albert Einstein but with the attention span of Daffy Duck."
Tom Shales talking about Robin Williams
|
|
|
|
|
Hi there,
first excuse the bad title but i don't know how to call me problem else *g*
I think everybody knows Outlook - if you click on anything there like "calander" it will appears in the right part of the window.
i need something like that. I've got the Outlookbar on my left site, but how can I realize it? I mean can I predefine (VS.net) where my buttons, checkboxes, ect. should appear when the user clicks on something in my left bar?
Or have I to programm it fully by hand in my code? That wouldn't be could, because I would have to test every position by hand *grrr*
Thx!!
-bb
|
|
|
|
|
This isn't something you can just throw together with the designer, unless you've bought some expensive third-party control that does this for you.
It's quite simple, though. A good object-oriented design would place the Outlook-like sidebar on one side and a container (like a Panel on the other. For each clickable icon in your Outlook-like sidebar, you would implement a UserControl (for example - could be any Control derivative although a container control is typically best) in your project. You need to associate that control with your sidebar icon. You could store the Type in the Tag property (if applicable) for the sidebar icons, or use attributes or whatever.
When the icon is clicked, you create an instance of that Control (perhaps maintaining a Hashtable with types and instances so that you can simply reuse a previously instantiated instance) and parent it (i.e., use Pane.Controls.Add) to the Panel on the other side. When a different icon is clicked, remove that Control (if an instance of it is still held - perhaps in that lookup table I mentioned above - it will remain in memory) using Panel.Controls.RemoveAt(0) (for example) and add the Control associated with the icon that was clicked.
This is really a simple OO design and there are many examples of similar designers here on CodeProject. I suggest trying a search or browsing the categories to read a few of these for specific details.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hey thanks a lot for your help! That was what I'm looking for! Would you say it is better to access the UserControls via:
Panel1.Controls(index)
or with a help-variable - such as:
private Control _ctl = null;
TextBox tb = new TextBox();
tb.Text = "Hi!";
_ctl = tb;
panel2.Controls.Add(_ctl);
??
on the second example: why some people write "this.panel2.Controls.Add(_ctl);" and not like I did in my example without this. ? Thx!!
- bb
|
|
|
|
|
You should really read the .NET Framework SDK documentation. Panel.Controls[index] (not parenthesis) is for accesing a Control based on its index. You can't add a control that way, nor can you set a control with a previous index (there is not set accessor defined for the Controls collection property - it's read only). You must use Panel.Controls.Add as you saw below.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Oh sorry - it was a missunderstud!
What I ment:
------------
TextBox tb = new TextBox();
tb.Text = "Hi!";
panel1.Controls.Add(tb);
//access via
panel1.Controls[index].blabla();
or with a help-variable - such as:
private Control _ctl = null;
TextBox tb = new TextBox();
tb.Text = "Hi!";
_ctl = tb;
panel2.Controls.Add(_ctl);
//access via
_ctl.blabla();
- bb
|
|
|
|
|
Either way works. What matters most is how often you plan on accessing the control. Repeated calls to panel2.Controls[index] require more instructions, so using a field or variable is a better choice.
Besides, you can't access it like panel1.Controls[index].blabla(); like you declared above. Panel.Controls[index] will always return a Control. You can only call methods or access properties declared on the Control class or inheritted from a base class. You must cast it to your class in order to call methods or use properties declared such as blabla() (for example). In this case, using a field would be easier but you don't need to pass TextBox to a Control like you're doing in your block:
private Control _ctl = null;
TextBox tb = new TextBox();
tb.Text = "Hi!";
_ctl = tb;
panel2.Controls.Add(_ctl);
_ctl.blabla(); TextBox derives from Control, therefore it is already a Control. Just use panel2.Controls.Add(tb). That's polymorphism.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
So you would say - this would be better:
--
private Control _ctl = null;
TextBox tb = new TextBox();
tb.Text = "Hi!";
_ctl = tb;
panel2.Controls.Add(tb);
//access via_ctl.blabla();
--
_ctl for better access (less instructions)
If this example would be "cleaner" what is in this case above the difference to ".Add(_ctl)"?
BTW: TextBox is just for this Example normaly I would add a UserControl *g*
- bb
|
|
|
|
|
Quit casting to Control. A TextBox derives from Control - all methods, properties, fields, and events (besides private members) are inheritted. A method that is declared on Control (like Text) is accessible on TextBox:
TextBox tb = new TextBox();
panel1.Controls.Add(tb);
tb.Text = "Hi";
tb.Refresh(); It's still an instance of a Control, just a derivative of it. This is simple object-oriented development. For example, every type in .NET derives from Object, so every type inherits a ToString method, a GetType method, and more. Some may override the behavior of that member or even hide it (at design-time only), but the member is always defined for derivative types.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Oh I see! 
Thx a lot for your good help!!
|
|
|
|
|
I'm working on an application that displays properties of an object in a PropertyGrid control. This object's properties don't have attributes (like BrowsableAttribute, CategoryAttribute, etc.). Since I want to control how and which properties are displayed in the PropertyGrid and in which categories and so on, I have made a "wrapper-class". It copies the required data from the original object and makes it accessible in custom properties which are not a one-to-one representation of the properties of the original object (instead they are split-up into more user friendly ones). The wrapper-object stores a reference to the original object as well. Some of these properties in my wrapper-class access objects which have properties themselves. With the use of the TypeConverterAttribute I am able to show and edit nested properties. When the user is done making changes in the PropertyGrid, I make the wrapper-object transfer its data to the original object.
It works, but I want to leave out this last step. I want the wrapper-object to update the data in the original object at the same time as when a property in the wrapper-class is changed. This causes a problem when the properties are nested, like mine are. When the properties of an object that is accessed by a property in the wrapper-class is changed, how will the wrapper-object know? I found an attribute that may do the trick: NotifyParentPropertyAttribute. This is a flag saying you want the parent property to be notified by a changed child property. However, I haven't a clue how (or if) the property should send this notification and how the parent should receive it.
So my question is: what should I do to be able to handle this notification. Has anyone come across this attribute before?
Thanks.
|
|
|
|
|
There's a couple more robust ways of doing this: implement ICustomTypeConverter on the "design-time unfriendly" object, or implement a designer. Both allow you to return a PropertyDescriptorCollection that contains PropertyDescriptors. A designer can also allow you to pre- and post-filter properties on an object. Through custom PropertyDescriptor implementations, you can configure the categories, descriptions, read-only'ness, etc. for a property, as well as call it anything you want (and implement GetValue and SetValue however you want).
I use this for a preference manager with a temporary PropertyGrid to edit the singleton data (through the internal static instance field that returns the singleton). I implement ICustomTypeDescriptor and - for the most part - just use the TypeDescriptor methods related to whatever method I'm implementing for the ICustomTypeDescriptor. For GetProperties, I use a custom PropertyDescriptor class that actually encapsulates rows in a database (via a DataSet that is filled/updated based on conditions) and displays them as properties on an object (with full support via the Type for TypeConverters, UITypeEditors, etc.).
This way, the user is actually changing the object without you having to shadow properties like you are now.
The NotifyParentPropertyAttribute simple causes the designer to use the information it has (such as what's returned for TypeConverter.GetCreateInstanceSupported) to re-create an object based on the new values in the property attributed with the NotifyParentPropertyAttribute. Very little else is documented about it, and since the implementation is primarily in the designer (i.e., the VS.NET IDE or #develop IDE, etc.) using the IL disassembler (or any disassembler/decompiler) won't be very helpful.
I recommend using ICustomTypeDescriptor or a designer.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks. I will look into it right away!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
