|
zead wrote: I use suspendLayout() before removing and resumeLayout after removing but it is still refreshing.
The Form should not be updating if you have used 'SuspendLayout properly.
Are you executing 'SuspendLayout outside the loop in which the Labels are being removed ?
Please describe in detail exactly how the Form appears to be updating: what do you see ? Are all the Labels on the Form; or, are some of the Labels inside some Container Control, like a Panel ?
“The best hope is that one of these days the Ground will get disgusted enough just to walk away ~ leaving people with nothing more to stand ON than what they have so bloody well stood FOR up to now.” Kenneth Patchen, Poet
|
|
|
|
|
Hi,
This is the code:
private Void RemoveLabels()
{
SuspendLayout();
try
{
for(int i=0;i
|
|
|
|
|
That is a lot of labels to remove from a form.
Can you describe the refreshing issue that you are having?
one thing to try is to enable the double buffering on the form[^].
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
Hi,
I mean by refresh you can see the form redraw the controls and you can see the Labels when it is removed, I want the label to still shown until last label deleted and empty the form.
Thanks
|
|
|
|
|
To add to what the others said, you can't do that anyway.
You cannot modify a collection which is being used as the target of a foreach loop.
You should consider a for loop instead - and work backwards through it, not forwards - or construct a separate list of "removable" controls and remove them afterwards.
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 – ∞)
|
|
|
|
|
Quote: work backwards through it, not forwards
Thank you, Thank you, Thank you!
This is definitely my lesson for the day - I never figured that iterating through the list in reverse was the way to do this.
I always used to amend the index and bounds when I removed an item from a collection
Embarrassed for missing this and glad that I have learnt the correct way - sometimes the simplest things slip by us 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
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 – ∞)
|
|
|
|
|
A side-note: trying to delete items in collections in a 'foreach enumeration of the collection does, in many cases, throw an actual error at run-time. In the case of removing Controls using 'foreach, an error is not thrown, however, not all the Controls targeted are removed. Another "strange but true" artifact of .NET (still valid in .NET 4.5, 4.5.1).
“The best hope is that one of these days the Ground will get disgusted enough just to walk away ~ leaving people with nothing more to stand ON than what they have so bloody well stood FOR up to now.” Kenneth Patchen, Poet
|
|
|
|
|
Another option, depending on your layout, is to put all the labels in a Panel control. Then you just hide the Panel instead of removing 150 labels.
|
|
|
|
|
I use a curtain[^] to hide multiple rapid screen updates in this[^] app. Works like a charm!
/ravi
|
|
|
|
|
At the risk of kicking a dead-horse, I'll throw my 2 cents in:
1. OriginalGriff's answer is spot-on. You can see my comment on his answer for an observation on the curious fact that using 'foreach on a Collection of Controls, and removing Controls in the loop, will not throw a run-time error, but will have "unexpected results."
2. Dave Kreskowiak's answer is spot-on: if all the Labels are in one Container Control, like a Panel, why not dispose of the Panel, or remove all the Labels by using PanelName.Controls.Clear();
The more interesting case is when you have a bunch of Controls that are visually "mixed-in" ... in the same containing object ... and you want to do something to some of those Controls, but not other Controls. In that case you can use a 'Tag to "mark" the Controls of interest for some future operation.
1. at design-time select all the Controls you want to tag: bring up the property browser, enter some text in the 'Tag property field.
2. assuming you tagged all 150 labels you want to, eventually, remove with "removable," and that all those labels are in a panel named 'panel1:
panel1.SuspendLayout();
var labels = panel1.Controls.OfType<Label>()
.Where(lbl => lbl.Tag == "removable")
.ToList();
for (int i = (labels.Count - 1); i >= 0; i--) panel1.Controls.Remove(labels[i]);
panel1.ResumeLayout();
“The best hope is that one of these days the Ground will get disgusted enough just to walk away ~ leaving people with nothing more to stand ON than what they have so bloody well stood FOR up to now.” Kenneth Patchen, Poet
modified 4-Mar-14 21:49pm.
|
|
|
|
|
How to use the GoF in project? there are 23 patterns in GoF,but I don't know how to use them in project.
|
|
|
|
|
I see this is your first message in CodeProject: welcome !
A design pattern is a generic abstraction of a certain type of solution/method for commonly encountered problems/tasks in programming.
You can find many resources here on CodeProject for almost any design pattern: just search. For example, if you want to study the "Factory Pattern:" [^]. This search will get you articles on CodeProject in the last year, whose ratings are between 4.0~5.0.
Articles like these will typically show you a design pattern in actual use to achieve some programming solution, or task.
“The best hope is that one of these days the Ground will get disgusted enough just to walk away ~ leaving people with nothing more to stand ON than what they have so bloody well stood FOR up to now.” Kenneth Patchen, Poet
|
|
|
|
|
Thanks you BillWoodruff,I feel CodeProject is a good website,There are many technology very cow force.I hope I can learn more things here.
|
|
|
|
|
With design patterns, first you need to answer few questions by yourself. Questions like:
1. When to use which pattern?
2. Do I need to use XYZ pattern in my application?
Once you have identified an appropriate pattern, look for code samples on CP or anywhere else you prefer.
|
|
|
|
|
That's a lot like asking "I have 23 different tools in my shed, what should I build so that I get to use some tools? I don't know how to use tools in a project."
It's a little silly, and remember, design patterns are means, not ends. They're not magic faerie dust that you can sprinkle on your project to make it cool, they're pre-made ways to solve problems that show up from time to time (some more often than others).
|
|
|
|
|
Patterns describe problems and a way to solve them.
If you don´t see a problem in your project, you don't have to look up the patterns.
Critical thing is to see/smell the problems (same as with refactoring) : browse over the problem descriptions, keep your eyes open and at some point in time you find a match.
|
|
|
|
|
It is not important to use design pattern.Design patterns are used for a specific problem domains.May be you already used one of them but you never know.First you should understand the design pattern then implement it on your code.
|
|
|
|
|
You've got this all backwards. First you need to work out what problems you are trying to solve in your project, and then you can look at design patterns to see if someone has already done a partial solution to some or all of them.
The most common in my experience are simple ones like observer (though not really in C# as delegates and events do all the work for you) and boundary interfaces, which are so simple as to barely count as patterns at all. An MVP or MVVM variant is also very common.
Are those in the seminal 'Gang of Four' design patterns book? I don't know ... and that's the point, a pattern is not part of a gospel truth handed down by the gods of programming, it is advice and a worked example that you can modify to your needs. It doesn't matter if it comes from That Book, or a blog, or a website or a colleague's brain, if it fits the purpose.
|
|
|
|
|
Hi, I have the following issue with my WinForms C# project and wonder if someone could point me to a solution...
I have a reference to a 3rd party DLL (which I am charged for and is licensed on a per end-user basis). The dll allows me to run certain functionality within my project. Ideally I'd like to to check if the Licence file \ DLL exists (I can do this) then if it exists, proceed as normal, but if it doesn't exists, then remove access to the functionality the Dll provides. The issue I have is that I have references in the project to the DLL, so if the licence file is not there or the DLL file is not present, the app explodes on startup. Is there any way I can get around this issue?
Many thanks.
|
|
|
|
|
Good question. I found this article: Loading an Assembly[^]
If that doesn't solve the problem, you can dynamically load the assembly with the Assembly.Load[^] method, and then create objects from it with the Activator.CreateInstance[^] method.
This will allow you to remove the static reference from your project.
Also, see this article about early and late binding: Early and Late Binding[^]
EDIT: I apologize, that article is about VB. But if you search on "Late Binding C#" you'll find good information.
The difficult we do right away...
...the impossible takes slightly longer.
modified 3-Mar-14 15:03pm.
|
|
|
|
|
Richard, many thanks for taking the time to reply. I'll check out the links you kindly posted.
|
|
|
|
|
What I would do is have the functionality declared in an external assembly - the classes I wanted would implement interfaces stored in a DLL or the Exe and I would then use MEF to wire things together. This would allow you to use the interface as your type in the main program.
|
|
|
|
|
MEF? 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
