|
It doesn't quite work like that.
We do not do your work for you.
If you want someone to write your code, you have to pay - I suggest you go to VWorker.com and ask there.
But be aware: you get what you pay for. Pay peanuts, get monkeys
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Google will find you many samples.
|
|
|
|
|
Hello everyone
For some reason I have to make my DataGridView static member in a Windows Form project.
So as it is predictable the designer window won't show to me anymore.
I want to know is there any trick to see the designer window in this situation?
|
|
|
|
|
No.
Why static? That is a very unusual thing to do with a windows forms control, and I can't think of any reason which doesn't mean you are trying to do something else very, very wrong!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Every row in DataGridView represents information about a thread.
All threads do same job (consuming a WCF service) and any progress of thread will be show in the DataGridView immediately. As you know if I try to change cell value of DataGridView in that Method the CrossThreadException will occurs.
In this case I create a class named "shareMemory" which all progresses of a thread will save in its DataTable field;
Then the shareMemory class will update DataGridView. ShareMemory needs to access DataGridView so easiest way is to make DataGridView Static member.
|
|
|
|
|
I thought it might be something like that! 
No - bad idea. There is a mechanism for using UI controls from within other threads, to avoid cross threading problems: Invoke
So use that, don't try to twist things to work in a odd way!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
OriginalGriff wrote: I thought it might be something like that!
You have no idea of what I have done.
Maybe it's looks like odd but the way I have choose helped me a lot in the case of encapsulation.
|
|
|
|
|
Only because it is a "forced solution" - it may help in one way, but it raises horrible, horrible problems in dealing with other things. Such as trying to use static controls...
Sometimes, the hardest (but best) thing to do is to say "OK, that was a silly idea", throw it away, and look at finding a more appropriate solution.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
OK, that was a silly idea.
|
|
|
|
|
Cathartic isn't it?
You're right, I don't know the details of your app, but the way I'd handle it from what you have said so far is to have the thread update the DGV via Invoke (the thread has the form as it's this reference, so it can access form instance variables such as controls for just this kind of reason) and pass it a row reference and some indication of which WCF service it should process. I'd then use an event in the processing class to feed the data back to a thread event handler and Invoke from there. That way the processing class can be independant of the display and you can reuse the form!
The Invoke moves the control update back onto the UI thread, so there are no cross thread exceptions.
Does that make sense?
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
OriginalGriff wrote: Does that make sense?
Absolutely !
|
|
|
|
|
I ran into doing something similar to this. I've got a DGV showing progress of a bunch of Tasks all doing work dependent on remote servers. Trust me, you do NOT need a static control. It does not solve the problem of cross-thread operations.
What you do need is whenever a background thread needs to update it's status it calls a method to update it's status in a table specifically made to track that information. When that method is called, it can determine if it needs to Invoke itself (put its own execution on the UI thread) to update the table and then refresh the grid that's bound to it. That's easily done with control.InvokeRequired.
|
|
|
|
|
In addition to what Griff said: Gather the information of the threads in an object and then pass that object to the UI datagridview (which is not static).
|
|
|
|
|
I’m writing an exam management program for a high school, using a remote SQL Server database. In the project, I access the database quite often, to get lists of student names, subjects, sets etc. The student (about 2200 records), Teacher (about 50 records) and subject (20 records) tables contents change very infrequently, I was wondering:
1. Would it be more efficient to read these tables at program start, and retain the information as lists<T> in memory, or should I read each table whenever the user needs it (possibly five times per session)?
2. Is SQL Server 2012 overkill for this project? I’ve thought about using SQLite in a local database, but for the life of me, I cannot get it to work. (This is the problem of working by myself, I’ve no-one to bounce ideas off).
3. Do any of you boffins have any better suggestions as to how to go about this?
I’m putting this in the C# forum, as that’s the language the database will be accessed from, but if you think that it should be in the database forum, please feel free to move it. (Or tell me and I’ll re-write it there).
|
|
|
|
|
It really all depends on what you are doing!
There is no "this is best" solution - or we would all just use that and the other solutions would fall by the wayside...
The SQL server SQLite decision is a case in point: Are you expecting only one person to use the information, or multiple people? If it's one person, then yes, SQL Server can be overkill. But if it's two people who need access to the DB, then a server based solution (SQL Server or MySql) is absolutely a good idea, and SQLite is a very poor decision because it will give you enormous hassles. But...Yesterday I spent ten minutes swapping one of my utility apps from SQLCE to SQL Server despite being the only person who uses it, simply because I was fed up with the low speed on start up / shut down - so it's isn't always as black and white as it seems...
The tables are the same: it depends what you are doing! I have systems which do it both ways: but generally if two people can change the data, then local caching becomes a problem, unless you use some SQL triggering to force an update on your application - which is not a trivial job!
So no, we can't tell you which way to go: just keep you data layer separate from your business and presentation layers so if you did chose the wrong solution, you can "undo" it as easily as possible!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Thanks Griff, you've put into words exactly what I wanted to hear. there's about 50 teachers, and it's remotely possible that they will all be entering results at the same time. Taking your advice, I've decided to use SQL server. The project will be on separate laptops, each with 8Gb of memory (don't you just love school standardisation?), so downloading all the data at run time won't be a problem, and I will have a trigger to flag updates. Not quite figured out how to do that yet, but I'm sure it can be done.
I'm going to use Entity Framework, as my data layer, with the business and presentation layers separated as well. In fact the only problem I can see is convincing the management team that the data is actually secure, even though it is on a remote server.
|
|
|
|
|
You're welcome!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Just a thought: You could keep a table in the database with revision numbers per table (or the whole database). Cash the data and refresh when the revision number is higher then local (small query that runs every minute). When you update, delete or insert data increment the revision number. You should use stored procedures in sql server, queries are very slow.
|
|
|
|
|
joost.versteegen wrote: You should use stored procedures in sql server, queries are very slow.
Explain me how sprocs are a magnitude (!) faster than a normal query?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Sprocs are compiled and then stored. queries have to be compiled every time.
|
|
|
|
|
|
oow...i see. Back in the old days when I learned sql server (4.1 or so) they where faster. sorry!
|
|
|
|
|
Wasn't exactly sure where to put this question...
We are currently using Programmers File Editor (which hasn't had an update since 1999 I think) to edit and view large and small data files before processing. Since moving to 2008 R2 it's been acting up a bit and will just close and other normal not supported software behavior. The key features I'm looking for is the ability to view files with large rows (col count over 35,000), checking for updated files before saving (basically have a file open twice, make changes in both places it should notify you that the file has changed before the second save happens), and kinda going with the last, notifying you of file changes if you move off it and go back (drop focus then gain focus), displaying row and col position is very handy as well.
Thanks!
|
|
|
|
|
Notepad++ should do all of that for you.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Just tried it, and it overwrote the file changes without asking...
This check before saving thing is basically because of one file that should be a database table.
Thanks for the suggestion though...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
