|
I really don't think that would be it, but, when you compile your exe it'll produce some .PDB files. These are the 'program database' files and are used by the debugger to map the execution point and variables etc. into the source code.
If it gets out of sync then you can see some very weird behaviour.
When execution leaves your button handler, does the application carry on?
Regards,
Rob Philpott.
|
|
|
|
|
How could i put the pdb file back in sync? I already tried a complete rebuild but that didn't help.
|
|
|
|
|
Do a "Clean Project" first, then recompile it.
|
|
|
|
|
You could try a complete rebuild of your project and then put a breakpoint at the beginning of the btn_Click method and run it through your debugger. You should also review what that method is trying to do. As it stands it seems to be setting checkRequiredObjTypesOk randomly to true or false , but never uses that value for any purpose.
|
|
|
|
|
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 .
|
|
|
|