I do the same for ASP.NET controls. As with every convention, it's up to you which one you chose. It's important to have a convention and to follow it.
I think it is very helpful to have such a convention for UI controls. Otherwise you will have to find some other way to differentiate related controls (e.g. a textbox with it's associated label: lblUsername and txtUsername).
This type of naming is referred to as Hungarian Notation. Whether or not to use this is a bit of a religious war and there are many arguments pro and con avaliable by searching around in google.
My opinion FWIW.
The fact that you felt it necessary to annotate your variable names in that box only goes to highlight how little information these abbreviations actually give you. If the button is a load button, call it load. I don't want to have to remember what dodgy abbreviation for button it's prefixed with.
That convention is called Systems Hungarian, and generally considered bad by many, including me. However, if it helps you, then feel free to use it.
It's a style thing. You'll find developers that abhor the practice and others that embrace it. In the end, if it helps you code, then use it. Just be aware that your type abbreviations may not make sense to those that come behind you. In my Visual Basic lifetime, I used 'txt' for a textbox prefix, so 'tb' wouldn't immidiately make sense to me.
At the end of the day it is a matter of preference and consistency. If you prefer to use this kind of notation then by all means use it, just be consistent and make sure to document your standard for other developers that are going to use or edit your code base are aware of the standard that you are following. Note that if you already have a standard in place then follow that, because nothing is worse than having code using multiple conventions unless you are going to change the current code to match the new convention.
Not just OK, but preferable in my universe. Otherwise, what sort of names would developers end up giving to controls? Which would you rather see as an incoming developer on an existing project: chkMatchCase or MatchCaseCheckBox? Or should it just be named MatchCase?
Intellisense is great, but it's always alphabetized (I think), so the prefix convention helps you groups controls by type (a not useless advantage).
As pointed before, the Hungarian Notation has the advantage to group controls based on their type :
txtTitle
txtName
txtSurname
chkIsAdmin
chkDelete
I prefer to use a name based on the purpose of the control, with the control type full name at the end :
titleTextbox
nameTextbox
surnameTextbox
isAdminCheckbox
deleteCheckbox
I find this method easier to use with recent framework controls, as you can include the full name of the control, and don't have to invent a new abbreviation for each specific control. When working with third-party GUI library, finding a new prefix can sometimes be hard and/or confusing for the next developper.
Use the convention you feel the most comfortable with, but be consistent on your whole project.
For me, it's only acceptable when dealing with GUI designer generated controls. When you have 20 different controls in one form, it's very easy to find the correct one w/ intellisense by using a 3 letter acronynm for it's type.
It's completely a personal preference (or a business' preference - in the form of a 'standard').
I now go by the rule of using a good name and the control type as a suffix. A 'good' name, will usually matche the control's paired label (if it has one) or else the domain model field it's bound to.
Plus the problem with prefixes is that at some point you're bound to run out of abbreviations to use as prefixes that are naturally discoverable by other developers. E.g. what about for a User Control? Or perhaps a subset of user controls that do the same thing (e.g. search related) do you use "usr" or "sch" or "sea" or god forbid the useless "ctl".