This incorrect behavior doesn't surprise me. You are, after all, accessing this control in a way that wasn't intended (otherwise it won't be exposed as a property of PrintPreviewDialog, or at least some of its properties like Zoom would). Unfortunately, there doesn't appear to be an easy way to correct this problem. When the Zoom property is changed, and event isn't even fired so you'd have to keep the values in sync yourself!
The only way I can think of is to get the ComboBox using the same enumerative code I gave you for the control, and update it when you programmatically change the Zoom. You can use ildasm.exe (the IL disassembler) that comes with the .NET Framework SDK to figure out in what Controls collection the ComboBox is added. If you can't read IL (and it wouldn't hurt to learn - it definitely can help you understand how to write more efficient code at the very least), you can use a good decompiler like .NET Reflector[^].
I want to (de)serialize a SortedList that contains a couple of "complex" objects.
Each of those objects in the list contains two attributes that are references
to another objects (they are also stored and (de)serialized in a SortedList).
Here's the problem: All references work fine until I serialize and deserialize
the data. I compared the deserialized reference with the object it should link
to and they are not the same. Before deserialization they are the same.
It seems that not the references are serialized but copies of the objects where
the references point to. That perhaps makes sense to me cause references are
similar to adresses. And adresses surely can change while (de)serialization.
So I guess after deserialization I have two separate (but equal) objects
and not one object and a reference to it.
Is it anyhow possible to (de)serialize object references correctly?
Many thanks in advance!
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.