In order to disable component designer in classes it is simple to add just [System.ComponentModel.DesignerCategory("")] attribute to it, however it does not work for any classes derived from this class in any generation. E.g:
[System.ComponentModel.DesignerCategory("")]
public class A:ServiceBase { } //Designer is disabled here
public class B:A {} //Designer is enabled here
[System.ComponentModel.DesignerCategory("")]
public class B:A {} //Designer is enabled here too
[System.ComponentModel.DesignerCategory("Code")]
public class B:A {} //Designer is enabled even here
This happens, of course, in any other generations and permutations. E.g.
//Whatever attribute here
public class C:B {} //Designer is enabled here
Does anybody ever tried to get rid of it? Why component model tries to add designer support even if it explicitely disabled in first generation?
Thank you
The reason for such behaviour is cached referenced assemblies. To solve it, remove reference to the assembly contained base server with attribute and add it again. In this case Visual Studio rebuild project and will not define default editor to derrived class.
"Attribute inheritance" at first struck me as odd, as I always thought that attributes weren't inherited; after checking learn.microsoft.com I discovered that that doesn't have to be the case - attributes may have Inherited = true, so thanks to you for helping me broaden my knowledge :-)
Additionally, I also had to remove a bunch of <SubType>Component</SubType> entries from the .csproj file
Related
I want to know if there is any way to limit usage of custom attribute to the specific class.
I read about it and somebody wrote that it's probably impossible in C#. But I have just tried to use AttributeUsage attribute on a class that doesn't derrive from Attribute and Visual Studio has thrown a following error:
Attribute 'AttributeUsage' is only valid on classes derived from System.Attribute
So now I think that there is a pretty smart way to make it. Have you any ideas?
The only way I can think of is by making the attribute class an inner class of the target. I have a hard time coming up with a legitimate reason to use this though.
This will compile:
[InnerAttribute]
public class A
{
private class InnerAttribute : Attribute
{
}
}
But adding this won't:
[InnerAttribute]
public class B
{
}
I have color scheme for my code editor in a settings file in the project. I have a several similar settings files each containing different color scheme.
To make those settings selectable on runtime, I need them to implement ColorScheme interface.
So far so good, code works fine, with only one major annoyance: each time settings are changed, the interface part is removed from Designer file, so the code doesn't find them anymore.
Is there a way to force code generator to add my interface to generated class? Or is it other workaround for this? I tried to make designer file readonly, but then I see lots of annoying VS dialogs.
Without the interface, I can't cast settings class on anything. I could probably read its properties via Reflection, but this approach looks like an ugly hack.
You could go for an "extension" using a partial class for your settings, that include the interface :) (It should be in the same namespace/assembly as your settings file is). Any changes to the settings do not interfere with your self created partial class
public interface IHaveInterface
{
void Hallo();
}
internal partial class Settings : IHaveInterface
{
public void Hallo()
{
Console.WriteLine("Hallo");
}
}
after which i can access the hallo inside the Properties.Settings.Default
Properties.Settings.Default.Hallo();
I used the OWLGrinder to create the assembly and imported the library into my project. That works fine. Now I want to write my own set of classes. Therefore I extended these with the equivalent of the assembly. But it just doesn't work.
The ontology holds a class named ManagementObject.
I created another Class (C#) called RealWorldObject:
public class RealWorldObject : ManagementObject
{
public RealWorldObject(string uri) : base(uri) { }
public RealWorldObject(string uri, RdfDocument rdfdocument) : base(uri, rdfdocument) { }
public RealWorldObject(RdfDocument rdfdocument) : base(rdfdocument) { }
public String getClassName()
{
return this.OwlClassName;
}
public static RdfDocument addRealWorldObjectIndividualt(RdfDocument rdfDocument)
{
Vehicle vehicle = new Vehicle("vehicle1", rdfDocument);
FixedEvent fxE1 = new FixedEvent("autoGekauft", rdfDocument);
fxE1.agent = new xmlns.com.foaf._01.Person("robert", rdfDocument);
vehicle.hasFixedEvent = fxE1;
return rdfDocument;
}
Which leads to the error:
ObjectManagement.Object.RealWorldObject does declare one (and only one) OwlClassAttribute. This is an implementation bug of the plugin.
How else should I extend the generated classes by the OWLGrinder.
Thx it is a long time ago that I used C#, so I'm kind of rusty.
The auto-generated classes produced by OwlGrinder.exe have not been designed for inheritance in mind. I am not saying it is wrong, it is just not designed for that. The auto-generated classes contain plenty of metadata defined as class attributes and inheritance hides all of that. The infrastructure counts on the presence of these attributes and if they are hidden, you get these runtime error messages.
Using Visual Studio Object Browser, take a look of the attributes over the auto-generated classes. OwlClassAttribute, SubClassOfAttribute, LightVersionAttribute are certainly mandatory. You may simply copy/paste the class attributes of ManagementObject on the top of your RealWorldObject class. I assume, it will work. But again, you might bump into additional show stoppers, as you do not follow the default routes ROWLEX has been designed for. This is a bit living on the edge :)
Instead of inheritance, you might consider reverse engineering your auto-generated assembly to C# using Reflector or other tools. Having the source code in your hand, you may modify the generated classes directly. You might make your ManagementObject class partial, and implement your additional methods in a separate file.
I am using Linq-To-SQL and I would like to attach an interface to each of my entities.
I can edit the designer.cs file and accomplish this.
However, when I make a changes to the dbml through the UI it rewrites the whole designer.cs and I lose my changes.
Am I just going to have to deal with it, or is there a way to get around it?
I am doing this in the designer.cs file(the IMatchable is a custom interface of mine):
public partial class Error : INotifyPropertyChanging, INotifyPropertyChanged, IMatchable
{
...
}
Don't edit the designer file; the beauty of partial classes is that you can create a separate file with just
public partial class Error : IMatchable
{ }
(assuming that we are using implicit interface implementaion by virtue of having properties that match the required interface)
Small word of caution though: if you are using VS2008 and you have MyClasses.dbml and MyClasses.designer.cs, do not call this file MyClasses.cs - there is a bug in VS2008 that makes this a nuisance (you have to keep moving the using directives inside the namespace, or the code-generator breaks) - fixed in VS2010 though.
Also, if it was a single interface, that every type in your model implemented, you can cheat by specifying that at the object base-type in the DBML. The designer doesn't show this option, but if you edit the DBML manually it works fine.
During a refactoring, I added a generic type parameter to MyControl, a class derived from UserControl. So my class is now MyControl<T>.
Now I get an error at runtime stating that the embedded resource file MyControl`1.resources cannot be found. A quick look with .NET Reflector shows that the resource file is actually called MyControl.resources, without the `1.
At the start of the MyControl<T>.InitializeComponent method there is this line which is probably the one causing problems:
System.ComponentModel.ComponentResourceManager resources =
new System.ComponentModel.ComponentResourceManager(
typeof(MyControl<>));
How do I force the ComponentResourceManager to use the embedded resource file MyControl.resources? Other ways to resolve this issue are also welcome.
Turns out you can override the resource filename to load by inheriting from ComponentResourceManager like this:
using System;
using System.ComponentModel;
internal class CustomComponentResourceManager : ComponentResourceManager
{
public CustomComponentResourceManager(Type type, string resourceName)
: base(type)
{
this.BaseNameField = resourceName;
}
}
Now I can make sure that the resource manager loads MyControl.resources like this:
System.ComponentModel.ComponentResourceManager resources =
new CustomComponentResourceManager(typeof(MyControl<>), "MyControl");
This seems to work.
edit: the above line is overwritten if you use the designer, because it is in the
generated code region. I avoid the designer and make use of version control tools to revert any unwanted changes, but the solution is not ideal.
In addition to Wim's technique, you can also declare a non-generic base control that has the same name as your generic class, and have your generic control/form derive from that non-generic base class.
This way you can trick both the designer and the compiler into using the resource file from your generic class, and you get permanent designer support once the base class is setup without having to fiddle in the .designer file everytime you rebuild :
// Empty stub class, must be in a different file (added as a new class, not UserControl
// or Form template)
public class MyControl : UserControl
{
}
// Generic class
public class MyControl<T> : MyControl
{
// ...
}
The only requirements are to have exactly the same name for your generic class and its base class, and that the base class must be in another class file, otherwise the designer complains about not finding one of the two classes.
PS. I tested this with forms, but it should work the same with controls.
On my Visual Studio 2008 I have this error:
System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(MyControl));
Using the generic type 'WindowsFormsApplication1.UserControl1' requires '1' type arguments.
Notice that in my case code was generated without parentheses, <>, after the class name.
It is becoming interesting, see ImageList autogenerates non-compiling code in a Generic User Control.
What they said:
Posted by Microsoft on 7/6/2005 at 2:49 PM
This is an interesting bug. You've hit upon a generic scneario that we do not support in the Windows Forms designer. We will not be able to add support for this in the Whidbey (my note: Visual Studio 2008?) release. We will consider this for a future version. As a workaround, you can use the designer to create a none generic UserControl with a public Type property and then create a generic class that inherits from it and passes T into the base classes Type property.
I suppose this control cannot be designed in the Visual Studio forms designer either.
The simplest and easiest workaround is to make a dummy class for the autogenerated typeof(). You do not need to inherit from it or even expose it to the outside:
// Non-generic name so that autogenerated resource loading code is happy
internal sealed class GridEditorForm
{
}
(In my experience, the time required getting the designer to work around generics was not worth the ideal coolness generics can provide. I won't be using generic windows forms or controls again.)