|
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 DataReader s).
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 DataReader s (but not with List s), 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?
|
|
|
|
|
I'm not in the spoon feeding business, I did provide the two keywords that exist for dealing elegantly with such situations. So if you want to learn something, look them up and read the reference material.
|
|
|
|
|
So sorry you don't feel like trying to answer the ops question with something less cryptic. Seems forums just aren't as helpful as they used to be. Since you feel you are such an expert that you you don't need to provide examples my opinion, for what it's worth is that you are no help at all and shouldn't even be posting.
|
|
|
|
|
Yeah, right. A couple of Code Project MVP's aren't very helpful at all. The pile of 5-voted responses to questions just doesn't offer up any evidence at all of us being helpful.
I'm not in the spoon-feed business either. There are just WAY too many very basic concept questions being asked that are very easily answered simply by typing the question into Google.
I'd rather have someone learn how to do research themselves than just keep asking question after question about very basic topics.
|
|
|
|
|
Actually Most everyone I know searches for the answers before hitting a forum with a question. Personally in my opinion it's more professional to offer assistance with a basic code example in the hopes the op learns something in the process. All anyone is learning from your responses is not to ask you for help.
|
|
|
|