For a C# UserControl on Windows Mobile (though please answer if you know it for full Windows...it might work) how do you change what shows up in the Designer Properties window for one of the Control's public Properties. For example:
private Color blah = Color.Black;
public Color Blah
{
get { return this.blah; }
set { this.blah = value; }
}
This shows up for the control, but it's in the "Misc" category and has no description or default value. I've tried using the settings in System.ComponentModel like "DesignerCategory", such as:
[DesignerCategory("Custom")]
But says this is only valid for class declarations... could've sworn it was the System.ComponentModel items I used before...
Update:
#John said:
DesignerCatogy is used to say if the
class is a form, component etc.
Try this:
[Category("Custom")]
Is there a particular namespace I need to use in order to get those?
I've tried those exactly and the compiler doesn't recognize them.
In .NETCF all I seem to have available from System.ComponentModel is:
DataObject,
DataObjectMethod,
DefaultValue,
DesignerCategory,
DesignTimeVisible,
EditorBrowsable
The only one it doesn't scream at is EditorBrowsable
DesignerCategory is used to say if the class is a form, component etc.
For full windows the attribute you want is:
[System.ComponentModel.Category("Custom")]
and for the description you can use [System.ComponentModel.Description("This is the description")]
To use both together:
[System.ComponentModel.Category("Custom"),System.ComponentModel.Description("This is the description")]
However this is part of system.dll which may be different for windows mobile.
Is this of use to you? I am not into CF development, but it looks like you need to add some XML metadata to enable it:
http://blogs.msdn.com/bluecollar/archive/2007/02/08/adding-compact-framework-design-time-attributes-or-more-fun-with-textboxes.aspx
Interesting read.. Looks like a lot of design time support was stripped out of CF because you dont design them on the devices.. Which seems kinda weird to me.. Cant imagine using a handheld as a development rig!
Scroll down about half way for the good stuff ;)
The article does not suggest that anyone is designing ON the device. However, when you create a Compact Framework project, the compact framework (for your desktop PC) is used to handle design time rendering. If you think about it that is what you expect. The same framework (or nearly so) is used to do the rendering both on your PC at design time and later on the device at runtime. The issue is that the design time attributes were not added to the compact framework (I assume to reduce the size).
Related
I've started creating a Windows Store App for Windows 8.1 and now I encountered a problem concerning localization.
I would like to display a string resource from a .resw file at design time, but every attempt to do so has failed, even though it works at runtime.
When using the x:Uid attribute, I still have to supply the Text property (i.e. for a TextBlock) and I don't like to write the text twice.
I also tried creating a property for the string on the viewmodel:
public string Title
{
get { return ResourceLoader.GetForCurrentView("Strings").GetString("MainView_Title"); }
}
This is working at runtime, but at design time it is blank.
So the question is, is there a way to display resources from a .resw file in the XAML-designer?
More specifically, does the ResourceManager class allow .resw files to be read at design time?
Thanks for your help,
Lucas
Old Method
So, there are a couple of things you can do.
The first (and simplest, given that you're using x:Uid already) is to just supply the text into the Text field. The x:Uid-related value will overwrite whatever is in there.
<TextBlock Text="MyText" x:Uid="MainView_Title"/>
The second method is to use the property like you already have, and then check to see if the app is in Design Time (through a couple of different methods), then return a constant value if it is and the Resource if it is not.
public string Title
{
if(ViewModelBase.IsInDesignTimeStatic) //Mvvm Light's easy accessor
return "My Text";
return ResourceLoader.GetForCurrentView("Strings").GetString("MainView_Title");
}
Hope this helps and happy coding!
Edit: There appears to be a new way to do this, at least as of Windows 8.1.
New Method
Create a class which references a ResourceLoader (similar to the property described above).
Create an indexed property accessor which accepts a string key and return the value from the ResourceLoader.
public class LocalizedStrings
{
public string this[string key]
{
get
{
return App.ResourceLoader.GetForViewIndependentUse().GetString(key);
}
}
}
In your App.xaml, define a StaticResource of this type.
<Application.Resources>
<ResourceDictionary>
<common:LocalizedStrings x:Key="Localized"/>
</ResourceDictionary>
</Application.Resources>
Now, when you want to access your property with entry key MainView_Title, use this. It's more verbose, but it should translate both in the designer and in the app itself.
<TextBlock Text="{Binding Source={StaticResource Localized}, Path=[MainView_Title]}" />
You can shuffle it around to be a bit more readable if you'd like, such as:
<TextBlock Text="{Binding [MainView_Title], Source={StaticResource Localized}}" />
This is an old thread, but since Nate provided such an elegant solution to the problem for Win8.1 I figured I'd ask here...
After much investigation and experimentation, Nate's solution does not appear to work for UWP apps for Win10 under VS2017 Community. The LocalizedString approach works just fine at runtime, but it appears
App.ResourceLoader.GetForViewIndependentUse().GetString(key);
refuses to return anything except String.Empty during design time. I've done a lot of experimenting and things like
ResourceContext.GetForViewIndependentUse().QualifierValues
Seem to be identical between runtime (working) and design time (not working).
I was wondering if anyone has encountered this and solved it. Nate? :)
Does anyone have any guidelines/best practices for naming conventions for Forms and controls (e.g., events, buttons)?
I usually use Systems Hungarian notation
Example:
btnSubmit: is button
lblAccountNum : variable is a label
In WinForms I usually use suffixes, so for example:
submitButton
accountNumberLabel
etc.
But a lot of companies still use a prefix, like anthares said.
I don't believe any special rules are needed for forms development; the Microsoft .NET naming guidelines cover it.
I name forms like any other class in the application: MainForm, SaveDialog, etc.
I name controls like any other field within a class: okButton, nameTextBox, etc.
I usually prefix the full class name e.g. textBoxName. I find it easier to read than three letter prefixes and it's consistent with the names that are generated by the IDE. I only name controls that are referred to by code. Controls that are databound usually don't need a name.
The following example is most of the .net programmer is used
Control: Label
Prefix : lbl
Example: lblFirstName
The reason that the prefixes are not the full class names in most of the companies but some abbreviations of the class name are as follows:
Most of the naming conventions are approved before Visual Studio 2010.
All Visual Studio versions before 2010 have their inteli sense filter with something like "starts with" instead of contains.
That's why a lot of people / architects / leaders decided it will be a better idea to type "txt" and inteli sense will filter all textboxes for you, so then you just type "E" for example and you get txtEmail. If you have the full class name, you will need to type "textBoxE" to get the same result in inteli sense. This adds a lot of overheat when you have complex UI.
Now with Visual Studio 2010 you get a better inteli sense so you can just type "em" and you can easilly see the "textBoxEmail" in the list (along with Email and some other things that contain "em"). Still I seem to prefer to have 2-3 or up ot 4 letters abbreviation that will allow me to filter in inteli sense by control type (specially for UI) than having to type textBox. The reason I prefer it is that even if you are puzzled for a while with some control type (e.g. "rg" for RadGrid) you will need 5 minutes 3-4 times to remember it and start typing without thinking about it. While if you have radGrid everywhere you will need to hit 7 strokes to get to the meaningful one that will filter for you (e.g. "radGridC" in "radGridCustomers").
I do agree that only naming controls that are referenced in the code is usually enough.
Basically what I'm hoping for is something that would work like how the Obsolete attribute works with Intellisense and strikes the method text when typing out the name. What I'm looking for is an attribute that blocks the method from being seen with the assembly it's defined. Kind of like an reverse internal. Using 3.5 by the by.
Yeah sounds odd but if you need the reason why, here it is:
My current solution for lazy loading in entity framework involves having the generated many to one or one to one properties be internal and have a facade? property that is public and basically loads the internal property's value:
public ChatRoom ParentRoom
{
get
{
if(!ParentRoomInnerReference.IsLoaded)
{
ParentRoomInnerReference.Load();
}
return ParentRoomInner;
}
set
{
ParentRoomInner = value;
}
}
Problem with this is if someone tries to use the ParentRoom property in a query:
context.ChatItem.Where(item => item.ParentRoom.Id = someId)
This will blow up since it doesn't know what to do with the facade property when evaluating the expression. This isn't a huge problem since the ParentRoomInner property can be used and queries are only in the entity assembly. (IE no selects and such in the UI assembly) The only situation comes in the entity assembly since it can see both properties and it's possible that someone might forget and use the above query and blow up at runtime.
So it would be nice if there were an attribute or some way to stop the entity assembly from seeing (ie blocked by intellisense) the outward facing properties.
Basically inside the assembly see ParentRoomInner. Outside the assembly see ParentRoom. Going to guess this isn't possible but worth a try.
I do see that there is an attribute
for stopping methods from being
viewable
(System.ComponentModel.EditorBrowsable)
but it's choices are rather slim and
don't really help.
You can use the EditorBrowsableAttribute for this:
[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
public void MyMethod() {}
One thing to know, though: In c#, you will still get intellisense on the method if it is in the same assembly as the one you are working in. Someone referencing your assembly (or your project, for a project reference) will not see it though. You can also pass EditorBrowsableState.Advanced, and then you will only get intellisense if c# if you clear the HideAdvancedMembers option in Tools Options.
I haven't heard of a good way to do this in plain .NET. But, here are some ideas. Maybe one of them will work, or set you off in a direction that will be helpful.
Use FxCop, probably writing your own rule to make sure ParentRoom isn't called from the asslembly that defined it.
Look into the various post-processing projects for .NET (link design-by-contract).
Write some code inside your ParentRoom getter which will check the stack (using "new Stack()" or "new StackFrame(1)" to figure out whether the caller was from the same assembly. If so, either throw an exception or simply return ParentRoomInner.
My typical application has a couple of textboxes, checkbuttons, radiobuttons, and so. I always want to load the settings the user used the last time when the program starts, and also want to save the settings as the users clicks "Save settings" or closes the application. When the user attempts to save the settings, I'll have to check each of the controls for input errors (sometimes they have to have a max length, other times only caps, other times other things, there isn't a rule for them all, everytime it'll be different), and only if everything's OK i'll let him save the options. If there is something wrong, no option is saved and my errorcontrol provider will pop up a description of the input type info that should be put in that control.
I've been designing this from scratch for all my projects, but it's being a pain to do it. So I'd thought maybe now was the time to do some library to help me. I thought initially that maybe it'd be a good idea to have all the controls on my form that are going to be part of this save/load process to have an attribute associated with them, something like this
public delegate bool InputIsOkHandler();
public class OptionsAttribute : Attribute {
public Control controlRef;
public InputIsOkHandler IsInputOk;
public string errorMessageToShowOnErrorProvider;
public OptionsAttribute(Control controlRef, InputIsOkHandler inputHandler, string errMessage) {
...
}
}
The main problem here is that when I declare the attribute on a given var:
[Options(...)]
TextBox textBox1 = new TextBox();
I'll get
Error 1 An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type.
So I guess this approach isn't the best one. What would you guys do in this situation? Would you use attributes? Would you use other mechanisms?
Thanks
Do you know that .NET already includes such a system since 2.0? See MSDN, CodeProject and this white paper from WestWind.
The Personalization and User Profiles supported in ASP.NET 2.0 can be a nice way to achieve your goal.
You can check this MSDN article for a overview Personalization in ASP.NET 2.0
I need to bind labels or items in a toolstrip to variables in Design Mode.
I don't use the buit-in resources not the settings, so the section Data is not useful. I am taking the values out from an XML that I map to a class.
I know there are many programs like:
http://www.jollans.com/tiki/tiki-index.php?page=MultilangVsNetQuickTourForms
but they work with compiled resx. I want to use not compiled XML.
I know that programatically i can do it, i create a method (for example, UpdateUI()), and there I assign the new values like this:
this.tsBtn.Text=Class.Texts.tsBtnText;
I would like something i could do from Design Mode or a more optimized way than the current one. Is there any Custom Control out there or Extension?
Aleksandar's response is one way to accomplish this, but in the long run it's going to be very time consuming and won't really provide much benefit. The bigger question that should be asked is why do you not want to use the tools and features built-in to .NET and Visual Studio or at least use a commercial third-party tool? It sounds like you are spending (have spent?) a lot of time to solve a problem that has already been solved.
Try with inheriting basic win controls and override OnPaint method. Example bellow is a button that has his text set on paint depending on value contained in his Tag property (let suppose that you will use Tag property to set the key that will be used to read matching resource). Then you can find some way to read all cache resource strings from xml files (e.g. fictional MyGlobalResources class.
public class LocalizedButton : Button
{
protected override void OnPaint(PaintEventArgs pevent)
{
base.OnPaint(pevent);
this.Text = MyGlobalResources.GetItem(this.Tag.ToString());
}
}
You can use satellite assemblies for localization and generate them using your XML file as a source for the translated entities.
more about satellites http://msdn.microsoft.com/en-us/library/21a15yht(VS.71).aspx
sure it's not from design mode, but there's no way to do it this way with your restrictions.