Ah, I see.
The problem is that when you use Form.Show(), it creates a global form, not a child form.
You either need to set the Parent property manually (which will also put the second form "into" the first form visually) or create a modal form using Form.ShowDialog().
What happens now when version 2.0 tries to read files written using version 1.0 is that an exception is thrown. What is the most elegant way to handle this? Am I forced to implement ISerializable and do all member serialization myself?
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
To upgrade a serialized document, extend SerializationBinder and override BindToType to bind one version of a Type (passed as a string so you don't have to load older assemblies) to the new Type in your assemblies. See the documentation for the SerializationBinder for more information. You assign this to the IFormatter.Binder property of your formatter, like the SoapFormatter, before deserializing.
On that note, if you're serializing Types for .NET Remoting, you can set the includeVersions to false (either via the .config or the Properties for the formatter sink) so that versions aren't included when serializing an object graph to send across application boundaries.
There was a discussion not long ago about GDI+ squishing characters together at the end of a sentance when NoWrap was used (or a couple other conditions were true). This lead to a topic on MSDN about why it does that and the proper StringFormat to use to eliminate that (StringFormat.GenericTypographic). Try to use the same flags as that if possible.
As far as spaces appearing between letters, this is fairly odd. I've never seen this when drawing my own strings and have never seen anything documented to even control this. Either the text you're passing has spaces (inproper Unicode string?) or the font you're using has some issues. Try a different one and see.
The latest programs use only one process for several application instances. An example is Microsoft Word. When you run it for the first time it creates a process and an empty document. When you run the executable for the second time (while first instance still running) then it doesn’t create a new process. It tells somehow to the first process to create just a new empty document. In this manner the program uses lower resources. How to implement it under .NET?
Is there some reading on how to organize the initial ideas, for a fairly large software (a graphics software, estimated to take about six months). I feel at loss, not having a computer science background.
Just a thought: Look for information on the Microsoft Solution Framework: Envisioning phase / Conceptual Design / Logical Design / Physical Design / Developement / Test / Deploy.
MS Exam 70-300 covers this also. (So one of the study guides for that exam could help out - I do NOT recommend the MS Press book for that exam, it is very dry reading and I felt that my major intestine was about to jump into my throat and strangle me in order to prevent me going insane with boredom)
What exception is being thrown exactly? I'm assuming an ArgumentException based on your description, but please correct me if I'm wrong. If a SocketException is being thrown, it's possible that your router does not support multicasts. You should consult your router documentation (or ask an admin) to find out for sure (although it would be safe to assume that it does).
Finally, for sanity's sake, debug this code and after the ip is assigned by IPAddress.Parse, check the IPAddress.AddressFamily and make sure that it is indeed AddressFamily.InterNetwork. An ArgumentException is most likely thrown when the IPAddress does not belong to the AddressFamily specified in the UdpClient constructor.
Hi Folks, I wonder if somebody can either point me in the right direction or explain a certain concept to me... i just can't figure it out (i've browssed through MSDN)...If in an application I have several threads running and while these threads are running something arrives on the serial port of the computer...Using a control I can raise an event to signal this "BUT" will the application be aware that this event has taken place? Or how can I make sure that the application is aware that something has been recieved at the serial port while other threads are running?.... Please can someone help...
A secondary issue also related ... say again multiple threads are running in an application, in one thread I implement a lock on a certain portion of code (so this must complete execution before any other thread can resume control)... if a timer raises an event (or is due to raise an event) while another thread is executing a portion of locked code... will this timer event be lost by the time the locked code in the other thread completes???
can anyone help!!! I'm desperate... can't find this information anywhere...
maria_p wrote: say again multiple threads are running in an application, in one thread I implement a lock on a certain portion of code (so this must complete execution before any other thread can resume control)...
Now, what I remember from my concurrency lectures (8 to 10 years ago) if you lock a piece of code (the "critical section") other code in other threads can still execute as they are not preventing from executing, they just can't execute the locked code.
Think of the critical section as the centre of a highway intersection with an American 4-way Stop sign. (In America the rule is the first to arrive has right of way and can pass through the intersection). So the first car arrives and is allowed onto the intersection. A fraction of a second later another car arrives from a different direction, it must wait until the first car has passed through. This is locking. Now, just because some traffic has to wait to gain access to this intersection doesn't stop the traffic flowing on an interstate a mile away.
Does this help you understand how concurrency (multithreading) works?
Yes thank you Sir, what you have said and the way you put it has given me a totally different way of looking at the issue (Excellent analogy!)... still a little confused about one issue though.... regarding the event at the serial port....
If various threads are executing in the application will the system get a chance to acknowledge the/an event (which I am expecting at some point) that may take place due to something arriving at the serial port? Or when one thread looses control another thread will immediately take control and due to this the possible event will be missed or seriously delayed? Is there a way around this or am I just missing the point about something?
If you could also explain this I'd be most grateful.
Colin Angus Mackay wrote: Now, what I remember from my concurrency lectures (8 to 10 years ago) if you lock a piece of code (the "critical section") other code in other threads can still execute as they are not preventing from executing, they just can't execute the locked code.
This depends on a number of factors. First, it depends on what you're locking against (if using the lock keyword). As I explained to her before, if you want to lock a block of code for all threads, then a static object (say, the Type of the class that contains the definition) should be used. If she uses an instance variable (such as this), then only the method will be locked for that instance no matter how many threads reference the class.
If you use the lock keyword, a Monitor is used which does block successive calls by different threads. The only way for threads to not wait is to use Monitor.TryEnter or use a Mutex and call WaitOne with a value to set the timeout.
Don't forget about all the articles in the .NET Framework SDK besides those in the class library. There is a pretty big selection of articles about threading in .NET at http://msdn.microsoft.com/library/en-us/cpguide/html/cpconthreading.asp[^] which also includes a lot of examples. Many of the overviews should even discuss threading in general for those not familiar with threads.
I'v been converting some classes I wrote in VB.net to stick them in a C# DLL, but have come accross some wierd irregularities in the .net architecture.
Firstly, the C# compiler will not allow me to explicity pass the value of one numerical variable into an enumerated data type, whereas VB allowed it, and MSDN swears blind it should. For instance:
VB: mnFog(x, y) = Convert.ToByte(sChar) - works fine
C#: mcFog[nLocX, nLocY] = Convert.ToByte(sChar); - Cannot implicitly convert type 'byte' to 'ThisEnum'
The enum in question is derived from a byte.
Secondly, C# just doesnt "see" some methods and properties which VB can use. For instance, in Microsoft.Data.Odbc the OdbcDataReader has an Item collection which allows its user to retrieve a field by its SQL name, instead of its column number (like the .Get[Type]() functions).
See for yourself, reference the DLL, find "Microsoft.Data.Odbc.OdbcDataReader.Item" in the object browser, then try and use it.
Has anyone else experienced these sort of problems?
dalm wrote: Cannot implicitly convert type 'byte' to 'ThisEnum'
Cast your value you pass, so if you have a function sig. which has an enum as a parameter such as this:
int SomeFunc(ThisEnum e);
and you know the enum value, simply cast it when you make the method call:
int a = 2;
dalm wrote: Secondly, C# just doesnt "see" some methods and properties which VB can use. For instance, in Microsoft.Data.Odbc the OdbcDataReader has an Item collection which allows its user to retrieve a field by its SQL name, instead of its column number (like the .Get[Type]() functions).
C# doesn't syntactically reference items like VB.NET does, it uses the  syntax instead.