|
Alright folks
having a bit of a problem with a datagrid. i set up the datagrid as read only to start with then using tablestyles set some columns as readonly = false.
When i first insert a new row into the datagrid it actually shows 2 lines but only 1 line is active, which i want but i don't need the want the other line.
So all i want when i insert a line into the datagrid is the line i create. It seems to do it when all datagrid read only. Is their any functions or validate checks that stop this from happening
any help is appreciated
regards
mack100
|
|
|
|
|
Wrong thread dude.
This is a thread about the result of the survey.
You get more chance getting an answer on the proper thread.
If someone says "Die mortal!", don't stay to see if he isn't.
|
|
|
|
|
Well ... someone had to vote for it!
|
|
|
|
|
For job security shouldn't we just name all variables X? Or, just one letter names from a-z. In C# you could use both "X" and "x" in the same block. You would be hard to replace if nobody but you understood your code.
|
|
|
|
|
Good idea! Bur, the trouble would be when you'll spend better part of the day understanding your own code
Cheers,
Rohit Wason
|
|
|
|
|
thrakazog wrote: just one letter names from a-z
Believe it or not, one of the first versions of BASIC for personal computers (called 'Tiny BASIC') supported exactly 26 variables, named 'A' through 'Z'.
Software Zen: delete this;
|
|
|
|
|
One of the machine tool programming languages we use used to only allow variables called V - V1, V2, V3, V4... Made programming in Brainf--k look appealing!
|
|
|
|
|
you know, code obfuscating tool exist !! 
what if you (or one of your colleagues) have to maintain the code several months later ?
very bad convention sir. i strongly deprecate it
|
|
|
|
|
It also can you the wrong way, that your boss is guessing you arent a serious programmer
PS: Writing maintainble code belongs to the duties of a programmer.
Greeting from Germany
|
|
|
|
|
I just don't get these other replies. Future maintenance? What your boss thinks? Bahh!!!! Personally, I name all my variables and functions with 'l' and '1':
l, ll, l1, ll1, l1l, l11, llll, lll1, (and so on...)
I mean, take a look at the beauty of the following code:
<br />
for(ll1ll1l=l11llll; ll1ll1l=l111lll; ++ll1ll1l)<br />
{<br />
ll1ll1l1[ll1ll1l].ll1l1l();<br />
}<br />
|
|
|
|
|
Very handy dont you think? 
If I was your boss and you would make code like that, you would be fired the next day. This will cost a lot of money to maintain and if you wait to long to fix code like this, you will spend even more money to fix it...
WM.
What about weapons of mass-construction?
|
|
|
|
|
 I can't believe anyone actually believes I or thrakazog is serious.  (At least I hope thrakazog isn't serious or he will have a hard time keeping a job.)
Obviously such code will get you fired in a heartbeat (should someone review it that is).
Here's a more subtle approach which will probably eventually get you fired, just not right away: How to Write Unmaintainable Code[^]
|
|
|
|
|
Yeah, you're right. Sense of humor seems to be rare around here. Can't believe most didn't get the jokes.
|
|
|
|
|
that's why emoticons exist... to express one's feeling 
-- TTD --
|
|
|
|
|
I use a mixture of them for all my code.
Properties and methods use Pascal Casing...
Text
GetDisplayText
All internal variables use camel case...
customerCount
numberOfCalls
All private variables that pertain directly to the values accessible via a property or method are camel cased versions of the property...
text
getDisplayText
Any local variable that has module level scope (ie: vars global to a class) use are camel case with a leading 'm'...
mText
mNumberOfCalls
All GUI elements are camel cased with the prefix providing the control type...
txtUserName
chkSlection
cmbOptionDropdown
Constants are all upper case with an underscore separating the words...
THIS_IS_A_CONSTANT
My Blog[^]
FFRF[^]
-- modified at 11:15 Monday 3rd April, 2006
|
|
|
|
|
uncanny 
that is pretty much exactly how I do my variables
/jason
|
|
|
|
|
The question is about local variables only.
Ray Cassick wrote: Constants are all upper case with an underscore separating the words...
THIS_IS_A_CONSTANT
That looks too Java-ish to me
Regards
Thomas
Disclaimer:
Because of heavy processing requirements, we are currently using some of your unused brain capacity for backup processing. Please ignore any hallucinations, voices or unusual dreams you may experience. Please avoid concentration-intensive tasks until further notice. Thank you.
|
|
|
|
|
Thomas Freudenberg wrote: That looks too Java-ish to me
Id rather have that instead of what I have seen other people do.
I had to wade through code where all the constants where prefixed with just a C. I was going nuts at first thinking that they were classes instead of constants 
Ccustomertype
Cthis
Cthat
UGH!
My Blog[^]
FFRF[^]
|
|
|
|
|
An issue I'm having in this hippy-free-loving-no-Hungarian-notation world we live in is: how do you, syntactically, differentiate between locals and parameters? I'm talking .NET here, where parameters should be camelCased, fields Pascal cased, and class member variables prefixed with an underscore.
I used to use Hungarian for locals and camelCase for parameters, making it easy. But it was onconsistent since class members weren't getting the Hungarian treatment. I moved to PascalCase but then you've got that whole "is it a field or a local" thing.
Maybe I should just install Visual Assist X...
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Chris Maunder wrote:
Maybe I should just install Visual Assist X
Yeah, mine are purple, thanks to Resharper
Ryan
"Michael Moore and Mel Gibson are the same person, except for a few sit-ups. Moore thought his cheesy political blooper reel was going to tell people how to vote. Mel thought that his little gay SM movie about his imaginary friend was going to help him get to heaven."
- Penn Jillette
|
|
|
|
|
I find that unlike with class-level variables, I usually don't need to syntactically differentiate between locals and parameters. They're all scoped to the method anyway, and I try to decompose my methods enough that I don't have a huge number of variables to keep track of in the first place. In those rare instances where I really do need to know what kind of variable it is, I just refer to the method signature.
Any naming scheme is about finding the right balance between giving the human reader of code hints where they need them most, and not unnecessarily slowing down the writing of code. For me, starting class variables with an underscore, local variables without an underscore, using pascal case for methods and properties, and camel case for variables is just enough.
|
|
|
|
|
I agree.
Kevin
|
|
|
|
|
majahanson311 wrote: I find that unlike with class-level variables, I usually don't need to syntactically differentiate between locals and parameters.
True, that.
|
|
|
|
|
why would you like to differentiate the variables defined locally to a function, and the parameters that function receives ?
from a compiler view (i talk from a C/C++ point of view as i don't know other compilers well enough), parameters are local variables... you can use them just as you do with local variables, such as read them, modify them...
their existance is limited to the scope of the function.
|
|
|
|
|
I have used a veriaty number of naming convensions. Normaly I use the camelCase as I do not want to counfuse variable names with function names. I normaly use upper case for the first letter of a function name. If a need to destinguish a parameter from a local variable, for any reason, then I prefix it with "arg" or "par", but that is usually not required.
Lately I have been developing templates and have adopted the style used in the STL. The reason for doing that is so people who are use to looking at STL, will immediatly recognize it. The only difference is that I tend to use longer names inorder to make it clearer as to what is happening.
INTP
Every thing is relative...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
