|
I realized what you were talking about. I simply created a class called AbstractForm, and I inherited the System.Windows.Forms.Form on this one base class. Then I inherited all the other forms off of this base class that I created. Inside this base class I have one method, the setdelegates method.
Thanks for your help,
Ryan
|
|
|
|
|
We are assuming that the browser control creates an interface to whichever browser happens to be installed on the client machine. With the browser control in our Windows Form client, how do I discover the version of the browser that I'm communicating with? We'd like to be able to display that version in our testing tool for test validation. Any help is appreciated!
_____________________________________________
The world is a dangerous place.
Not because of those that do evil,
but because of those who look on and do nothing.
|
|
|
|
|
There can be only one Internet Explorer version installed per OS.
Extracting the version is a matter of either :
- reading the following registry key : HKLM \ SOFTWARE \ Microsoft \ Internet Explorer (System.Microsoft.Win32)
- getting the file version info of <sysdir>\shdocvw.dll (System.Diagnostics.FileVersionInfo)
|
|
|
|
|
My new adventures with C# have brought me to discover the ArgumentException (and derived) classes. They're convenient for raising an exception if a method parameter is not valid.
So now I'm questioning the usefulness of Debug.Assert statements, which I've long used to check method parameters. In other words, whereas before I would use Assert to verify the parameters were in good shape, now I'm thinking that it's better to take a more active and aggressive approach of throwing an ArgumentException if they're not. So I've basically taken out the Assert statements and replaced them with "if parameter is bad, throw new ArgumentException" lines.
In your opinion, is this a better approach? I suppose I could still leave the Debug.Assert statements in there, on top of the exception lines, but it seems like too much extra code. I mean, exceptions do the job always, and once they're caught, I can find out what the problem is -- basically like Assert statements do. So why even bother with the extra Assert statements? See my dilemma?
What approach do you take?
I appreciate your comments,
Alvaro
When birds fly in the right formation, they need only exert half the effort. Even in nature, teamwork results in collective laziness. -- despair.com
|
|
|
|
|
Both of them have their place. In my mind the simplest distinction is that Assertions are used for debugging (for the programmer) and Exceptions are used for graceful error handling (for the end-user). I don't think that a production ready application should ever be causing assertions, though. So, my answer to your question is "use both"--assertions to debug your code and exceptions to handle errors gracefully. 
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
|
Yes, but what about this specific case where I need to verify that method parameters are valid? I've always used assertions to check these, but I've somehow felt that they're not robust enough since they get compiled away in Release mode. Now with these handy new exception classes, it seems like I can kill 2 birds with one stone: verify that parameters are valid, and if not stop the execution to notify myself and maybe the end-user, if the bug slips through the cracks.
I guess a distinction could also be made between different types of code:
1. Code executed directly from an end-user's action, such as a button-click handler.
2. Code exposed publicly by a class library.
3. Code which is internal or private to a class library.
I can see how for the first two types of code exceptions should be used to enforce that the end-users of the software or callers of public methods of a class library do not send invalid parameters. Indeed that's how most (if not all) of the methods in the .NET library work. If a parameter is not valid, an exception is thrown.
However, for the third type of code, assertions seem more appropiate since it's the responsibility of the programmer that the parameters passed to those methods are valid. So the assert statements provide a safety net during the development/test phase.
Well, I guess I've answered my own question then. 
Regards,
Alvaro
When birds fly in the right formation, they need only exert half the effort. Even in nature, teamwork results in collective laziness. -- despair.com
|
|
|
|
|
I have a Stream of bytes from a file, I wish to cast the byte array into various data types eg int doubles etc( no I cannot do this at the file read stage due to the nature and format of the data), but under compilation I either get on the data from the first byte or complier warnings being 'unable to cast byte[] to int'. How can I convert an array of bytes to another data type eg a 2 byte array to an int.
Thanks in advance
|
|
|
|
|
Conversion from a Stream should be a service provided by a Stream-derived class. Watchout MemoryStream, TextReader, StringReader, ...
When your stream cursor has read 4 bytes, use the System.Convert helper class to get an Int32.
|
|
|
|
|
Checkout the MemoryStream and BinaryReader classes.
The MemoryStream class allows you to wrap a byte array in a stream, and then BinaryReader class allows you to read primitives (doubles, floats, ints, etc...) from a stream.
Hope this helps,
Nathan
---------------------------
Hmmm... what's a signature?
|
|
|
|
|
I have a Stream of bytes from a file, I wish to cast the byte array into various data types eg int doubles etc( no I cannot do this at the file read stage due to the nature and format of the data), but under compilation I either get on the data from the first byte or complier warnings being 'unable to cast byte[] to int'. How can I convert an array of bytes to another data type eg a 2 byte array to an int.
Thnaks in advance
|
|
|
|
|
I have a RichTextBox. I'd like to know the current position in this control (line & column). If a have a text with tabs, i need to know the size of each tab
PLEASE HELP ME !!!
Thanks.
|
|
|
|
|
How can I convert a long into a date in C#?
For example the number 37634 is equivalent to 13/01/2003.
In Vb6 I could write:
Dim d As Date<br />
<br />
d = CDate(37634)
and d would then hold 13/01/2003
|
|
|
|
|
There are two ways to achieve this... You can use Convert.ToDateTime(37634) or DateTime.FromOADate(37634).
Chris
|
|
|
|
|
Cheers
|
|
|
|
|
Hi all,
Just want to see if there is much interest for an article on how to save out high quality gif images in C#. I've written some code that saves out an image in gif format (indexes and selected palette colours) with different options for how the colour palette is selected: standard (default .net implementation), web safe, most popular and octree. The octree method is by far the best and fastest with very similar results to photoshop. Let me know and I'll knock something up in the next couple of weeks.
Regards
Andy
-----------------------------
Try my Batch Image Processing Software
Read my DirectX 8 Tutorials
|
|
|
|
|
|
Yes! 
"Do unto others as you would have them do unto you." - Jesus
"An eye for an eye only makes the whole world blind." - Mahatma Gandhi
|
|
|
|
|
I'd be very interested in the article. I'd be especially interested in the implementation details of the octree algorithm.
|
|
|
|
|
I'm a VB developer trying to learn C#. I have a problem. I'm not able to access public methods of one form in other form.
Form frm = new Form2();
frm.Initialize();
It is giving me compile time error
|
|
|
|
|
A few suggestions :
- from the code above, you are creating an object of type Form2, and then store its reference to a variable of type Form. Although this could be ok, it's likely you are misusing the object types. Use this instead : Form2 frm = new Form2().
- to make sure a method can be called from the outside, just add the public attribute on the left of the return type. For instance, public void Initialize() { ... }
|
|
|
|
|
Basically i have created a windows service for the purposes of logging events, exceptions etc to a central database. The windows service gets the objects (ie info object, warning object, excepiton object etc) from a MSMQ queue. Since I wanted to deploy the whole thing a bit easier (in case I needed to move it), I created a web service so that my other apps call the webservice with the message to log, and the webservice takes care of putting the object into the queue which is monitored by the windows service.
Heres my question (finally). What are the rules for objects being deserialized and serialized, with respect to does the assembly doing the serializing need to know of the types it it serializing, or can it just know of the base type etc?
TIA
Andy
He who knows and knows that he knows, is wise; follow him
He who knows and knows not that he knows, is asleep; wake him
He who knows not, and knows that he knows not, is simple; teach him
He whoe knows not and knows not that he knows not, is a fool; kick him
|
|
|
|
|
I have some code that reads from a NetworkStream, retrieving both standard strings as well as binary data. The following code works:
connection_ = new TcpClient(host, port);
connection_.ReceiveTimeout = 30000;
stream_ = connection_.GetStream();
bufStream_ = new BufferedStream(stream_);
reader_ = new StreamReader(stream_, Encoding.GetEncoding("iso-8859-1"));
string str = reader_.ReadLine();
byte b = (byte)bufStream_.ReadByte();
But it's a little weird because the reader goes directly against the network stream for reading full lines as strings, but it goes through the buffered stream when reading individual bytes. Even though this works, I tried the following change:
reader_ = new StreamReader(bufStream_, Encoding.GetEncoding("iso-8859-1"));
But this doesn't work at all. When it gets to the ReadLine, it blocks indefinitely. Could this be a bug in BufferedStream? I'm using .Net 1.0, by the way.
|
|
|
|
|
I got around this problem by writing my own "ReadLine" for the buffered stream, eliminating the need for the StreamReader. Here it is, if you are interested. Please excuse the use of "goto", but it was the most natural (and efficient) way to write the code:
private string ReadLine()
{
StringBuilder sb = new StringBuilder();
byte b;
<BR>
p0:
b = (byte)bufStream_.ReadByte();
if (b != '\r')
{
sb.Append((char)b);
goto p0;
}
<BR>
p1:
b = (byte)bufStream_.ReadByte();
if (b != '\n')
{
sb.Append((char)'\r');
if (b == '\r')
{
goto p1;
}
else
{
sb.Append((char)b);
goto p0;
}
}
<BR>
return sb.ToString();
}
|
|
|
|
|
Is there a preference for Windows Forms programmers between overriding On{EventName} vs. adding an EventHandler for the {EventName} event?
For instance, override OnClick(...) vs. Click += new MouseEventHandler(this.ClickHandler).
Is either way more proper or efficient, etc.? I can understand that in certain cases, it makes sense to override OnPaint if you don't want the base OnPaint handler called, and things like that.
Thanks,
Arun
|
|
|
|
|
Generally speaking, it is better to override the On{EventName} methods first. The first reason is that the On{EventName} method will be called before the corresponding event is fired anyway, and the second reason is that overriding the method is more efficient than intercepting the event. Of course, that advice goes out the window if you aren't deriving from the class that is issuing the event(s). In that case, you will need to intercept the event itself.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
