This isn't a difficult problem if you'd only read the .NET Framework SDK documentation. Type MessageBox.Show in the help index and you'll see all the overloads. Most of your method calls are all wrong. The majority of your errors are because you're using the wrong parameters in the wrong order for MessageBox.Show - this is all documented in the .NET Framework SDK. "Error" 1 isn't even an error - it's a warning. If you're not going to use the exception information, then you don't need to declare an Exception variable. You can do either of the following:
You must read the documentation. Fumbling around blind won't help. Even looking at the documentation displayed in IntelliSense (the drop-down menu that appears when you're coding statements) would tell you what parameters should go where.
Also, in one line you're trying to use the > operator with a string! This doesn't work. If you want to check the length, use txtPassword.Text.Length > 10.
In many of your incorrectly called MessageBox.Show calls, you call it using specific buttons but you never compare the return with a DialogResult! What's the point? If all you're doing is displaying an error to a user, you shouldn't even define which buttons to display because "OK" is the default button. If you actually get the return value and compare it against a DialogResult enumeration, that's a different subject:
DialogResult result = MessageBox.Show("Would you like to retry?", "Prompt",
if (result == DialogResult.Yes)
// Retry code.
It's not that C# doesn't "know" this property, it's that it does not exist. C# is just one of many languages that target the CLR and uses the same assemblies in the same way as any other language can (though some language features - not class members - are not supported by all languages).
In this example you saw, either the author is wrong (like I said, the Zoom property doesn't exist) or he has created his own PrintPreviewDialog class, or he is using the PrintPreviewControl and either named it differently or hosted it in a dialog and is encapsulating the PrintPreviewControl.Zoom property. You could do the same thing.
The PrintPreviewControl does have a Zoom property but you must host this control in your own Form. One final way is to enumerate the PrintPreviewDialog.Controls property and find the PrintPreviewControl that it uses internally and then set the Zoom property on that, like so:
foreach (Control c inthis.printPreviewDialog1.Controls)
if (c is PrintPreviewControl)
((PrintPreviewControl)c).Zoom = 2.0f;
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);