You are correct - references are address, but in the case of the .NET Framework it manages these objects in memory. Since memory address shouldn't be serialized (because the .NET Framework can move these around at any time, which is why the fixed statement is needed to work with unsafe memory addresses in C#), you need a serialization manager that can fix-up these objects. With .NET Remoting, the remoting infrastructure does this automatically when marshaling data types across AppDomains. Many programs use serialization to save state and exist, restoring that state when the program restarts so such hooks-up aren't needed.
You should read through the Serializing Objects[^] section in the .NET Framework if you haven't already. It should cover a few of these things.
It's also possible that some things in your list aren't serializable (to be serializable, objects must be attributed with the SerializableAttribute and can optionally implement ISerializable to control serialization). Some properties of the list (or any other object) might also be non-serializable. What exactly differs between the two lists?
Some properties of the list (or any other object) might also be non-serializable. What exactly differs between the two lists?
The structure of the lists looks like that:
ClassA (objects are stored in SortedListA)
| |----> reference to object of ClassB (objects are stored in SortedListB)
|--------> reference to object of ClassC (objects are stored in SortedListC)
All classes contain only simple data types like strings, uints, floats, etc. Furthermore ClassA contains, as you can see in my amazing ASCII-diagram , a reference to an object of ClassB and a reference to an object of ClassC. Nothing more. So I think everything should be serializable.
As I said in my first post, everything works fine until deserialization. Then the references seem to be independent objects. I can't manipulate the referenced objects through the reference. So perhaps the framework notices that I want to serialize a reference and since this is not possible cause addresses are shifting, the framework serializes just a copy of the referenced object.
But because of these limitations I would prefer at least a warning while compiling or an exception at runtime...
Which serialization are you using? The System.Runtime.Serialization namespace elements or the System.Xml.Serialization namespace elements? The former does serialize references (as I mentioned before) but requires something to associate them with the original object. Since you don't have such a serialization manager, a copy of the class is deserialized, yes. There is not way to get an existing reference back since memory address shouldn't be stored (isn't durable), only to associate the data with existing objects. If you don't have something that will do that, all that can be returned is a copy of the class.
Again, read the link I sent you for more information.
Thnxs for your answer, I got it to change every 3rd row. But now there is a different problem, the instant i scroll down on the datagrid the colors get messed up or changes to one color. Do you know what this problem could be?
You need to use a DataAdapter (for this, I'll assume a SqlDataAdapter and related classes) with SelectCommand, InsertCommand, UpdateCommand, and DeleteCommand properties assigned. If you use a simple SELECT query (i.e., no JOINs or nested SELECTs) you can use a SqlCommandBuilder to generate the other 3 SqlCommand properties from the SqlCommand for the SqlDataAdapter.SelectCommand property. These commands must also be parameterized.
You can also use the VS.NET designers to create the SqlDataAdapter and all the SqlCommands for you. You can drag a DataSet (which can be strongly-typed) or SqlDataAdapter from the "Data" tab of your toolbox when a component is open in the designer. Play around with this, though I recommend you examine the code that is generated in the source file to understand what it going on.
is it possible to implement a drag & drop interface in C#. And if so can anyone point me to a tutorial or give me some tips. I need to be able to drap an item from a list box and drop it on a button which will envoke the click action of the button on the item dragged from the list box. Any takers? ,
See the Control.DoDragDrop method for information and an example.
Basically, you pack information into an IDataObject impementation (like the DataObject class provided in the base class library) and identity it with a simple string known as a clipboard format (this is covered in more details in the Platform SDK, though THAT IDataObject is different, but the concepts are the same). Handle the DragOver and DragDrop events on your button such that you check for the existence of this clipboard format:
privatevoid button_DragOver(object sender, DragEventArgs e)
// You can use any DragDropEffects that you want.if (e.Data.GetDataPresent("MyCustomFormat") &&
(e.AllowedEffect & DragDropEffects.Link) != 0)
e.Effect = DragDropEffects.Link;
privatevoid button_DragDrop(object sender, DragEventArgs e)
if ((e.AllowedEffect & DragDropEffects.Link) != 0)
object o = e.Data.GetData("MyCustomFormat");
if (o != null)
// Store the object for the Click event handler.this.currentListItem = o;
// Just call the Click event handler.this.button_Click(sender, EventArgs.Empty);
First of all, you shouldn't serialize the Socket itself, but perhaps information about the socket. To be serializable, a class (the class you instantiate, not any base classes) must be attributed with SerializableAttribute. If you want to control serialization, implement the ISerializable interface. See the documentation for the ISerializable interface in the .NET Framework SDK for more information, such as implementing the special constructor used for deserializing information. By implementing this interface, you could just serializing certain properties about the socket. See Serializing Objects[^] in MSDN for more information.
Second, you should take a look at .NET Remoting. It is the de facto way in .NET to talk to different AppDomains (contexts in which applications run, which obviously your client and server are in different contexts). It takes care serialization (so long as you follow the same serialization rules I mentioned above) and transportation across TCP, HTTP, or any custom transport channel using SOAP, binary, or any custom serialization formatter you want. See .NET Remoting Overview[^] for more information about remoting.
I need to download HTML pages from a website. These pages require username/password access which I DO have. The problem is, the website sets a persistent cookie in my Cookies folder and it's encrypted, so I can't read it's content.
How can I automate the download of these pages but not through internet explorer? In other words, how can I make WebClient/HttpWebRequest read the persistent cookie in my local folder?
If I can't do that, then how do I do it?!
"A good friend, is like a good book: the inside is better than the cover..."
First of all, the cookie should NOT have the password contained within it. This is very insecure. The web site should authenticate the credentials in whatever way is fit (say, BASIC authentication of HTTPS) and return a ticket that signifies that the credentials have been authenticated. This is the underlying concept of authentication.
Second, if you have the username and password, you could make the call to the web server to get the ticket and that should return you the cookie. In order to accept the cookie, though, your HttpWebRequest.CookieContainer must be initialized:
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://www.codeproject.com");
request.CookieContainer = new CookieContainer();
// Add cookies if necessary and make request
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
This example if very basic, but you can find more information in the documentation for HttpWebRequest.CookieContainer.
Additionally, you can also pass the username and password to the initial request to avoid making several requests. You'll still need the initialized CookieContainer to store the response cookies (and use that over for every request and response), but you can put the username, password, and domain in a NetworkCredential and assign that to the HttpWebRequest.Credentials property before getting the response (which commits the request). See the documentation for the HttpWebRequest.Credentials property in the .NET Framework SDK for more information.
It retrieves certain completed auctions from eBay.
This URL however, results in a page that says: you have to sign in. I get the source of this page, I see that it gets a posting (username/password) from you, and redirects you to the original page you were requesting. I post this data, it gives me a Redirect Error, although I have HttpWebRequest.AllowAutoRedirect set to true. I also tried KeepAlive = true/false. No luck.
So, I try posting my username/password to http://signin.ebay.com/aw-cgi/eBayISAPI.dll which is the sign in page, and getting the cookies returned. It gives me a Cookie Error page, where it says my browser cannot accept cookies, although I did set CookieContainer of my HttpWebRequest.
What can I do?!!! If anyone wants to try:
username = booksbysammy
password = stupiddog
Thank you very much.
"A good friend, is like a good book: the inside is better than the cover..."
Okay, there's a few things I have to mention. When using form-based authentication, the HttpWebRequest.Credentials won't suffice. You either have to POST or GET data to the form action as you've discovered. I just wanted to mention this to be clear.
The problem looks like it doesn't recognize your user agent (the browser name and info). Fortunately, you can trick into thinking another browser is making a request (i.e., one that supports cookies) by the HttpWebRequest.UserAgent to something like "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" and it will think Internet Explorer 6.0 on Windows XP is making the request. This error might be making such assumptions because it's quicker than setting a cookie and checking for it in the next request (which requires making a request and getting a response twice). It's worth a try.