|
That part was not finished yet.
|
|
|
|
|
OK. However I have just tested your code (modified to fit my sample) and it works fine using both for and foreach. You need to get to work with your debugger to see what is happening. I suspect some out of date code is getting linked in by mistake somewhere.
|
|
|
|
|
joost.versteegen wrote: the program jumps out of the method (in the lin
No, it doesn't. It jumps out on the line after that, as your control is not a combo. Using "as" does not throw an exception, the variable is null and ignored.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
No, it does realy jump out of the line i specified. The debugger sometimes does not reach the "if (cb != null)" test!
|
|
|
|
|
Add in a Debug.WriteLine to show the names of the controls found. It will only loop the children, not any sub-children btw! The code will SKIP anything that is not directly on the form (IE, any combo that's on a panel).
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
took your advise and added a number of debug.writeln statements...the code did exactly what it was supposed to do...but the debugger keeps doing strange things. Thanks anyway!!
|
|
|
|
|
Did you deploy a version to the GAC?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
The debugger is sometimes a little buggy. Set a break point in one of the next lines to be hi. Generally, it will stop then there even if it uses to leave the method to nowhere.
|
|
|
|
|
I tried lot of coding but not yet to get the answer. so could you help me. please send me source code and c# code for that.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
