|
thnks for this answer i appreciate it
|
|
|
|
|
Classes only have the constructors you create - if you don't create any at all then a parameterless constructor is created for you.
Structs, being value types, are different and always have a default parameterless constructor with all the fields initialized to their default values (normally zero, or null if the field is a reference type).
|
|
|
|
|
Because the language specification says so.
17.10.4 Default constructors
If a class contains no instance constructor declarations, a default instance constructor is automatically
provided. That default constructor simply invokes the parameterless constructor of the direct base class.
Really it should be have said "if and only if", because that's what they mean. If you don't define a ctor, the default one exists. If you do define a ctor, the default one goes away. You can get it back if you want, because it's trivial:
public TypeName() { } (it would be protected for abstract classes)
|
|
|
|
|
Would like to ask what are the possible causes for columns of cells in a datagridview not to show values being pushed into it?
I have a datagridview with about 40+ columns and for some strange reason a number of columns are able to accept values I am pushing into them using:
datagridview.rows[rowindexhere].cells[columnindexhere].value = valueToPushHere;
whereas a number of others wont accept it? This is really weird and not sure if there a  re some undocumented things or limitations about Datagridview control that new users like me need to be aware of to ensure successful push of info into the control 100% of the time?
Thanks so much for all the help you could give ... I really appreciate it.
Matt
|
|
|
|
|
While banging my head trying to find an answer :^) ... below is what I did to test it further and gain more insight .. I changed the values as described below with result also indicated:
Change 1: I changed all the values pushed to the 48 columns to be the string "Writing here"
Result : About six columns responded and reflected the change
Change 2: I then proceeded to change the value from "Writing here" to the number 68
Result : 30+ columns have responded and reflected the new value 68
This is good and indicates that the type of data pushed have an influence on whether the value actually gets to land in the grid or not.
Unfortunately, the particular column whose cells I am interested in altering remains unaffected so there seems something odd about it ...
All the columns get populated on the fly via a stored procedure that is mapped to a dataadapter that is created inside a .xsd file.
The one odd thing about the particular column I want to affect via code is that it is not actually a column existing in a table instead it is created via with a little t-sql
manipulation in the select statement of the stored procedure alongside the other normal columns similar to the one shown
Select NormalColumnActuallyExisting1,
NormalColumnActuallyExisting2,
NormalColumnActuallyExisting3,
ColumnCreatedOnFly = Case When NormalColumnActuallyExisting1 = 1 then ...
When NormalColumnActuallyExisting2 = 1 then ...
When NormalColumnActuallyExisting3 = 1 then ...
Else ...
End
NormalColumnActuallyExisting3,
...
The odd (ColumnCreatedOnFly) gets populated with a hardcoded string based on the bit values of NormalColumnActuallyExisting1, NormalColumnActuallyExisting2 and NormalColumnActuallyExisting3 columns so it really puzzles me why it wont accept the string in the Change 1 I have described above...
So I did the changes below:
Change 3: I then proceeded to change the value from 68 to the boolean true
Result : The odd column whose value I want to change still remains unaffected
Change 4: I then proceeded to change the value from true to the integer 0 (for bit)
Result : The odd column whose value I want to change still remains unaffected
All I want is to be able to push a string in that said odd column but finding the grid not cooperating with me right now ... so is there a way for me to make it happen ... thanks again for all the help I really appreciate it.
|
|
|
|
|
It looks like somekind of limitation in the DataGridView control which prohibits use of on the fly created virtual (non-existing) column ...
As I learn more of DataGridView I will discover more what can and can't be done with it. ... thanks again
-- case solved --
|
|
|
|
|
It appears to be somekind of limitation in the DataGridView control which prohibits use of on the fly created virtual (non-existing) column ...
For now this works for me and maybe as I learn more of DataGridView I will discover more what can and can't be done with it. ... thanks again
-- case solved -
|
|
|
|
|
I'm working on an app that has custom exceptions defined. When the DAL wants to communicate that something is wrong, not necessarily an error, then it throws a custom exception. The theory here is that the UI can catch them and know what's wrong.
Examples might be a purchase amount exceeding a credit limit. The custom exception AmountExceedsCreditLimitException is thrown, with the message and amount attached to to it.
Then the UI now knows about this and can deal with it.
Now I know some who say that Exceptions should only be used for true errors.
I'd like to get your opinion.
If it's not broken, fix it until it is
|
|
|
|
|
I guess there's always people who are going to be polarised one way or another - yet I think the major crime is throwing exceptions, catching them, and chucking them away.
Define 'true error' anyway - surely that's also in the context of the software
At least in your case, the exceptions mean something, and are being caught and handled
|
|
|
|
|
Throwing Exception("<blah>") isn't too useful because you can't code for those exceptions (i.e. e is CustomExceptionType). Custom exceptions are better, but you'll find that you'll end up writing THOUSANDS of these AmountExceedsCreditLimitException type classes.
IMHO, your example of AmountExceedsCreditLimitException should not be an exception, but rather a bool return from a method.
Goes back to my first point, once you start doing custom exceptions, its easy to get overzealous and make everything exceptions.
|
|
|
|
|
SledgeHammer01 wrote: Goes back to my first point, once you start doing custom exceptions, its easy to get overzealous and make everything exception
That seems like what's going on here.
The problem is that if you want to return some kind of message to the UI, then the message has to be defined in the DAL or BL, rather than in the UI where it belongs. Using the custom exception tells the UI "Hey, this condition occurred. You decide how to tell the user", rather than "Hey, this condition occurred and here's what to tell the user".
If it's not broken, fix it until it is
|
|
|
|
|
Is the user really going to be able to do anything about the error? Most of the time probably not if they are not technical. The .Net framework throws custom exceptions so you might want to be consistent with that. Personally I try to show the user as few errors as possible because they'll just think the software is buggy. Better to try to handle common errors yourself silently and log the ones you can't.
|
|
|
|
|
I think this is a great question to throw (  ) out in the community and I am interested in seeing the responses. I am in favor of throwing exceptions on errors and when the code encounters an unexpected situation. Vague, I know. I would not want to make a more detailed statement because it depends on what is considered unexpected in any given function, library or application.
In an application handling charges to credit cards, I do not think it is unexpected that an amount can exceed the available credit limit, so I would be against categorizing that as an exception. It seems to me that if you go down that road, you end up defining the program behavior through the use of exceptions.
Here is a link to what I will normally follow.
http://msdn.microsoft.com/en-us/library/ms173163.aspx[^]
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
That sounds OK to me, but that still doesn't seem enough like an Exception, and a boolean wouldn't give enough information, a good old enumerated value might be good.
public enum TransactionStatus
{
Pending
,
Applied
,
Rejected
,
NoSuchAccount
,
InsufficientFunds
...
}
|
|
|
|
|
{ true, false, EFileNoteFound }?
Needless to say, I'd recommend using the exceptions; yes, there's a performance-penalty, but it's hardly noticeable. Unless it's in a tight loop, you won't notice it.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
The problem with this is that, one, Exceptions are a little expensive to throw, so if you end up throwing a lot of them, well, it adds up.
Two, as the name suggests, is what you're finding "exceptional"? No, it's not. What you're doing is making a determination of an account status as part of a normal business process. You're chosing two different paths to return the two possible states of an account. THe account can either have sufficient credit, or not.
What you should be doing is not relying on exceptions to determine the state of a business object. The business object should be telling you its state. If you have to wrap or include a state object in your transaction object, fine.
Exceptions should be used to transmit information outside of your normal business process, such as if a transaction fails to commit because of a database failure.
|
|
|
|
|
Dave Kreskowiak wrote: the state of a business object
Who said anything about business objects? 
|
|
|
|
|
Dave Kreskowiak wrote: The problem with this is that, one, Exceptions are a little expensive to throw
This is a bit of a myth.[^] if you run tests with the debugger on you get poor performance, without debugging it is OK.
Otherwise, I agree. We use the exceptions as business logic at work and I don't like it: We've 100s of exception classes (and a deep hierarchy) to handle cases that often should be state within a business object. Not only is there this exception-bloat but it makes stuff harder to trace: I have to work up through the potential call stack to see where something is handled. Not only that we rely on the exception being caught somewhere (if not the user gets an error screen for normal business logic), instead of a more traceable return result (or object state).
I can see where the "exception" camp comes from, but I think they are wrong.
“Education is not the piling on of learning, information, data, facts, skills, or abilities - that's training or instruction - but is rather making visible what is hidden as a seed”
“One of the greatest problems of our time is that many are schooled but few are educated”
Sir Thomas More (1478 – 1535)
|
|
|
|
|
Keith Barrow wrote: This
is a bit of a myth.[^] if you run tests with the debugger on you get poor
performance, without debugging it is OK.
Hang on a second. I did my own testing in Release builds. The problem comes in when the CLR has to search up the call chain to find a handler. It's not so much the Throw that's slow, as it is finding a Catch.
|
|
|
|
|
I'm for avoiding try/catch blocks unless absolutely necessary. It's a heavy operation and should be avoided if you can solve it by using normal means of handling it.
eg. check if the file exists before performing any operation on it (open, write, read) instead of just trying to open/write/read it and catching the exception.
Just my thought.
|
|
|
|
|
V. wrote: It's a heavy operation
Create a console-application, and throw as much exceptions in a loop as possible in a second. How many exceptions did it generate? (Last time I checked, more than 10k on a very slow machine)
It ain't that heavy, unless you have a debugger attached.
V. wrote: and should be avoided if you can solve it by using normal means of handling it.
That sounds like a religious statement. Do you think an integer representing an error would be easier?
V. wrote: eg. check if the file exists before performing any operation on it (open, write, read) instead of just trying to open/write/read it and catching the exception.
Checking would be redundant in that case any way; but imagine some object that can have three different problems; would you use integers or exceptions to communicate the "error" to the user?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: It ain't that heavy, unless you have a debugger attached.
And thus, no problem?
Eddy Vluggen wrote: That sounds like a religious statement.
Not at all, I use try/catch more than often enough.
Eddy Vluggen wrote: Do you think an integer representing an error would be easier?
Since your dutch, dat is wel héél kort door de bocht. (sorry didn't know the English expression)
Eddy Vluggen wrote: Checking would be redundant in that case any way; but imagine some object that can have three different problems; would you use integers or exceptions to communicate the "error" to the user?
You're comparing integers and exceptions which is like comparing apples with pears. I use a descriptive message to show to the user and in that message I'll explain what he can do with it.
Don't shoot me for giving an honest reply.
(I think hope you didn't mean too)
|
|
|
|
|
V. wrote: Don't shoot me for giving an honest reply.
(I think hope you didn't mean too)
I never mean to, but interhuman-communication isn't one of my strong points. Then again, the worst that could happen are a few downvotes, and I might learn something 
V. wrote: And thus, no problem?
Nah; just that it's not a heavy operation. Still, you made me curious. Can you give me an example of the problem you're trying to avoid?
V. wrote: Since your dutch, dat is wel héél kort door de bocht.
"Kort door de bocht" is geen argument; omrijden is nooit een wijs idee. For the English reader; "kort door de bocht" means taking a (inofficial) shortcut; and in coding, KISS is preferred.
V. wrote: (sorry didn't know the English expression)
A "jump to conclusions-mat". Seen the movie "Office Space"?
V. wrote: You're comparing integers and exceptions which is like comparing apples with pears.
No, I'm taking a particular use that we have for exceptions, and wondered what alternatives there could be, and whether they're more preferable or not.
I have seen "True, False, EFileNotFound" in code too often. It's easier to create a new Exception, to throw it, and to handle it. Yes, I'd say that such even goes for the validation of a BO. Why? Because it'll be guaranteed in a "correct" state; no illegal values in any properties, as it would throw an exception.
My old PC did around 10k exceptions in a second (throwing and handling). The one at work did around 33k in a second, and the new PC (new means "from the store a week ago") does 48000 exceptions per second.
..and only 192 in debug mode.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
V. wrote: It's a heavy operation
Not on modern systems. In the 90s that was true for C++ and probably Java, but I have seen no evidence since that one need be overly concerned about that versus any other obvious performance related issue.
|
|
|
|
|
Kevin Marois wrote: Examples might be a purchase amount exceeding a credit limit.
That specific example means that the database doing business logic so of course it must be capable on communicating a business failure. I suspect that an exception is a convienent and perhaps even the best way to do this.
Naturally if there are a lot of business rules in the database then there will be a lot of exceptions. However I question the need for different types of exceptions. I suspect it could be encoded within a property of the exception and although that seems more complex because there are already so many the complexity is the same.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
