This question already has answers here:
textBoxEmployeeName vs employeeNameTextBox
(16 answers)
Closed 9 years ago.
Microsoft has naming guidelines on their website (here). Also I have the Framework Design Guidelines book.
What I could not find was a guideline about naming controls.
For example, a button, when dropped to a form, gets the typename + number, camel-cased as default name, such as "button1".
This is what I do: I delete the number and add a meaningful description after. For example "buttonDelete" or "buttonSave".
This way you do not have to maintain a big list of controls and their abbreviated names in a guideline somewhere.
Do you agree?
Here are some common ones:
frm Form
mnu Form menu
cmd Command button
chk Check button
opt Radio button
lbl Text label
txt Text edit box
pb Picture box
pic Picture
lst List box
cbo Combo box
tmr Timer
A longer list is at INFO: Object Hungarian Notation Naming Conventions for VB.
Caveat: The following is more directed at WinForm/WPF development. Patrick Peters rightly pointed out that there are bandwidth/performance issues at play when dealing with ASP.NET controls.
There isn't really a standard here, and I believe that this is because its one of the most arbitrary naming scenarios. In most cases, controls are private to the class, and only used lightly in event handlers.
Like other answerers, I too used to spend a non-trivial amount of time "fixing" control names. I would do things like "btnSave", "tbxName" (tbx for TextBox), etc. However, when explaining my scheme to someone else, I realized how arbitrary that was. Is "cbx" a ComboBox or a Checkbox?
This led me to re-examine what the designer does automatically and realize that I can clearly, consistently, and quickly name controls if I let the designer do the work. Its actually very similar to the suggestion of the question poster:
I replace the control number with the semantics of the control. Thus "button1" (the designer default) will be "buttonSave", and "listBox3" will become "listBoxWidgets". If there will only be one control of that type, I just remove the number: "errorProvider1" becomes "errorProvider".
So how is this better?
Meticulously "fixing" variable names is a waste of time if its an internal variable
Your naming scheme is likely to be ambiguous if it shortens a whole bunch of stuff (CheckBox versus ComboBox)
The designer gives a good, consistent starting point that is easy (and quick) to specialize
The length of the variable name is irrelevant when you use Intellisense
Control names group nicely and intuitively (in Intellisense) when prefaced by their type. When you have 15 TextBoxes on your Form, you just first remember you want a TextBox , type "textBox", and then pick the name from the list.
Anyone unfamiliar with your "scheme" can see it immediately and adopt it quicker than anything else.
It is VERY fast to provide useful control names...very little keyboard/mouse jockeying to do this...so high productivity with intuitive results. What is not to like?
PS. This is tending towards a Bikeshed question, but as I can paint a bikeshed, I went ahead and joined the discussion. ;)
I don't have a convention as such, but I do try to be very broad with the 'type' portion of the name. e.g. Button, Link Button, Image Button tend to be named 'somethingButton'. Combo boxes, radio button lists all end up as 'somethingSelector'. TextBoxes and Calendars are 'somethingInput'. That way I get a rough idea of what sort of control it is without the name being tied to the actual implementation. If I decide to replace an option button group with a dropdown then no need to rename!
I don't do WinForms for quite some time but what I did was two things.
uncheck 'generate member' (or however it is called) for things like labels, etc. Basically ensuring I keep as fields only things I need.
for those I need, set descriptive name. It if is necessary, append the name of the control (ie saveButton). If I don't feel like adding a control name adds any value I would not append the 'Button' and leave the name simply as 'save'.
Basically most of the time I would not create a member for save button at all. (If you have some save logic you still can have only OnSaving event handler subscribed to the button's Click event).
https://msdn.microsoft.com/en-us/library/ms233630(v=vs.110).aspx
Yes change those names
For me:
Button btnDescription
TextBox txtDescription
ComboBox cboDescription
etc...
GUI programming gets the short stick when it comes to conventions of all sorts. See my answer to another question for the guidelines I use for naming.
Yes, you need meaningful identifiers for any variable - control or not - the default names are only because your IDE knows nothing about your problem domain and so can't always 'guess' a better name.
I'm probably one of the last few people that still uses Hungarian notation. I know that argument that the IDE can tell you the variable type, but that doesn't help me when I'm coding in Notepad++ or looking at a printout.... anyway, I use the "btnSave", "cbOptions", "txtFirstName", "lblTitle", "ddlCardType", etc... I just like being able to glance at code and know what I'm looking at without looking for a declaration or hovering over a variable to get it's data type from the IDE.
I believe that current thinking frowns upon including the control type in the name. I'd be inclined to treat them as another other object I'm using and follow the same naming convention.
Certainly use meaningful naming, that goes without saying :) However, at the end of the day, if your naming convention still makes sense to you when you revisit your code months later then I'd probably stick with it.
Yes, I agree totally (but I rename it to ButtonDelete), so lowercase names are for variables in my case :)
Personally, I think as long as you are consistent, you won't run into problems even if someone else is reading your code.
I'm not sure, but I think that control naming in Windows Forms is one of the only places I can see a use for Hungarian notation. So I think you're good.
This is what we are using
In short, we prefix the controls with an abbreviation of the control. ie
Buttons = btnDelete, btnSubmit, btnReturn
Textboxes = txtUsername, txtPassword etc
that way, by typing the abbreviation you get all the similar controls by the time you finish typing the abbreviation ie type btn and intellisense will list all the buttons you have added so far.
Related
I'm just starting with Universal Windows Platform and actually C# as well (I've got a C background) and just trying to get my feet wet with a basic accounting app meant to keep track of a checkbook. The way it works is simple, the user either presses + or - buttons and specifies the name of the transaction and the amount either credited or debited, hits ok and that transaction is inserted as a row.
So it would look something like this
Gas ($20) 1/5/17 _delete_button_
Paycheck $2400 1/3/17 _delete_button_
Total $2380
....
So each row has 2 editable text boxes (name and amount), one textfield for date, and one button to delete that row.
Now my first instinct as a C programmer is just to create a struct with those variables and every time user inserts a row just populate the struct and push it on a stack. However I just want to make sure that this is the best way to do this and I'm not missing some feature of XAML that would let me do this.
"Now my first instinct as a C programmer is just to create a struct
with those variables and every time user inserts a row just populate
the struct and push it on a stack. However I just want to make sure
that this is the best way to do this and I'm not missing some feature
of XAML that would let me do this."
This question is dangerously close to not meeting the requirements for a good question because it is too broad, but I will answer anyway due to remembering the pain I went through with XAML when new. Whether new or experienced (and I am at most in the "intermediate" category), it seems XAML has its bits that will always send you looking for help. But I digress.
The standard is to create your model, then somehow connect (or "bind") the appropriate parts of the model to your view.
You would use C# (actually can use VB or F# or others also) for your model. This is where you would create your "struct" you are referring to. This would define your individual transaction. Then, create a collection of these transactions, again in your model.
In XAML, you bind to this collection. You have a control (a visual element in your view) that displays all transactions. You have a control for specifying the name of a specific transaction, for selecting a transaction, for inserting, for deleting, etc. All of these controls interact with the model through the bindings.
So, to answer your question, yes you are missing a feature of XAML. It is called binding. Not to be sarcastic but unfortunately, binding is a technology worthy of months of study. Sorry, but you will want to go back to C with no UI at first. Keep at it! If you want to do the universal app thing, it is worth it. You may even find yourself liking (parts of) it.
Link to get thou started:
WPF and other XAML-related
How do I display Price value($) in textbox next to a label when user checks the radio button, select one of item from listBox, and then clicks the button?
Is there way to do it on the form1.cs[Design] using the properties? Or do I need to set them up in code level?
listBox item example
EDIT: Solved this in Code-level.
I don't think you can do it without any code.
Also I'd recommend you to check out this page - just a few simple rules can make your chances to get a good answer on this site much better.
And there is not much of coding needed to solve your problem. Take a look on the Events tab in Property view in form designer. A few event handlers to process user input and some fields inside your class to store the data - I assume it is not some serious business app you're dealing with, so all the code you need for this to work would be like 20 lines tops -)
I'm just getting started in C# and hope you can help me choose the best way to pass values. I'm doing an exercise building a calculator in Visual Studio. I need to pass/get values once buttons are clicked.
I can see that a (sloppy?) way to do this would be to create code for each button's click event. Doing that, I would be certain which button is pressed... then could call a method and pass it a hard-coded argument indicating the button's value. For example, "BtnEntry_Click(1)" when the one button is pressed.
Another way would be to grab the sender's name, then have a switch statement that checks the button's name and assigns the value. For example:
private void BtnEntry_Click(object sender, RoutedEventArgs e)
{
var buttonClicked = sender as Button;
switch (buttonClicked.Name)
{
case "btnOne":
// The one button was pressed, so pass 1
break;
case "btnTwo":
//The two button was pressed, so pass 2
break;
//etc .....
}
}
A third option would be to put the value into the button's tag property, then grab it from there.
Is there another option using the RoutedEventArgs? If so, can you offer example code?
Is there a best way from among the options above... or is there a better way to do this?
Thanks!
Note: An editor noted that this question is related to the one posted at this question. I feel this is a broader view, addressing more potential solutions, and also easier for "noobs" like me to understand. The other question has stuff about binding code, which makes it an unhelpful answer for me.
I did, however, come across this answer regarding commands, which expands on the idea offered by Drew Noakes and kidshaw. (Thanks!)
So, I would suggest keeping this as a separate question, since it offers an easier entry point than the other and also addresses more options.
Of the options you offer, the tag would be my preference. But since this is wpf, you can implement an mvvm solution where you have a command and supply a parameter to a viewmodel.
Typically mvvm has overhead that might deter its use in small apps, such as a calculator. But since you're a newbie and looking for options - it's worth doing small to learn it.
I'm not a fan of the Tag property because it is not typed. You might consider having a class inherit from Button, and have that class implement a property that exposes its underlying numeric value.
I have two doubts about the autocomplete feature of textboxes in C#.
First, I want to display the full list, not only the ones that start with the given text, and secondly I want to prevent the auto-complete of specific options (some are category titles).
I've been checking the textbox properties and there's nothing related to it, so probably the main question could be, Is there a way to modify / override the textbox events in order to handle the auto-complete actions? (I don't know if it applies to show the full list too)
I assume you're asking about a winforms textbox, as I dont think the WPF textbox supports autocomplete at all.
The base TextBox class will not support doing what you want, so you could in theory attempt to override all of the functionality in the TextBox class to do what you want, but the better idea would be to create a new custom control that inherits from TextBoxBase and implement the autocomplete behavior the way you want it.
I'm not sure about displaying the full list (perhaps a combobox or similar is more suited to this?) but you can definitely do something like this to swap which list of possible items can be displayed.
Another option, though one I like less, is to remove items you don't want to display at a given time from the collection dynamically, like this: textBox.AutoCompleteCustomSource.Remove("ACategoryTitle")
I could foresee that approach having many problems with trying to rebuild the list constantly. I would probably create a subclass of AutoCompleteStringCollection that wraps some LINQ code to nicely select the union of some lists and not others to display in the textbox.
I decided to build my own autocomplete tool with the help of a simple listbox and events, then I could achieve what I was expecting..
The CodingGorilla's answer probably leads to a better solution if you want something more decent, in my case for speed reasons I decided to do it that way but I'll mark his answer as the accepted in order to help other people who have the same doubt and they could consider that point..
I would like to design one xml text editor which is based on normal text-box which implements all XML characteristics(i.e., it should implement intelligence to differentiate the text colors by node_name,attribute_name,attribute_value and it should check proper closing the tag).
Can any one give me the idea how I could process the each and every character entered by the user(normally we can call the TextBox1_TextChanged event after fully entered the text in text-box but I need to call this event each and every character entry)? I am good in C#, so that I have decided to transform the control to coding page because I already did one editor using console application which read the input character from the user and change the text color.
I might be wrong to approach this problem like this way so, give your suggestions, valuable reference links and ideas to accomplish this editor.
If you know any plugins to do this task please inform me
Thanks in Advance.
Regards,
--SJ
Use a Rich Text Box and handle the KeyDown event for character processing.
Rich Text Box will allow you to do syntax highlighting, text formatting, etc.
I would also validate entered xml for correctness and possibly highlight incorrect syntax to the user if validation fails.
All this is going to required effort, i am not aware of any QUICK solution. But using the basics i've suggested here, you could achieve what you require if you put in the effort.
The EditArea appears to have the features (and more) that you are looking for.
You could also check the list of Javascript base source code editors