First, let me advocate that a well-known client Type can't be well-known if you change its URI.
That being said, you can use RemotingServices.Disconnect. If you have a reference to the registered object, just pass it to the static Disconnect method. If you don't have an instance of it available, you can get one using other methods of the RemotingServices class.
Registering it with another URI is as simple as what you've already done.
Another way is to simply shut down the .NET Remoting host, such as a Windows Service, IIS, or some other program, but that's most likely not what you want in this case.
Thanks for your effort!
Unfortunately doesn't work it...
I want to explain the situation more detailed:
When the client starts his application, he get's a login-dialog, where he has to type in the servername (and username, password ....) he wants to connect to. When the client types in a servername, that does not exist or the server is not available, he must get a new chance to login, without restarting his application.
When he clicks the Login-Button I do something like this:
If an error occures (severname incorrect or server not available) I have to unregister this Dispather-object first, before I can register it again with another URL. RemotingServices.Disconnect(Dispatcher) does not work, because it's for Serverobjects. And Reregistering (with RegisterWellKnownClient) throws an exception ("System.Runtime.Remoting.RemotingException: Es wurde versucht, die bereits umgeleitete Aktivierung des Typs 'Dispatcher, ccShared' erneut umzuleiten.").
Hi, I'm seeking a way to emulate "Send To" function.
I just need to pass a file to .MAPIMail (it can pass a file to the default mua). .MAPIMail is normally located in C:\Documents and Settings\Default User\SendTo\ but doesn't have to use them. Simply prepare a file named like firstname.lastname@example.org.MAPIMail (zero-byte) and drop a file with explorer. It'll attache the file to the default mua.
If anyone knows about this, please let me know. I'm willing run the default e-mail client and a file attached.
I want Send To function for one of my C# projects too and in that time I couldn't find a .NET way for it, so I wrote a Shell Extension which do some task for my SEND TO function and register it with my application. But as I'm thinking now , those steps are doable in .NET too(not sure). This[^] article show you the VC6 way. If you couldn't translate it to .NET at least you can make that dll in VC6 which handle your job.
This should work, but you can also get the edit control (a TextBox in .NET) that the Tree-View common control uses during label edits by handling the TVN_BEGINLABELEDIT notification message in TreeView.WndProc and then call a P/Invoked SendMessage with the TVM_GETEDITCONTROL:
Why not just read this into a string, or better yet a StringBuilder (which is mutable). If you store the reference to this StringBuilder you can keep appending to it. Just use StringBuilder.ToString() to get the actual String.
Another way would be to use a MemoryStream and wrap your StreamWriter or StreamReader around it.
One unrelated thing to your question: instead of concatenating strings that represents directories, you should use Path.Combine to take into account the OS's path separator (\, :, /) and to ensure that - if the WorkingDir doesn't not end with a path separator - that it is added before appending the filename (or additional directory name(s)).
bouli wrote: 1) What is the equivalent of Win32 GetSysColor() function in .NET?
It is System.Drawing.SystemColors class
bouli wrote: 2) I would like to have the equivalent in C# (.NET) of the following C++ (MFC) statement:
class CMyWindow : public CWnd
While CWnd is an MFC class that represents a basic window.
I want to write my own control and use it
Use System.Windows.Forms.Form for forms(dialogs). But for controls like button, user-controls use System.Windows.Forms.UserControl or Control. Here big difference between MFC and .NET. In MFC can be CWnd dialog and control(I used these for nested dialogs - one dialog owns another), but in .NET only classes delivered from System.Windows.Forms.Form can be dialogs and cannot contain any forms.