|
Filling any grid with 100,000 rows is going to be slow. That aside, IMO there are far better grids around than the Janus offering (unless it has improved greatly of late). Are you too far down the road to review your choice of 3rd party controls?
Regards,
Rob Philpott.
|
|
|
|
|
You should only be filling the view with a page of data at a time: most decent controls will enable you to do this quite simply. Check out Infragistics[^] or Telerik[^] or DevExpress[^] or Obout[^] amongst many others.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
|
Paging is the option to go with..
suchita
|
|
|
|
|
In C# - Classes are reference types; structures are value types.
I was reading about this and saw something which I didn't understand.
I have created a simple program to explain my doubt. In this program I have defined a class and a structure with an integer variable.
class TestClass
{
public int x;
}
struct TestStruct
{
public int x;
}
Now I have couple of static methods each changing the value of the integer.
static void ChangeStruct(TestStruct ts)
{
ts.x = 10;
}
static void ChangeClass(TestClass tc)
{
tc.x = 10;
}
Now in the main method, I call this functions and results are as expected.
static void Main(string[] args)
{
TestStruct ts = new TestStruct();
ts.x = 20;
Console.WriteLine("Before change: ts is ({0})", ts.x);
ChangeStructure(ts);
Console.WriteLine("After method: ts is ({0)", ts.x);
TestClass tc = new TestClass();
tc.x = 20;
Console.WriteLine("Before method: tc is ({0})", tc.x);
ChangeClass(tc);
Console.WriteLine("After method: tc is ({0})", tc.x);
Console.ReadLine();
}
So far so good. Now when I uncomment the line tc = null; in the method ChangeClass, I expect the class to be null referenced i.e it should not reference to any memory in the heap any more.
But that is not how it works.
Can anybody explain me why there is a different behaviour here.
Thanks a lot!
|
|
|
|
|
That's because tc is a reference type passed by value, ie. a local copy. Setting it to null in the static will not change the value outside the method. Stick the word 'ref' in front of it and you'll probably get the behaviour you're expecting.
Regards,
Rob Philpott.
|
|
|
|
|
Thank you for answering.
Rob Philpott wrote: That's because tc is a reference type passed by value, ie. a local copy
I do understand that, but what confuses me is why the values are changed then. I see an inconsistency in the behaviour. Since the memory reference is passed, if we are changing the value in the method, it is getting changed and assigning a null doesn't.
Rob Philpott wrote: Stick the word 'ref' in front of it and you'll probably get the behaviour you're
expecting.
Yes that will do the job.
|
|
|
|
|
Ron, I was thinking upon Ian's answer and finally understood the concept. You may like to check my reply to Ian.
Thanks for your help. Since your answer is also correct, I am voting it up.
|
|
|
|
|
Simple... The key is the way you pass the reference to ChangeClass.
When you do ChangeClass(tc), you're only sending a reference to tc... You're telling ChangeClass where, in memory, it can find the data in tc. And since you didn't specify the ref keyword when passing it to ChangeClass, you're just sending a COPY of the reference, not the original variable.
As an analogy... I have the URL to a website, and I e-mail it to you. You erase your e-mail, but you haven't erased my copy of the URL, just your own.
|
|
|
|
|
Thanks, that very much clears the doubt.
Please see what I got is correct:
I have a reference stored to the object of the TestClass on the stack. When I pass this to the method ChangeClass, I just pass a value which refers to a memory location which is same as the actual memory location of the object. So any change to the fields of the class is reflected as the method is accessing the same memory location. When I assign the object null in the method, the reference to the object is no more available to the method. But it is still available to the Main method.
This is my understanding. Please let me know if I am wrong somewhere.
Thanks and voted as a "good answer".
PS: I am changing the message type to answer as it contains descriptive answer.
|
|
|
|
|
|
|
mmm, you're not rendering the class itself to null I think, rather the parameter tc.
Since it is a reference it should be the same object, but maybe .Net does something funky when the parameter passed to a method is the same type as the class.
I don't know for sure, but it could be. Try passing the object with the ref keyword (need to change method signature as well).
V.
|
|
|
|
|
V. wrote: Since it is a reference it should be the same object, but maybe .Net does something funky when the parameter passed to a method is the same type as the class.
Function arguments are always passed by value unless the ref keyword is used.
|
|
|
|
|
What do you think of this bit of code?
Subscriber[] subscribers = subscription.GetSubscribers();
Array.ForEach(subscribers, s => s.SendResponse(publishableItem));
i.e. the use of Array.ForEach with lambda rather than a traditional foreach with a code block?
Regards,
Rob Philpott.
|
|
|
|
|
Looks fine to me. What's the issue?
|
|
|
|
|
No issue, it works ok, but I'm a bit old fashioned and come from a point of view where simplicity always wins the day. Just little things like why are we using static Array.ForEach when the language provides 'built in' support for such things. Also, if I remember back, doesn't every delegate result in a whole class being generated behind the scenes at MSIL level. Isn't there a performance hit associated with invoking a delegate?
Although there's nothing wrong with it as such, why do it this way? It just has a ring of macho programming about it.
Regards,
Rob Philpott.
|
|
|
|
|
Does the job nicely.
I'd probably stick with the foreach code block, only because VS's Edit and Continue doesn't work in functions with lambda expressions, so it would slow down my tweaking/debugging a bit.
But Array.ForEach does look a lot cleaner.
|
|
|
|
|
Why not combine the two lines, by the way?
Array.ForEach(subscription.GetSubscribers(), s => s.SendResponse(publishableItem));
|
|
|
|
|
Well, I'd argue that its more readable and readily understandable being spread over several lines (it makes the execution flow clearer), and the local variable you have removed could be something useful to hover over when debugging.
There's nothing wrong with the code, I'm not saying that, but I think it can be expressed more clearly and would be easier to debug done the traditional way and I'm trying to gauge whether people agree with me or not.
Regards,
Rob Philpott.
|
|
|
|
|
I'm sure that everyone has their own opinion on "to variable, or not to variable".  Personally, I never create one-time-only variables: I only establish them if they need to persist, or if I need to use them more than once. (And honestly, "readability" is never an argument that holds water for me, I've seen it used to defend bad practices in the past.)
It will work fine as you have it, of course.
|
|
|
|
|
Lambdas are a code smell. 
|
|
|
|
|
HI,
I need of a nice gauge control to show a measurament of an angle variation ... can help me to found control / soucecode?
Thanks a lot!
Alex
|
|
|
|
|
Have you tried Google? "C# gauge control" gives some good results.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
