|
This might actually be worse as Contains probably iterates over the collection and you're calling it twice.
|
|
|
|
|
This might, even if I didn't test it. Thanks for pointing it out.
Maybe using two HashSet<string> would help ; first, lookups for hash should be quicker ; second, it could be taken profit of Union() and Intersect() methods to build a list of process names to be closed.
But it's just a guess ; and I won't have time to measure gains or losses. Maybe the OP will.
No memory stick has been harmed during establishment of this signature.
|
|
|
|
|
It depends on what the loops are doing. In this case it's unnecessary and phil.o's response is good. But it may still perform similar to what you presented because the Contains may simply do what your inner foreach is doing. I also assume that the lists will be fairly short so it won't matter too much.
If you have long lists, and they are sorted (or can be), then I recommend a different tack, based on Ye Olde Master File Update*...
0) While both lists have items to process:
0.1) Compare the two current items
0.1.1) If they match, process the item, and advance both lists
0.1.2) If the first list's item is less than the second list's item, advance the first list
0.1.3) Otherwise, advance the second list
1) Do stuff with any items left in the first list (you won't need this)
2) Do stuff with any items left in the second list (you won't need this)
This way you only iterate each list at most once.
* The only thing I learned on COBOL class  , but I have needed it many times in my career, including within the last month.
|
|
|
|
|
thanks for the detailed explanation.I solved the problem already but you gave me an idea about future problems. Regards...
|
|
|
|
|
PIEBALDconsult wrote: 0.1.1) If they match, process the item, and advance both lists
0.1.2) If the first list's item is less than the second list's item, advance the first list
0.1.1 assumes a sorting (which you state is required) ... of the two lists ... but also assumes matching of items in each list so that you can be assured for each ith. entry in List 1, the ith. entry in List2 is what you need to compare. If List2, or List1 has 'intermediate,' or 'extra' values, this technique will clearly fail.
0.1.2 implies that the lists' items have some possible form of quantitative comparison possible (in this case using less-than) : this is not relevant to the scenario implied in this thread by the OP.
1, and 2. imply a possible difference in the length of the lists, which you say can be ignored here: but what happens if in the the part of list 2 (which is longer than list1) is an item that matches an item in list1 which you did not find a match for as you progressed sequentially ?
I'm not commenting on this from a 'picky-picky' perspective: I am generally curious as to why you think this 'schema' is broadly useful, or relevant to the OP's scenario, and I'd be even more curious as to how you actually used it recently.
Now that we have Linq, selecting items that match from Lists is a whole lot easier (if more difficult to master ... at least for me).
best, Bill
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
BillWoodruff wrote: assumes a sorting
Yes, both lists must be sorted.
BillWoodruff wrote: for each ith. entry in List 1, the ith. entry in List2 is what you need to
compare
No, when there is no match, only the list with the lower value is advanced.
BillWoodruff wrote: how you actually used it recently.
Given lists of database items (creation scripts of tables, views, procedures, etc.) between dev and prod (for instance), find those which exist in only one environment or whose scripts are not identical. (I may write an article on it.)
See also: http://cs.uni.edu/~east/teaching/cobol/topics/seq_update/algorithms.html[^]
|
|
|
|
|
I agree.
Now if you have an elegant implementation, that would make an interesting Tip/Trick IMO.
BTW: IMO what Bill hinted at is correct, the lists need to be fully sorted; e.g. sorting people on last name only would not guarantee a unique sorting order and then your approach would fail.
modified 31-Oct-11 13:29pm.
|
|
|
|
|
I've been giving that some thought, but, while a generic solution may be devised, I'm not sure how elegant it would be because of the variety of possible data sources (my latest usage uses DataReaders).
I can imagine a MasterFileUpdate<T,U> that requires not only references to two data sources (which may not be the same type), but also a delegate to a Comparer<T,U>, and delegates for advancing the sources. Plus, as with DataReaders (but not with Lists), some data sources will need an initial advance before they can be read.
My concept then, once the Updater is set up and put in motion, would involve the Updater raising events to report its findings as it goes. The calling code would only attach handlers for the events it needs.
... on further thought I think there would need to be four generic parameters, not two  .
It's still an interesting exercise and perhaps I'll get right on it.
Edit: I have it roughed in, but not tested. It may not be too bad after all.
Edit: Tested it with List<int>s -- it seems to work. I need to refactor it into a recent app and test it further.
modified 2-Nov-11 21:35pm.
|
|
|
|
|
This response is an "aside:" it is not an answer to the OP's question, but a comment on the scenario, and a corollary question the question and answers raised ... for me.
Looks like you got what you need from the answers here, and, after all, your original code works.
But, I am surprised that this code did not run into the issue of a collection which is self-modified during a foreach, or for, loop, throwing a compile error.
A problem which I've worked around in the past by using Linq to cast an existing collection to a List<whatever>, and then enumerating that generated collection which can be modified/deleted/whatever without causing an error, a trick I learned somewhere on StackOverFlow.
But, I guess the 'simpler' structure of Array, by definition, cannot have this problem.
best, Bill
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
modified 31-Oct-11 1:20am.
|
|
|
|
|
both the array and the queue contain snapshots, i.e. they are views on the recent past; they don't get affected by changing the present, so there is no issue using them in a foreach.
|
|
|
|
|
BillWoodruff wrote: But, I am surprised that this code did not run into the issue of a collection
which is self-modified during a foreach, or for, loop, throwing a compile
error.
There's no reason it would. The OP is not actually attempting to modify the list, rather he is acting on an item of the list which represents a snapshot. If he attempted to remove the item from the list, he would hit exactly the issue you describe.
|
|
|
|
|
The area of an MDI container window is covered by an MdiClient control; consequently, Form.BackColor and Form.BackgroundImage are ineffective. So How to set the background for this form.
|
|
|
|
|
I would think you need to do P/Invoke for that...
Philippe Mori
|
|
|
|
|
You could, but it's worthess and will slow down your applications rendering speed.
Again, you can't do it as design time. You have to do it at runtime.
Again, you have to enumerate through the MdiParent Controls collection. Once you find the MdiClient control, you can set its BackgroundImage property to whatever you want.
|
|
|
|
|
+5 Right on target, Dave, and you reminded me of when ... several years ago ... I did some stuff with MDI (yuck), and I went back today, and took a look at the MdiClient component that is created when you set a Form's IsMdiContainer Property = true.
The WinForms designers, probably having a bad hair day, set the Text and Name properties of MdiClient to an empty string, which means you can't do something like this to find it:
private MdiClient theMDIClientControl;
Control[] potentialMDIClientControls = this.Controls.Find("MdiClient", false);
if (potentialMDIClientControls.Length > 0) theMDIClientControl = potentialMDIClientControls[0] as MdiClient;So, as you said, you gotta iterate/enumerate over the Controls collection of the Form.
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
Very true. I found the lack of a name a little annoying at first, but I now prefer to find it by type. You really can't change the type at all, but the name can be changed breaking existing code.
|
|
|
|
|
If your question means you want a solution where there is one MDI container Form with a background image, and all the Forms on it ... interpreting "client" to meaning an 'mdi child form:' someForm.MdiParent = MDIContainerForm ... show a background as if they were 'transparent,' and you were seeing the portion of the MDIContainerForm's background their current bounding-box covers ...
You are in for some deep-plumbing, and as others comment here, it ain't worth it.
Now if the MDI container form just has a background that's a texture, then it's easy, but I'm pretty sure you are asking about the container form having a background picture, not a texture.
However, if you have the option of not using the MDI architecture, there are some ways you can 'simulate' the effect of contained Forms having the same background image. You make them transparent, and you "do the right thing" so that at run-time they remain in the boundary of the intended container control.
If you wish to hear about the specifics of this alternative, just ask.
best, Bill
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
You can set the background by casting the type to MDIClient and setting the MDIClient background. EXAMPLE:
private void Form1_Load(object sender, EventArgs e)
{
MdiClient ctlMDI;
foreach (Control ctl in this.Controls)
{
try
{
ctlMDI = (MdiClient)ctl;
ctlMDI.BackColor = Color.White;
}
catch (InvalidCastException exc)
{
}
}
}
|
|
|
|
|
Alisaunder wrote: try
{
ctlMDI = (MdiClient)ctl;
That is so ugly. I suggest you read up on the is and as keywords.
|
|
|
|
|
Not to mention using a try/catch to find the correct control is slow as exceptions are expensive objects to create.
Exceptions should be used to handle exceptional cases, not used in main logic.
A much better and faster implementation would have been to check the type of the control first, then cast it to an MdiClient if appropriate.
|
|
|
|
|
|
I don't care. Those examples are not there to demo best practices. Those examples are not considered "production-level" code.
|
|
|
|
|
I'm so glad your opinion isn't all that matters then.
|
|
|
|
|
I'm not the only one telling you the practice sucks...
|
|
|
|
|
And yet neither of you are displaying an alternative that is better?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
