|
How have you attached the database to your tree view control?
You can add an event handler to the tree view to intercept when the currently selected node has changed. Then, depending on how you've got things set up, you could possibly:
#1 - Look up the required data from the database by the ID associated with a tree view node.
#2 - Extract the information from the selected tree view node.
Don't forget that you can use the 'Tag' property of tree view nodes, so you could associate your data using the Tag property. Then it is very easy to access your information. In your selected node changed event handler you can simply populate your list view from the associated 'Tag' property, or even acquire additional information from your data source using the information provided by the 'Tag' property.
I hope that I have understood you correctly, and that this is of some use. 
Best regards,
Lea Hayes
|
|
|
|
|
Afternoon everyone. Crap weather we're having today...
Now then, what's going on here?
using System;
namespace Confusion
{
public delegate void ThingDelegate();
public abstract class A
{
public virtual void Thing()
{
Console.WriteLine("A::Thing");
}
}
public class B : A
{
public override void Thing()
{
Console.WriteLine("B::Thing");
ThingDelegate del = base.Thing;
del.Invoke();
}
}
public class C : A
{
public override void Thing()
{
Console.WriteLine("C::Thing");
ThingDelegate del = base.Thing;
del.BeginInvoke(null, null);
}
}
class Program
{
static void Main(string[] args)
{
B b = new B();
b.Thing();
Console.ReadLine();
C c = new C();
c.Thing();
Console.ReadLine();
}
}
}
If you run this simple console application what's the output? If you're as dim as me, you'd expect:
B::Thing
A::Thing
C::Thing
A::Thing
What you actually get is:
B::Thing
A::Thing
C::Thing
C::Thing
C::Thing
...
... to infinity and beyond.
eg. Invoke and BeginInvoke resolve to different methods. Can anyone explain why?
Regards,
Rob Philpott.
|
|
|
|
|
BeginInvoke uses the thread pool. Invoke is the same as calling del();
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
Agreed, but that doesn't explain the disparity between the two.
Regards,
Rob Philpott.
|
|
|
|
|
Which one is not being called? Right special code to see if it is the invoke or Begin invoke that is not firing. The easiest way is to specify a callback method. And then you can determine why you do not get two A's in the output.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
I tried your code and it effectively seems that Invoke and BeginInvoke behave differently. Invoke seems to take the address of the base's method, while BeginInvoke seems to take the address of the child's method, hence the infinite loop. Probably something to do with threading.
Well, good catch. Now, you will know in what circumstance not to use BeginInvoke.
Btw, I don't know in which context you wanted to use this, but you probably should review your design.
|
|
|
|
|
Thanks for the reply!
Review the design? I'd quite agree but I'm trying to fix an infinite loop bug in someone elses code. Personally I'd steer clear of anything with a complicated parent/child relationship and asynch processing but that's what I've got.
Regards,
Rob Philpott.
|
|
|
|
|
This puzzled me, so I decided to do some digging to figure out what was happening. Just to warn you thought, I still haven't got a clue what is going on, but I thought I'd share what I looked at with you, maybe you'll spot something I missed.
First thing I tried was looking at the compiled assemblies in reflector.
B:
ThingDelegate del = new ThingDelegate(this.Thing);
del();
C:
new ThingDelegate(this.Thing).BeginInvoke(null, null);
As you can see, they are slightly different. In both cases, the delegate assignment is expanded to use the constructor. (Obviously, the assignment you are doing is just short hand for calling the constructor). What's odd though is that with B, the variable 'del' is kept, but with C, the compiler removes the variable and just calls BeginInvoke directly after creating the delegate. This could just be an artefact of the way reflector rebuilds the code though, we'll have to look at the IL to see.
You can also notice that in both cases, your reference to base.Thing is changed to this.Thing. Which I find a bit strange. To me, this implies that both calls should behave like C, and go into infinite recursion.
Next I took a look with ILDasm
B:
IL_000c: ldarg.0
IL_000d: ldftn instance void Confusion.A::Thing()
IL_0013: newobj instance void Confusion.ThingDelegate::.ctor(object,
native int)
IL_0018: stloc.0
IL_0019: ldloc.0
IL_001a: callvirt instance void Confusion.ThingDelegate::Invoke()
IL_001f: nop
IL_0020: ret
C:
IL_000c: ldarg.0
IL_000d: ldftn instance void Confusion.A::Thing()
IL_0013: newobj instance void Confusion.ThingDelegate::.ctor(object,
native int)
IL_0018: stloc.0
IL_0019: ldloc.0
IL_001a: ldnull
IL_001b: ldnull
IL_001c: callvirt instance class [mscorlib]System.IAsyncResult
Confusion.ThingDelegate::BeginInvoke(class
mscorlib]System.AsyncCallback, object)
IL_0021: pop
IL_0022: ret
Ok, so what's the difference here. The both start with ldarg.0 instruction. This basically pushes the "this" pointer for the current object onto the stack. Then they both do a ldftn which pushes an unmanaged pointer to the method A.Thing() onto the stack (as a native int).
Next they both call the delegate constructor. Which uses the 'this' pointer and A.Thing() pointers that we just pushed (The object and the native int in the brackets)
The next two lines (stloc.0 and ldloc0) basically pop the newly created ThingDelegate off of the stack an into storage index 0, then back onto the stack again ready to be used.
C then has 2 calls to ldnull which simply loads a null pointer onto the stack (for you two null passes to BeginInvoke).
The next line (callvirt) is the call to either Invoke or BeginInvoke. As you can see, we've created the ThingDelegate exactly the same way, and the calls are exactly the same.
finally, C has a pop command to get the IAsyncResult return object off of the stack (and B just does a no-operation), then both return nothing (ret).
Ok, so what's the difference? Nothing as far as I can tell.
Both have been compiled in exactly the same way. Both have created the ThingDelegate using a pointer to this and the A.Thing() method.
The only difference is that one calls Invoke and the other calls BeginInvoke.
My next step was to look at the ThingDelegate itself. In reflector you can see that it extends from System.MulticastDelegate. Basically it declares virtual methods BeginInvoke, EndInvoke and Invoke. You can see exactly the same if you look at the IL.
So where does this leave us? I'm still confused. It seems that the runtime handles the Invoke and BeginInvoke calls. I've used reflector on the MulticastDelegate type and it doesn't even have Invoke or BeginInvoke methods, they are only defined in the ThingDelegate type. I would assume that somehow the call is ultimately directed to the DynamicInvoke method on the base Delegate type, but I've no idea how that happens, or why it's different for the two types of invoke.
I'm totally confused by this. If you ever work it out, please let me know.
Good luck.
Simon
|
|
|
|
|
Wow, that's some digging. Thanks for the reply.
I've sort of concluded the following, but it may all be wrong.
The Invoke method effectively just calls the method on the same thread so could be replaced with base.Thing(), which calls the base class just as you'd expect.
BeginInvoke though on an instance delegate having a 'this' pointer referring to the child class seems to be activating the polymorphic mechanism and determining that Thing() is overriden and using the override instead. It's kind of valid.
So I guess the difference is that Invoke just calls a method, but BeginInvoke will call the method or preferentially any override. It is an odd one though, because one naturally assumes they'd call the same method ultimately.
Thanks again for your help.
Regards,
Rob Philpott.
|
|
|
|
|
Guys,
I am taking some classes and I am trying to do assignm,ent in c#. I have a question. I have the asignment that must use the LInked Lists so I was wondering if c# has any think like Linked Lists in C++? Please advice and I will greately appreciate your comments.
Thank you and God bless you all for wonderful help!
|
|
|
|
|
Yeah, umm....surprise surprise, it's called LinkedList[^]
It's a generic so you can use it with whatever type you want.
Simon
|
|
|
|
|
There's a LinkedList class in .NET 2.0.
Kevin
|
|
|
|
|
There is such thing called Google that let's you to search. Have you tried it? There is also MSDN too.
|
|
|
|
|
sorry, but if google had it all, this forum will no longer be needed. google searches forums like this. If you have no answer to it better not to response. Noone is born nice and kind but kindness can be earned. Respect yourself and respect others.
|
|
|
|
|
nesfrank wrote: sorry, but if google had it all, this forum will no longer be needed.
I agree, Google does not have everything but it does have much information. You use documentation and books to learn about something and post on forum if you can't need to clarify some points or need more help.
nesfrank wrote: Respect yourself and respect others.
So why don't you respect us and do basic search and read documentation? Most of the questions asked at this forum can be answered by reading documentation and doing simple search. I guess some people are too lazy to do that.
|
|
|
|
|
thanks anyway. I appreacute any answer
|
|
|
|
|
But when the 4th hit for "C# linked list" is an article that shows why the generic linked list (at the end of the article) is better than a DIY list, and the 2nd hit for "C# linkedlist" is a howto on the ArrayList<> generic, posting a question like this shows you haven't put any effort into it.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
I do put efforts but I have limited english. all are different. I appreaciate any response but I don't appreciate offense
|
|
|
|
|
Hi!
I have a stdcall-DLL, that works as an API and offers me connection to a hardware-device using "open"/"close"-methodes, as well a "read"/"write"-methodes for accessing the device. These API-calls are wrapped by a C#-DLL, that encapsules the calls an offers some methods i need to use in my application.
The API´s "open"-method delivers a handle, that is used with the other functions to access the device.
This handle is stored in a private class-member for further use with the read-methodes.
My application/wrapper-DLL opens the connection, then reads something from the device everytime an external signal arrives at my software. When starting my app everything works fine for some hours or days, until nothing can be read from the DLL and an error occurs ssaying "invalid handle".
When trying to re-connect the device (API-calls "close" and "connect") the API tells me that the connection is already open and i cannot connect to the device. After restarting my software everything works fine again.
Because of this behaviour i changed the operation of my software:
Now the device is re-connected everytime i finished a read-operation.
This is because i thought that maybe the API might have a problem with a long-term connection.
Unfortunately i get the same problem again: After some hours/days i get an "invalid handle" again.
As the application should run 24/7 i need a way to stabilize this connection to the device.
Does anyone have an idea, where my problem might be?
Thanx a lot
Greetings
JH
|
|
|
|
|
I'm using VS 2008. How can I enable/disable ToolBar buttons please?
|
|
|
|
|
|
Hi all,
If I try and set some of the properties of a textbox for example, within the thread I receive the following error: cross-thread operation not valid. I understand why this is happening so my question ...
I would like to know if there is another way of setting / getting form control properties within a thread instead of making use of the BeginInvoke() method.
I.e:
public delegate void InvokeDelegate();
private void Invoke_Click(object sender, EventArgs e)
{
myTextBox.BeginInvoke(new InvokeDelegate(InvokeMethod));
}
public void InvokeMethod()
{
myTextBox.Text = "Executed the given delegate";
}
Many thanks in advance
Kind regards,
The only programmers that are better those C# programmers are those who code in 1's and 0's ![Green Alien | [Alien]](https://www.codeproject.com/script/Forums/Images/alien.gif) |
Programm3r
My Blog: ^_^
|
|
|
|
|
|
|
Glad to help you 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
who else but the legend Sacha Barber 
![Green Alien | [Alien]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/alien.gif)