i am not sure, i think i tried that way but it didnt work for me, i needed to sign the data from the hash with the signature formatter cause it will encode it too. Try if u can do it that way, but i think the sign data didnt do the same as the signatureformatter

Look into the BCP command line utility. Michael I firmly believe that any man's finest hour, the greatest fulfillment of all that he holds dear, is that moment when he has worked his heart out in a good cause and lies exhausted on the field of battle - victorious. Vince Lombardi (1913-1970)

I'm trying to connect from the VS IDE. I own both the server and the client, and I see no problem on both. Can you reffer me to a relevant artical? Thanks, Yaakov

Thanks. Yaakov.

Thanks. I have added a suggestion in the Feedback Center. Yaakov

class Class1 { class Foo : Attribute {} [return:Foo] static void Main(string[] args) {} } :-> top secret Download xacc-ide 0.0.3 now! See some screenshots

What exactly are you asking? Do you need to store a reference to a delegate in order to remove it from a event later? If so, the answer is "no". So long as the delegate references the same method for the same instance of a class that is already added to an event (which is a MulticastDelegate), you can "new" up another one like so: textBox1.TextChanged += new EventHandler(textBox1_TextChanged);   // Later that day...   textBox1.TextChanged -= new EventHandler(textBox1_TextChanged); A delegate is like a managed function pointer. So long as the function pointer (the method to which the delegate points) is the same - the same method on the same instance or a static method for a class - the delegate is the same. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]

What I had seen when I was using MC++ was that if I had a COM object that was used inside of a managed object, the memory and the COM object would be cleaned up but only after the application exited, not when the managed object went away. We had to call a function to delete the COM object when we wanted to when the managed object was disposed. Not sure if it would be the same for you, but you could always turn that unmanaged struct into a class and put some code into the destructor to see when it gets called. Steve Maier, MCSD MCAD

I don't use MC++, but the operator signatures for operator[] in most flavors of C++ is typically as follows: // return element for read/write T& operator[](int index); // return element for read-only const T& operator[](int index) const; Hope that was what you were looking for.

I did some checks, and I got the following: foo(null) won't compile, but foo((someRefType)null), and foo(someRefInstance) will both call foo(someRefType o). I wonder if it will be the same in the next version of .Net. Yaakov

Nice! I didnt know that one. But I wonder if it is good style to declare more than one variable on one line. Most coding styles would forbid it.

You're right. the readonly variables has to be initialized in the constructor, and no threads can change them. Problems in multithreaded environments starts, when a thread assumes something about a variable, that can be changed in between line x and line y by another thread. "After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus

You could take a look at the System Event Log. The entries from the eventlog service tell a lot about when a system starts and shuts down... Wout Louwers

TyronX, yous second suggestion did answered my question. thanks a lot. BTW, the first one isn't correct. leppie, Your suggestion could also fit in another constraints, but thanks for the new information.

Thanks for your detailed answer. Yaakov

Interesting. But I have no clue how you're going to access the .DLL inside the assembly. Also, if your .DLL is a COM component and must be registered, I have no idea how you're going to get that accomplished while it's sitting inside a .NET assembly. It's just never been a requirement for me. If someone is going to do something malicious with my code, they're going to succeed weather I want them to or not. It's just up to that persons determination. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome