|
structs and any other type that inherits from ValueType lives on the stack, and thus can't be null. ValueTypes are also copied by value instead of by reference, so assigning one System.Drawing.Rectangle to another only copies the values so any further changes to one won't affect the other.
Most struct based datatypes expose a static member named Empty which can be used for comparisons.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Thanks James for the detailed explaination.
:-D This is just me gripping about something that can't be changed now. It is not directed at anyone. :-D
Then they should not allow the use of 'new' to create one. Like in C++ you should have a choice of where you want it to be. Stack or Heap by the use of the keyword 'new' or not. If they are not going to allow you to put the struct on the heap then it should be just like an int and you do not be allowed to use the keyword 'new'.
Don't get me wrong I like C# for somethings, but I think Microsoft's attempts to merge C++ and Java missed the mark in a lot of areas.
I think Java, C#, and C++ have there place in the world and never will any one replace another in it.
Anyway, enough of my gripping  about this stuff...
|
|
|
|
|
Hi Aalst, I have these problems all the time and I went searching for for more info. This is especially in regards to calling unmanaged functions that can either take a null or a struct as a parameter.
Firstly ,if it can be worked around try overloading the function, else define the struct as a class , but with an expilcit layout attribute (sequencial allways). This way the unmanaged function is "tricked" in to believing it is a struct.
Info can be viewed HandleRef Sample[^].
Hope this help 
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info. 
|
|
|
|
|
I wasn't having this problem with unmanaged code, it was with the .NET Framework itself, and the fact that they include structs in it.
However, the first time I tried to use COM InterOp a while back, it required a struct. This created another problem I have with the .NET Framework, how it InterOps with COM. If you add a reference to a COM DLL you only get the classes and interfaces, you do not get any functions, structs or enums. This causes great problems when you have to re-create these structs & enums in C#. First for enums you have to hope they are declared in the Header file (and usually they are) so that you can get the correct values for each member. As for structs, if they are simple data structs then usually no problem. However, when the struct implements a C++ only feature lie "union" you are screwed.
The "union" keyword really should be part of C# it is useful in some situations, and if they are not going to wrap structs and enums in the COM InterOp then they should provide you everything that you need to recreate them.
So the first time I tried to use an unmanaged function the struct it required had a union in it. Which there is NO WAY to recreate this in C#. I know how to simulate a union in C# but it has it's limits and it can not be used with unmanaged code.
Again Microsoft didn't think hard enough on how they were going to implement something, and it causes people problems (usually me).
Also BTW "ms-help://" links are environment dependent. They do not work in IE Directly. They only work in a MS Help utility or application. Like Visual Studio or MSDN Library. So if you see something you like in one of those then you can get it from the ONLINE MSDN library and provide that link.
Sorry for all my gripping, but maybe someone at Microsoft will see it someday and provide fix the problems in a future Service Pack release. (yeah Right!)
Aalst
|
|
|
|
|
Thanx for the insight I do agree, there are some parts that I just like, but I guess they cant make a language perfect for everyone, hence .NET and the ability to write in the language of choice, depending on the situation.
Aalst wrote:
Also BTW "ms-help://" links are environment dependent. They do not work in IE Directly.
Funny, mine does.
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
The simplest solution is instantiate the structure as an object rather than as a structure. You can always use and explicit cast to get it back to a structure.
Only change is constant
|
|
|
|
|
Casting a sturct to an object is to much overhead. I would have to cast it every time it is needed. Thanks for the advice though.
All structs in the .NET Framework seem to have ways around this problem, by providing a static EMPTY member that you use like setting an object to null, and an IsEmpty property for testing against like testing against a null object. Only have to worry about 3rd party structs. I do not create structs in my code, since I do not like them. I use classes not structs.
In my opinion the only useful struct is one that does not have constructors or methods, just public members for use a simple data structure. To do more than this, you should just design it as a class not a struct. Struct's are from pre-OOD, and they should not have been brought into a new OO language. They have reasons for being in C++ for backwards compatibility, but they have no usefulness in C#.
Again this is just more of my ranting about a bad design choice on Microsoft part.
Aalst
|
|
|
|
|
Coming from a pure object oriented background (smalltalk and eiffel) I am very sympathetic to your view. Like you I mostly avoid using structures. When I do create structures I generally employ 'new', and I mostly use them for interop with Windows API's.
Obviously value types were retained for speed optimizations and because the second you drop below the rather spartan GDI+ abstraction you will be making extensive use of structures.
Unfortunately C# is still a hybrid language - for instance, it is not truly polymorphic. And it does not use messaging as its primary medium for communicating between objects. However, the inclusion of the Interface 'pattern' has gone some way towards alleviating the lack of full polymorphism. And it does encourage a rather nice 'published' approach to defining component interfaces. I wish that metadata manipulation were a shade better developed. On the odd occasion I cannot be bothered to write an Interface I end up using the 'is' keyword and casting objects to specific class types. Which is a bit of a bore really.
Studio .NET is really just a two trick pony. C# is the primary language and C++ is retained for those occasions you really must drop down to API level (I use C++ to wrap DirectX API code for instance).
VB.NET is just C# with VB-like syntax. Likewise J#. Except that J# is essentially useless to serious Java programmers because it has no support for VM/Swing. I also mourn losing FoxPro database. But hey, that's life.
Only change is constant
|
|
|
|
|
C# is a hybrid, but they should have left the non-OO stuff just for use with InterOp. They should not have used it in the .NET framework. The other annoying thing is when coding, and I come across a new 'object' that is returned to me from the .NET Framework I do not know if it is a struct, or a object 'object' until I try to do something illegal to one or the other.
When I have to use a struct from the framework I do not use the new keyword any more, so that I know it is a struct. I know that all the books say not to do this that it will be confusing or not look right. Well I say it is less confusing since it show that it is a struct and is a ValueType object, with it's pro's and con's, and should be treated as such.
Why treat one ValueType object different than the others? Should you then use new to create all your int's and float's etc?
I just wish there was a way to tell you are working with a struct when an object hands you one without having to implement any stupid hungarian notation.
It's nice to know that someone else has similar issues, since most of the people responding are more negitive of my comments.
Thanks,
Aalst
|
|
|
|
|
Is there any control like CPropertySheet (in MFC) in C# ?
I want make a wizard like dialog, is there any control can does ?
Thx.
|
|
|
|
|
The closest approximation to a PropertySheet would be a UserControl.
Genghis[^] has a framework for creating Wizards; but I haven't even looked at it so I don't know what it offers.
I do have a wizard framework that I'll make available, but I'm too busy at the moment to find one bug that just makes me cringe in that I have no idea why it is happening.
If anyone feels like bug hunting, I've uploaded the source and a demo of the wizard framework; TSWizard.zip (39.4 Kb). The bug is that the BaseStep.Wizard_OnNextClicked delegate isn't removed from the Wizard's NextClicked event when the back or next buttons are clicked. Oddly I don't have that problem with the BackClicked event and the code is exactly the same (except a few name changes).
[Edit: Oops forgot to add this bit]
I'm posting it now only because I'm going to be very busy writing my first chapter [insert excited emoticon here] and probably won't have a chance to look at it for another week. On top of that I've promised the code for two weeks now 
[/Edit]
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Thx.
And there is a bug. In BaseWizard.cs
internal event EventHandler NextClicked
{
add
{
Events.AddHandler(BaseWizard.nextClicked, value);
}
remove
{
Events.AddHandler(BaseWizard.nextClicked, value);
}
}
the remove must be Events.RemoveHandler(BaseWizard.nextClicked, value);
And it is very good wizard,I like it.;)
|
|
|
|
|
  I can't believe I missed that!
