|
This may not be possible in your case, but since you have provided the C++ code, have you tried compiling the C++ part as C++/CLI and using managed arrays in the C++ part? You could then make the C++ part a DLL that is referenced in your C# project.
I do this all the time in order to get over the difficult unmanaged/managed boundary.
|
|
|
|
|
Class a
{
a obj=new a();
}
in this case we are calling the default constructor
but
class a
{
public a(int i)
{
console.writeline(i);
}
a obj=new a(); //Gives error during compilation
}
In this case we can't call default constructor after creating a custom constructor.
But why it happns???
Why we cant use default constructor in this case
|
|
|
|
|
Because it doesn't have one.
|
|
|
|
|
means?, can u describe it
|
|
|
|
|
In your first version of class a, you haven't specified a constructor. This means that a default constructor is created for you. As soon as you add a constructor, you lose the default constructor. This is exactly what should happen because you can't instantiate a class that doesn't have a constructor, and you don't want the compiler to give someone the ability to use a default constructor if your class relies on values that are passed in via the constructor.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
