|
Hoda,
The line
<br />
double t; <br />
should be changed to:
<br />
double t = 0;<br />
You need a default value. The first iteration of your foreach statement is trying to add a double value to null which doesn't work. So give 'er a default value and be off 
Hogan
|
|
|
|
|
Dear Hogan,
thank you very much for you response.
Hoda
|
|
|
|
|
I am developing an application where multiple users will have concurrent access to a database for reads, writes/adds, deletes and updates. Much of the user interface will be through the DataGridView control. I am trying to come up with as elegant a solution as possible to dynamically update a DataGridView for, say, User #2 if User #1 makes a database change to the same table that User #2 is viewing. It seems that I have to programatically refresh the grid no matter how I have it bound to the database (connected or disconnected recordsets). Am I missing something? Is there something in ADO.Net that will enable me to bind data to a grid such that any changes to the database will almost immediately be reflected in the grid with no forced/programmatic refresh?
Thank you...
|
|
|
|
|
No There is no such facility. The closest thing to what you want is SQL Server Notifications, but that is cumbersome and overkill here.
Your idea to update user1 of changes by user2 may not be as good a design as you think. Some questions to consider:
1. How likely is it that multiple users will be modifying the same data?
2. What is the likelyhood they will be viewing the same data (same subset of rows in the same table).
3. If user1 edites field A of row 2 just as your update notification arrives for User B having done the same, what will you do - overwrite user1's change? how annoying might that be?
In most cases both 1 and 2 are relatively rare, so all the network round trips needed to even determine if users need to be synchronized is not worth the negative impact on performance and scalability. The normal practice here is to detect collisions only when the user commits changes, and refuse them if the modified data had additional changes after the first user read them, but before he posted changes (typically by adding a timestamp field to each row, and comparing the timestamps - only allow update if they are still equal).
|
|
|
|
|
|
From the help on SqlDependency Class:
" SqlDependency was designed to be used in ASP.NET or middle-tier services where there is a relatively small number of servers having dependencies active against the database. It was not designed for use in client applications, where hundreds or thousands of client computers would have SqlDependency objects set up for a single database server."
Not a good ideal in this context.
|
|
|
|
|
when do we get StackOverFlowException? In what kind of situation cos i am in one.
|
|
|
|
|
Most of the time, you won't face this situation. But when there is a dead loop, StackOverFlowException will be thowed.
|
|
|
|
|
Generally when i run into it it's a case of infinite recursion. If you're running into it then the debugger should tell you where the problem is.
|
|
|
|
|
Most of the time this happens when you recursively call a method infinite times, like in the case of this getter:
public int SomeGetter
{
get { return SomeGetter; }
}
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Hi,
the most likely way to get a stack overflow is by having a property that refers
to itself, instead of refering to the data member that probably has a very similar name.
|
|
|
|
|
Hello everyone,
I am wondering why do we need to derive some type from IEnumerator<T>? Could anyone show me some useful samples?
I think using IEnumerator<T> itself should be enough in all cases?
thanks in advance,
George
|
|
|
|
|
Well, when to derive or just use the interface is according your context. If using IEnumerator is enough, you needn't derive from it. But sometimes, your class has its own responsebilities besides IEnumerator. So you will implement this interface.
|
|
|
|
|
Thanks adamzhang,
I can understand this point, such as the derived class may have some special rules for MoveNext.
But my confusion is how to initialize and create an instance of such derived class? Could you show a sample with some pseudo code please?
regards,
George
|
|
|
|
|
I'm sorry, but the term you are looking for is not derive. It's implement. There is a whole world of difference in OO terms.
|
|
|
|
|
Sorry, it is my mistake to use the wrong word. My confusion is how to implement a class, which implements IEnumerator<t>, especially how to write the constructor, any ideas or samples?
regards,
George
|
|
|
|
|
In most cases you dont need to do that.
read up on the "yield return" keyword, that will generate a ienumerable<t> for you
|
|
|
|
|
Thanks Roger,
I have found great samples by using yield.
regards,
George
|
|
|
|
|
Hello everyone,
New to C#, a simple question which my book does not cover.
If we do not specify the public/private access of get/set, then it is of the same as the public/private access to the property itself, but we can overwrite it.
For example, in the following code, in get method, when we do not specify public/private, it will be automatically the same as the property Abc, which makes get public, but in set, we can overwrite it to make it private?
public class MyList
{
class Foo
{
private int _abc;
public int Abc
{
get
{
return _abc;
}
private set
{
_abc = value;
}
}
}
static void Main()
{
Foo f = new Foo();
return;
}
}
thanks in advance,
George
|
|
|
|
|
Properties by their nature are public accessors for private/protected variables.
If you don't want an external object to be able to set a property, don't provide a set function. That makes it read-only from the calling object.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
What do you mean "public accessors for private/protected variables.", John? Default are public to property, set and get?
regards,
George
|
|
|
|
|
If you don't want to provide set method, just cut it off from property field, no need to put private accessor in front.
|
|
|
|
|
Thanks adamzhang,
Good point. 
regards,
George
|
|
|
|
|
True if you're using a backing field, but if you're using automatic properties en 3.0/3.5, you'll need a private set for it to work.
class WithAutomaticProperties {
public String NoBackingField { get; private set; }
}
class WithBackingField {
private string backing;
public String HasBackingField { get { return backing; } }
}
Scott P
"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