That bug had plagued me for 2 weeks and I went over it at least a hundred times.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
|
|
I don't think everybody can do it.James is one of editors in CP.
Mazy
"If I go crazy then will you still
Call me Superman
If I’m alive and well, will you be
There holding my hand
I’ll keep you by my side with
My superhuman might
Kryptonite"Kryptonite-3 Doors Down
|
|
|
|
|
Mazy is right, its a feature for Editors, Platinum members, and Supporters.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
My application needs to restrict the cursor to a rectangular region. How do I do this?
I've tried using the mousemove event (of the form). When the mouse moves out of the rectange I use SetCursorPos. But this ends up being a mess because the mouse cursor "blinks" (mouse cursor apears in two locations), because it does pass the region and has to be put back in.
Another approach I tried. I used a lowlevel mouse hook. If the mouse went out of the rectangle I would mark the message as handled, keeping the message from going any further. The cursor would be positions on the edge of the rectangle (closest to where the real position would be). But even this approach was flawed because the mouse still "blinked". Appearently the cursor is drawn on the screen before the message gets to my hook.
Is there a way to do this?
|
|
|
|
|
Check out the Cursor.Clip property. I believe this can restrict the cursor to a specific rectangle and it doesn't require any special coding.
The syntax is like this:
Cursor.Clip = new Rectangle(...your retangle dimensions here...)
Does this help?
Alastair
Only change is constant
|
|
|
|
|
|
Luis Alonso Ramos wrote:
The problem is that if a change the server and client to use UDP (and datagrams) an exception is thrown in the server at the Listen call.
UPD datagrams support up to 64 KB messages without fragmentation.
If you want to send a bigger portion simply turn on it
socket.SetSocketOption( SocketOptionLevel.Udp, SocketOptionName.DontFragment, false);
Another case in which an exception could be thrown is that the default buffer is too small to receive such a big datagram. For example, in UdpClient it's set to 8KB.
socket.SetSocketOption( SocketOptionLevel.Udp, SocketOptionName.SendLowWater, 1024 * 128 );
socket.SetSocketOption( SocketOptionLevel.Udp, SocketOptionName.SendBuffer, 1024 * 128 );
43 68 65 65 72 73 2c
4d 69 63 68 61 65 6c
|
|
|
|
|
I tried adding those lines after the creation of the socket, and they throw exceptions (of invalid argument type.)
Anyway, I don't try to send more than 64 KB at a time, it's just a simple 19 byte message.
Any idea why the server will not start listening??
-- LuisR
──────────────
Luis Alonso Ramos
Chihuahua, Mexico
www.luisalonsoramos.com
"Do not worry about your difficulties in mathematics, I assure you that mine are greater." -- Albert Einstein
|
|
|
|
|
Could you give the exception's description and its type. It could help.
43 68 65 65 72 73 2c
4d 69 63 68 61 65 6c
|
|
|
|
|
Yes, this is the exception:
System.Net.Sockets.SocketException: The attempted operation is not supported for
the type of object referenced
at System.Net.Sockets.Socket.Listen(Int32 backlog)
at AsynchronousSocketListener.StartListening() in d:\projects\asyncsock\server\server.cs:line 49 The socket is created like this:
Socket listener = new Socket(AddressFamily.InterNetwork,
SocketType.Dgram, ProtocolType.Udp);Thanks,
-- LuisR
──────────────
Luis Alonso Ramos
Chihuahua, Mexico
www.luisalonsoramos.com
"Do not worry about your difficulties in mathematics, I assure you that mine are greater." -- Albert Einstein
|
|
|
|
|
From what I remember, UDP is a connectionless protocol. Unlike TCP, UDP has no notion of an explicit 'connection' being made to a server socket, which is most likely why this exception is being thrown.
TCP is designed to guaruntee data delivery or to notify the sender and receiver of a delivery failure. In order to do this it keeps alot of state behind the scenes, thus necessitating the 'connection' metaphor.
UDP, however, is much more like IP in that it is a "best effort" delivery protocol. If you send data over UDP, it will most likely get their in good shape. However, it's up to the person reading from the UDP stream to figure out whether or not the data they got has been corrupted.
Long story short - there is no such thing as a 'Connection' or a 'Listen socket' in UDP. If you want to send a data packet via UDP, you specify the data you want to send along with the IP address and port # you want to send it to. You do this for every send() call. Same type of thing with receive() on UDP. You don't connect to a server socket like you would with TCP, you just recv() on a specific port # and wait for someone to send a UDP packet to that port.
My only experience with writing UDP code is in straight C on Unix, so I'm not sure how this would be implemented in the .NET FCL...
--
Russell Morris
"Have you gone mad Frink? Put down that science pole!"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
