|
Yes. But I dont know the solutoin exactly. Google it
|
|
|
|
|
hi!
i am building an application which inserts 100000 or more records in XML file and then retrieve those records when required in a datagridview control.
The retrieval of records is very slow, it takes 1-2 minutes in populating datagridview. First i thought it is because of XML, but today i came to know that it takes more than one minute for just creating 100000 rows of datagridview. I checked it by inserting 100000 empty rows in datagridview.
I tried to create rows in a separate thread but it gave exception that row cannot be inserted from a thread other than the one which created datagridview. i tried the technique available on msdn, which makes "Thread-Safe Calls to Windows Forms Controls" but it did'nt worked (may be i was not able to handle it)....
Now can any one please tell me how to get required result...? how can i add 100000 or more rows in datagridview control within 10 seconds...? is there any alternative way to do this?
Thanks in advance...
Regards,
Affan Ahmad Toor
|
|
|
|
|
Maybe 100,000 rows in a datagridview isn't what you really want. The user can only see a few of these at a time anyway, right? Just a thought.
Regards,
Matt
It isn't enough to do well in life.
One must do good when and where one can.
Otherwise, what's the point?
|
|
|
|
|
You don't. You create a DataTable, or some other DataSet that holds all of your data, then bind the DataGridView to this data source.
I can fill a DataTable with 100,000 row of randomly generated data and show it in a DataGridView in less than 4 seconds.
Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007
|
|
|
|
|
Hi!
Thanks for reply, i just solved my problem with your mentioned method. I am not able to populate 100000 records in 4 seconds, as you mentioned, it is taking approximately 10 seconds, but stil it is better than 1 minute and fulfils my requirment..
Thanks again...
Regards,
Affan Ahmad Toor
|
|
|
|
|
Affan Toor wrote: I am not able to populate 100000 records in 4 seconds, as you mentioned, it is taking approximately 10 seconds,
Noone ever said XML was fast. Storing 100000 records in an XML file is not a good idea. XML was meant to be a transport, not a database. It only has the look and feel of a database table.
Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007
|
|
|
|
|
Hello all, we are writing a server that comunicates with clients using .Net remoting but we have a couple of problems:
in order to keep separated the implementation of the remotable object we create that object on the server. That object exposes a GetConnection object that returns a new object for each request, this way we can have a dedicate object for each client. Is this a correct way of achieving this?
In addition, we need a way to listen the connection status of each object (that is, if a client losts the connection, we can close the thred).
Can someone help me? Thank you all!
Alessandro
|
|
|
|
|
What was the logic behind the decision for the Release build of a C# program to be totally decompilable even down to the variable names? It seems an incredible design decision to me.
|
|
|
|
|
It's not really an incredible decision. How would you expect reflection to work? How about JIT compilation? Remember, that .NET generates IL code and you see why it works the way it does.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
That's all well and good but why include the original variable names? Why not produce a compact form with minimal identifiers? MS are anti-GPL because you have to give out your source code, and here they are promoting a language which effectively distributes your source code on a plate!
|
|
|
|
|
Original variable names are still required for reflection to work, Additionally, all (non-private/internal) entity names are required for the way the CLR finds external references. The one thing that could be "removed" are scope-local variables, but that won#t help a lot, andobfuscatorsa can do this.
I fully understand your concern, I need to keep this in mind permanently when deciding which technology for which product. But that's a tradeoff that in most cases makes sense.
There are two main ways to deal with code to protect:
* use an obfuscator
* move critical code to an unmanaged binary
* Reflection.Emit
All are not "complete": obfuscators seem a delicate balance between making the code unreadable and breaking it. External binaries, beisdes the old "find that DLL" problem, would still isolate the critical part and make reverse engineering the easier. Reflection.Emit could be used as addiitonal "obfuscation of ideas", but doesn't protect the code from being copypasted.
IIRC upcoming Authenticode features are supposed to provide a new mechanism that gives you control over who sees what. (I am not sure though, how well it is received or protects, as it sounds to much like DRM)
But keep in mind that every binary is reverse engineerable, it's just a quesiton of skill and patience.
|
|
|
|
|
There's a number of reasons for this. At the core, the fact is that most people are targetting markets that do not contain people likely to decompile code. Having your code compile on the target machine opens the door to things like a version of the framework that optimises for new processors, such as dual cores or 64 bit. It also means that in theory the framework can target multiple architectures.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: It also means that in theory the framework can target multiple architectures.
What do you mean in theory? What about Mono?  Doesn't that run on most Linux systems which run on most processors?
|
|
|
|
|
Isn't Mono not allowed to impliment the Windows.Forms classes ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
From what I understand they are allowed but things at the moment are so tied down to Microsoft's way of things that they implemented stuff on GTK because a it was easier and b provided more flexibility (GTK was more established on different platforms and had more flexibility I think). I've got a feeling that they may have simply mapped the critical Windows.Forms to the GTK namespace.
You can from what I remember of my experimentations run most Windows.Forms apps on Mono without any adjustment but there are a few classes etc which are deeply tied into MSs way of things that they don't run. (Yet again) from what I remember the comments were that yes there are some problems with simply copying and pasting code across but there are some quite straightforward workarounds which will work in both Mono & MSs implementation so as long as you know of these before hand you should be OK.
Of couse most people writing for Mono use the GTK etc implementations because they're more used to coding to those in C++ etc and they're stuck in their ways.
But as far as I know there isn't a legal reason why Mono can't implement the Windows.Forms classes.
|
|
|
|
|
I understand that, but for a release build to contain the original variable names is just daft. Why not do a compile-time replacement of the names with the shortest possible names to at least obfuscate your code and make the IL version as short as possible?
|
|
|
|
|
to create work for people writing obsfucators, of course.
Decompilation is very useful, for example, if you need to see what the framework is doing. You don't get the source like you did for MFC, but with a decompiler, you do.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: to create work for people writing obsfucators, of course.
Not only does it let you see what the framework is doing, it also lets your customers see what you are doing. Suppose you are charging for the interface software to some proprietary hardware - with C# your customers can see exactly how the interface works and write their own for free. Goodbye revenue stream!
This has put me off using C# for any serious work that I will be sending to customers. I think I will be sticking with C++ and MFC for the foreseeable. 
|
|
|
|
|
Steve_Harris wrote: This has put me off using C# for any serious work that I will be sending to customers. I think I will be sticking with C++ and MFC for the foreseeable.
Why? Unless you are doing serious reflection, there are ways round this using tools like Obfuscators.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Why should I have to buy one just to protect my IP? If I compile a C++ program it is immediately pretty well protected.
|
|
|
|
|
Steve_Harris wrote: Why should I have to buy one just to protect my IP? If I compile a C++ program it is immediately pretty well protected.
But not bulletproof. While it is protected better, it still isn't totally foolproof. All code is capable of being reversed.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Steve_Harris wrote: it also lets your customers see what you are doing
Sure, if you have the sort of customers who would be inclined to look.
Steve_Harris wrote: I think I will be sticking with C++ and MFC for the foreseeable
The obvious alternative is to write C++ DLLs that hide your proprietary stuff and call them from C#.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: The obvious alternative is to write C++ DLLs that hide your proprietary stuff and call them from C#.
What about C++/CLI? Isn't that managed and unmanaged code in the same assembly?
(Just curious...  )
-alwinus
|
|
|
|
|
C++/CLI is managed code, so it also can be decompiled. It can be a combo of both, but the unmanaged part is the only way to write stuff that can't be decompiled.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
I have 2 binding lists (say A and B), i need to compare the contents of A to B to see if they conatin the same items.
How can i do this?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
