From within a class library, I'd like to know if it is being accessed during design mode as opposed to normal runtime.
I tried using System.ComponentModel.LicenseManager.UsageMode but it seemed to have a value of Runtime even when I was editing a form.
UPDATE:
To clarify, I want to know if I am in design mode not from within a component, but rather from within a separate class that happens to be called by other items from within a form or control. I have a Utility class which is being called indirectly from a control and it is there that I need to know if I am in design mode or not.
I don't think Component.DesignMode will help in this case. What if the component or control is not loaded on the forms designer ? What you may try in this case is, create an enum that only sets the one value at normal startup which otherwise remains to another value by default. You can now check the value of the enum instance and decide if it's a design-time or runtime.
You can use Component.DesignMode to check this. However, be aware that this will always report false inside the constructor of the component, so it needs to be checked later. For details, see Debugging Design-Time Controls.
Edit in response to comments and edit:
Unfortunately, the LicenseMananger, as well as most other services which provide information about whether you're in Design Time (including Component.DesignMode and DesignerProperties.IsInDesignMode) as specifically geared at handling user interface elements. This makes sense, as they're intended to tell you when your item is being "designed" on a designer surface, which requires the component to be registered in the designer.
There is no single property that will cleanly tell you this from within an arbitrary class.
I could see two options, both of which are less than ideal:
Pass the required information into your class (ie: a Component or DependencyObject), so the methods above can be used to check for design-time access correctly. This is probably a more maintainable approach, and will likely work properly in more situations.
Resort to the "hack" of checking the current process name and looking for "devenv" - this is pretty awful, as it assumes Visual Studio only, relies on the executable name, etc... In general, I'll mention it because you'll find it with enough searching, but wouldn't recommend it, as it's very easy to circumvent and has many limitations and flaws.
Is it not possible to use Component.DesignMode property?
Here's some info on applying attributes in order to get design-time specific behavior: http://msdn.microsoft.com/en-us/library/37899azc.aspx
Related
For context, using C# inside the Unity3D Editor.
I have more and more often started using enums to loosely couple things to settings.
For example i am setting up an item, and i want to give it a visual from a pool of defined visuals. That visual is basically a class that contains a sprite, a color, and a model attached to an integer unique ID. From this Unique ID, i generate an Enum. And it takes some effort to verify that the UniqueID is actually Unique, and catch some edge cases regarding that.
The benefit of doing the above, is that the enum is all that has to be stored on the item, to link it to the visual. At runtime there is a dictionary created to lookup the enum, and then request the stored visual to be loaded/used. This loosely couples the visuals to the item, so loading the item list does not automatically load all of the visual assets associated with the item. The last part is unity default behavior and is really annoying, and it really slows down the game and consumes a massive amount of RAM in this default behavior.
As a result we have a lot of those enums for various purposes and a lot of lookup stuff happening. And currently we are having no big problems with it.
However, the enums and the editing/generation of those enums is error prone in the sense that when values are removed, the items (and any other interested parties) are non the wiser, which then has to be either tested before build, or runs into a safety catch/error at runtime.
My question is. Is this a blatant abuse of Enums? And if so, what would be a better way of approaching this problem of loose coupling?
If it is not, what would be a better way to set up and manage these enums in a safe way? So alarm bells will go off if anything using the enum now has an invalid value, or the values meaning would change? Which i imagine is hardly possible, and requires code all over the place to "self check" on recompile?
Or does this just all boil down to team discipline to manage the values well, and know what the enums mean and represent? In which case, it would never be able to make this designer friendly unless i write a custom editor for each and every one of these.
Thanks for any insights you might be able to provide.
If I understand you correctly, you're trying to associate each item with one of multiple static visuals? If this is the case you can simply write each visual as a static readonly object inside the visuals class. In your "item" objects you can then make a field called e.g. "visual" and set this to reference the right visual.
I don't know what makes the visuals load, but if the constructor does, then I believe they will load when the visual class is first used at runtime.
Example:
I have an user control with 1 property (that one editable through Property Grid) called "Title".
There is a way to throw an compile-time exception if the property "Title" is empty? Or all design-time properties is optional?
There is no way at compile time to ensure a particular property is set. You can use the #error directive to cause a compile time error or #warning for a compile time warning if code is compiled but this is not what you want.
There are two ways of ensuring a particular property or method is set. The first is to require it in a constructor or check that it has been set in a subsequent method or property. This is a runtime check, not compile time and, as you say, you have certain restrictions in a UserControl.
The second way is to use a code analysis tool like FXCop. You could write a custom rule that identifies all instances of your UserControl and ensures the property has been set on all instances. It may also be possible with Roslyn or PostSharp but I am not familiar enough with those tools to say so.
The problem with code analysis tools like FXCop is there is a rather steep learning curve. Programming languages are complex and these tools need to expose the complexity. My recommendation is use a default value like "insert title here" or, in the unlikely even that there is no suitable default, throw an exception when the control is rendered with a descriptive message.
See Good way to ensure that a property on a UserControl gets set? for a similar case.
I wish to allow the user of my control to choose the licensing method for the control. The choice comes from an enumeration, so they must choose one of the methods I have laid out for them. This license needs to be chosen prior to the code executing at runtime. Therefore I wish for them to selected a value at design time. Furthermore I do not wish for this property to be writable at runtime, if that can be avoided. Is there a way to make a property only available at design time?
You can give a control design-time behavior by creating a separate designer class for the control. Since the control itself can only exist as an instance of your runtime, you can't really have a property directly on it which is set only at design-time (where would it get stored?). However, designer classes are only invoked and used by the designer, so you can encapsulate non-runtime behavior there.
When adding a control to my form, currently I have to wire it up with my save and load code, with my internal data structures and I have to do this with all my controls. This scenario severely violates the DRY (don't repeat yourself) principle and can introduce subtle bugs.
I have came up with the idea of traversing all the Controls in a foreach loop, the Name property will be the key and the Text (or whatever depending on the type) will be the value in a dictionary (filtering for user input controls during the procedure). This way I will have to serialize/deserialize the dictionary to save/load it.
So, why am I asking? I am a beginner and I think there are more proven and tested methods for accomplishing the same task then what I came up with.
And sorry for my clunky English, I have not had the fortune to learn it as my first language.
Thanks for your help
note: I know about WPF, but I have to stick to .net 2.0
There are already good examples for doing that, see RealPosition. We modified this source to do form/control position saving in our project by just placing a component on the form in the designer and specifying the necessary properties there. Look at the IExtenderProvider and ISupportInitialize interfaces on MSDN too.
Ideally you want all the controls to inherit from a base class, the base class can then deal with all of this when each control is initialised. If you need the dictionary then pass the dictionary into a method, the method can then set all the various properties required on the control.
If each control inherits, then the logic is shared and DRY :)
I'm still new with C#, and I'm working on a project where we also use WPF, and the WPF DataGrid Toolkit (See at CodePlex), which hasn't yet been released into the framework. Due to the nature of the project, it's 100% sure we will be altering some controls of the assembly later.
My co-workers have decided to redefine every control from the datagrid within a namespace of our project, and ihnerit the specific control of the assembly namespace.
So instead of using:
clr-namespace:Microsoft.Windows.Controls.Primitives;assembly=WPFToolkit
clr-namespace:Microsoft.Windows.Controls;assembly=WPFToolkit
We'll be using our own xxx.Controls and xxx.Controls.Primitives Namespaces.
This way, it would be pretty easy to alter the ihnerited controls.
Somehow, I got a bad feeling about this solution, but I'm still inexperienced and cannot tell if such an approach is legitimate or not, or if there is another good solution to our requirements (altering the controls later without changing too much code in multiple files).
It would be nice if you express your opinion to this approach.
What kind of alterations are you talking about? It seems like a waste of time to pre-emptively derive from each of the classes before you know what you'll actually need to change.
When you do need to change something, it shouldn't be too hard to create the derived class at that point, and fix up any references - which may only be for some instances rather than all of them. Yes, it may mean check-ins involving quite a few files - but if you're using a sensible source control system it will be an atomic change, and it will be obvious why it's changing.
With your current approach, there's no immediate "these are the controls we've had to change" - if you do it in a "just-in-time" manner, you'll be able to tell just by looking at what derived controls you've actually had to create.
I agree with you. The alterations, or better said, the changes, can be of any kind. Behavior and etc. And the changes should be make just in time.
Unfortunately, that is not my decision. Some stubborns are at work :)
But what is interesting me is if a complete different approach to the whole idea exists?
Say, I've got a DataGrid, the project evolves, and now, I've got to do some drastic changes in the validation behavior of dataGrid rows.
This could also apply to a lot of controls.
The problem with our project is, we have a kind of complex data access layer, which not only provides data, but also actually controls it. This means data isn't read,modified, deleted or appended without including some logic provided by the data access layer.
For an example, the datagrid doesn't directly delete rows, but instead, we overwrite the delete behaviour and aks the data access layer to delete it. With binding, this works pretty good for now.
This kind of scenario will apply to a lot of other things in the future, regarding CRUD operations, validation and etc.