|
|
I'd like to have a globals class in my app with a global dictionary, but am having trouble getting past the error below. Any ideas or suggestions?
<br />
using System;<br />
using System.Collections.Generic;<br />
namespace GlobalDict<br />
{<br />
public partial class Globals<br />
{<br />
public static Dictionary<string, int> GlobalInts = new Dictionary<string, int>()<br />
{<br />
{"one", 1},<br />
{"two", 2},<br />
};<br />
}<br />
class Program<br />
{<br />
public static Globals g = new Globals();<br />
static void Main(string[] args)<br />
{<br />
int i = g.GlobalInts["two"];<br />
<br />
}<br />
}<br />
}<br />
Sincerely,
-Ron
|
|
|
|
|
Aside from warning you about using globals AND public members, you can't use an instance. Try this syntax: Globals.GlobalInts["two"]; If you remove the static modifier, you'll be able to use the instance reference.
Scott P
“It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.”
-Edsger Dijkstra
|
|
|
|
|
Lets say i however fire the Close method.and close it is fine. but i want to confirmed it is actually close and dispose with that resources.
Because i have a page and i have used a TVgrabber componenet and show TV card tuner, but when i going to another page closing that..it gets flicker with my page. I couldn't close that Grabber properly also i want to dispose all in.
using System;
using System.Data;
using System.Data.SqlClient;
using System.Collections;
namespace ItvC
{
public partial class frmTVX : Form
{
public static frmTVX tv = null;
public frmTVX()
{
InitializeComponent();
tv = this;
}
private void Close()
{
this.TopMost = false;
this.Close();
frmMain.FormMain.Show();
}
}
}
|
|
|
|
|
Well...
First, you're calling Close() from within itself. Eventually, you're gonna run out of stack space.
Second, the last line in Close() will never be executed because you're recursing back to the same function before it gets there.
I'm surprised your system hasn't caught fire yet as a result.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
i have created the service project and sometimes it gives some exceptions. i want to handle them and show the message to the user by MessageBox . but in this context there is no MessageBox . How can i use the MessageBox?
|
|
|
|
|
It's generally not a good idea to have a service interact with the user.
If you really know what you are doing, you have to add a reference to System.Windows.Forms to show a MessageBox. For it to actually appear, ensure the checkbox for Allow service to interact with desktop is checked (service applet - properties).
How about logging the events, or sending out an email when something fails?
Cheers,
Vikram.
The hands that help are holier than the lips that pray.
|
|
|
|
|
|
You can't/shouldn't.
Instead, write an system tray application that monitors the service and puts the message box up itself...
[EDIT] Why did you vote this a one? Did you want me to write the code for you too?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
modified on Wednesday, May 14, 2008 3:31 PM
|
|
|
|
|
It wasn't the OP who 1-voted you, it was someone with gold status. He(?)'s bronze, so if it was him the average with my 5 would've been 4.2, not 3.
You know, every time I tried to win a bar-bet about being able to count to 1000 using my fingers I always got punched out when I reached 4....
-- El Corazon
|
|
|
|
|
With a service it's a very bad idea to assume there is a user at all. Services are by definition assumed to have no user present, supervising them. Often services are running on a remote computer like a file or application server that may be in another country from the person responsible for it.
Keep this in mind at all times when writing a service, it should handle everything possible on it's own.
Have a look at the System.Diagnostics.EventLog component. That is a commonly expected and accepted way for a service to indicate an error of some kind. Avoid the temptation to put too much in that log, your users won't appreciate it. Stick to truly important messages.
Then users can view a problem in the Event log in windows if they have one or use many automated tools for working with the event log (like emailing them if an error occurs etc etc).
"The great pleasure in life is doing what people say you cannot do."
- Walter Bagehot
|
|
|
|
|
thanks. I got another problem with service project.that is when i install it after restarting the machine service is running, but the name of the exe file which installed is displayed in ADD/Remove Prog's. through it can be uninstalled. is it ok to display it in ADD/Rem Prog's.
|
|
|
|
|
Very bad practice to start a new question in an existing thread. Start a new thread if you have a new question please.
"The great pleasure in life is doing what people say you cannot do."
- Walter Bagehot
|
|
|
|
|
Hello everyone,
Here is my code for Dispose method. Currently, I am thinking whether it is necessary to make it thread safe by adding a lock to prevent two threads to execute Dispose methods at the same time?
Notes:
1. disposing is used to indicate explicit call to Dispose or implicit call from Finalizer;
2. disposed is used to indicate whether current instance is Disposed or not, to prevent from disposing again. The thread safety consideration is used to protect this variable.
protected virtual void Dispose(bool disposing)
{
lock (DisposeLock)
{
if ((false == disposed) && (true == disposing))
{
disposed = true;
}
}
}
thanks in advance,
George
|
|
|
|
|
Why would two threads call dispose on the same object ?
Christian Graus
Please read this if you don't understand the answer I've given you
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Thanks Christian,
My concern is, if a reference is or potentially held by two threads, and they may call Dispose at the same time. Any comments?
regards,
George
|
|
|
|
|
They may not. Strictly speaking, if two threads or objects hold references to a single object, neither of them may call Dispose.
If they do, they are violating the fundamental rules of the IDisposable pattern.
The rules in short:
1. Dispose is meant to tell an object this: "I now know for sure that nobody has a reference to you except for myself, and I will never talk to you again - you may now safely throw away any resources you've been holding on to. If I or someone else ever talks to you again, please throw an exception.".
2. If you don't know for sure that you're the only one holding a reference to the object, you should never call Dispose. Just drop your reference (as in myRef = null;). The GC (garbage collector) will then call its finalizer (~TheClass) as soon as a) it realizes that nobody holds a reference to the object any more and b) it or your program has nothing more important to do. The finalizer will call Dispose(false), ensuring that any unmanaged (operating system handles and whatnot) will finally be released.
The only reason that the docs say that you should always allow calls to Dispose even if you are already disposed or not completely initialized is that you may in some cases get called from a catch or finally block that shouldn't have to check whether or not the try block that should have called you actually did it before the exception got thrown. This can never occur simultaneously on different threads, though.
So, the IDisposable stuff is only an optimization, enabling us to force expensive resources to be released before the GC gets around to it - but it should never be used unless we know for sure that the object is dead for good. Note that there is a lot of code (even in the framework) that just crashes spectacularly instead of throwing the proper exceptions if you try to use an object that has been disposed. Try loading a bitmap, showing it in a picture box and then disposing it (while still showing it). Results will vary - the app may exit silently, throw a protection fault or even display random graphics. At least, this was true in 1.1 - it was a while since I tested that.
Later,
--
Peter
|
|
|
|
|
Great reply, Peter!
1.
PeterTheSwede wrote: The only reason that the docs say that you should always allow calls to Dispose even if you are already disposed or not completely initialized is that you may in some cases get called from a catch or finally block that shouldn't have to check whether or not the try block that should have called you actually did it before the exception got thrown. This can never occur simultaneously on different threads, though.
I am very interested in the scenario you described, but still confused after reading a couple of times. Could you show some pseudo code please?
2.
"dead for good" means on one else refers the object?
3.
PeterTheSwede wrote: Note that there is a lot of code (even in the framework) that just crashes spectacularly instead of throwing the proper exceptions if you try to use an object that has been disposed.
You mean ObjectDisposedException should be thrown -- and in your points should be the correct behavior -- in this scenario?
regards,
George
|
|
|
|
|
1. I'll try.
If I remember the recommendations for the IDisposable interface correctly, the requirement that duplicate (but not simultaneous, mind you) calls to Dispose() shouldn't fail is explained with something like this:
MyClass obj = new MyClass();
try
{
obj.DoSomethingThatCanFail();
obj.Dispose();
this.DoSomeOtherStuff();
}
catch
{
obj.Dispose();
throw;
}
This code should be considered correct - that is, you shouldn't have to check if things went wrong at A or B in the catch block. Note that obj could potentially be a 2GB image, and the DoSomeOtherStuff() method could also be something extremely memory-hungry. In which case it makes sense to call obj.Dispose() then and there instead of in a finally block.
2. Exactly.
No one but you refers to it and you aren't ever going to use it again. If you can't guarantee those conditions, you're essentially not allowed to Dispose() the object.
3. Yes.
According to Microsofts current recommendations, ObjectDisposedException should be thrown if you try to do anything with an object that is disposed (except calling Dispose() again). But like I said, there's a lot of code out there that just crashes instead. Understandably - it's easy to forget if (disposed) throw new ObjectDisposedException(); in a method or property somewhere.
Which makes it even more important to never use Dispose() unless you're absolutely sure that the object is dead. People who get buried alive don't play nice... 
Later,
--
Peter
|
|
|
|
|
Thanks Peter,
Your reply is great!
1.
In your sample, it is possble to call Dispose twice on the same object if there is exception thrown from DoSomeOtherStuff, in this case, there will be ObjectDisposedException from catch block?
2.
Is it always a program bug when we met with ObjectDisposedException? Means someone Disposed the object instance, but some other guys may still refer it and call the method on it.
3.
I like your below code,
if (disposed) throw new ObjectDisposedException();
Currently, I think of two solutions when met with ObjectDisposedException. Solution 1 is to do operations on object straigtforward without checking IsDisposed property, and wrap catch block to catch ObjectDisposedException, solution 2 is to check IsDisposed property as you showed above, and it is set, do nothing but throw ObjectDisposedException to propogate out or write a log without rethrow. I am wondering which pros and cons and your suggestions of which solution is better?
regards,
George
|
|
|
|
|
Thanks for the appreciation!
When English isn't your own language (which I assume it isn't for neither of us), it can be hard to understand even the good C#/CLR books sometimes. I have read a lot of good texts about the IDisposable interface over the last few years (there are even some excellent articles on CodeProject), but I must admit that it wasn't until recently that all the pieces of the puzzle fell into place. Sometimes you have to read the same thing (phrased differently) several times before you get it.
So, I'll try to summarize the most important points again (it should answer your follow-up questions as well), as short and concise as I can:
A: It is always legal to call Dispose() on an object more than once, for exactly one reason: The example I gave (and similar code) should always work even if something happens in DoSomeOtherStuff(). This means that a call to Dispose() should never cause an ObjectDisposedException - if the object is already disposed, Dispose() should just silently do nothing. Note that usually, the only place where this is acceptable is in an exception handler (as in my example).
B: It is always illegal to call any other method or property on an object after Dispose() has been called. And ideally, an ObjectDisposedException should always be thrown if that happens (but like I said, this is not always the case - sometimes very bad things such as unmanaged memory corruption or similar happen instead - even in some .NET Framework classes).
Some conclusions (some obvious, some not):
C: You may only call Dispose() on an object if a) you created the object, b) you haven't given away the reference to anyone and c) you're done with it. Can't be said too many times...
D: If you ever see an ObjectDisposedException, it is a bug. It should be fixed (yesterday), so it's fine to just crash (as long as you leave a clue as to why, meaning that if you're a service or a web application, you should log the exception before crashing - if you're a Windows app, you should display it and/or log it).
E: A repetition of rule C from a different angle: If you ever expose your reference to a disposable object (by returning it from a property or using it in a call into a class you don't control), you effectively give up your right to dispose of it. There are cases when it is OK to do differently, but they must be documented. For example: "If you dispose of a MyParent object, all MyChild objects created by it will also be disposed of, and may not be used again" (if I remember correctly, there are such relationships in the SqlClient namespace in the framework). In such cases it does make sense to deviate a bit from the basic rules.
F: Answering your original question - making the Dispose() method thread-safe is meaningless. It should only be called by the class that created the object, only when it will not be used again (even though additional Dispose() calls may be made by the same caller due to exception handlers) and only when nobody else can hold a reference to the object. Hence, the class creating the object has no reason whatsoever to call Dispose() from more than one thread. If someone comes up with a reason (I once did, actually - I called the same termination and cleanup routine from a worker thread that I exposed to clients when it died due to external problems), the caller is free to implement his own synchronization (I did in my termination routine).
G: A public IsDisposed property is entirely meaningless. If the code calling Dispose() doesn't know it did, it's broken (the example with the exception handler is the only exception - but since an extra Dispose() should cost less than a property check, the property still doesn't make sense).
H: The IDisposable interface is meant for classes holding unmanaged resources (including other disposable objects). Don't bother otherwise (unless you're writing an abstract class that would typically be implemented using unmanaged resources or disposable objects).
Finally, an example from the framework: If you create an Image from a BinaryStream you may think that you can dispose of the BinaryStream when that is done. Not so. The Image will not read the entire stream until it has to, and if the stream is a file it is even free to read the same part of the file several times when needed. Look at rule E. You showed the stream to the image, so you're no longer in control of it, and may not call Dispose(). In this particular case, you can dispose of the image (after making sure that nothing that has seen it is still around) and then of the stream.
Clear as mud?
One more suggestions: Do read the articles on implementing the IDisposable interface here on CodeProject as well. There are some aspects (such as how exceptions in Dispose() should be handled, and how object inheritance comes into play) to it that I haven't mentioned. It's too complex for a forum post, and I don't remember all of it anyway...
Good Night!
--
Peter
|
|
|
|
|
Thanks Peter,
Your reply is so great!
After reading your reply, I think it should be a bug -- either my code or CLR code, if ObjectDisposedException is thrown.
My detailed scenario is like this,
(I am writing an Http Server service using HttpListner class of C#, and handles coming request in an asynchronous way.)
1. The exception from server side, when I call EndGetContext, not from client side;
2. On the server side, I create an HttpListener object, and waiting for incoming client request;
3. When I received a request, I will process the request asynchronously by using BeginGetContext, and in this way HttpListener object instance can still listen for incoming calls, while processing backend at the same time;
4. When sending the request to server from client, the client will close the connection immediately -- during the asynchronous processing period;
5. The server will throw exception when I call EndGetContext. At the same time, ObjectDisposedException will happen.
Any ideas why the exception will happen? I am also interested in whose Disposed method is called, any ways to detect which object instance's Disposed method is invoked?
regards,
George
|
|
|
|
|
Hi!
Again, thanks for the appreciation. I usually don't write such long answers but I've been at a customer site (staying at a hotel) this week, and nights get a bit boring...
Sorry, no idea what is happening. I have never used asynchronous calls seriously so I don't have any experience to draw from. Then again, try looking for asynchronous samples (I don't find any using HttpListeners, but there are bound to be others) and understand what they do. Then perhaps it will become clearer.
--
Peter
|
|
|
|
|
Hi,
I've seen others have this concern and have seen a multitude of solutions, but like Christian says, why? I only realized this recently (and felt pretty stupid about that), but like he says, there is NO circumstance whatsoever where it is correct for two different threads to invoke Dispose() on the same object.
In fact, if Dispose() is ever invoked twice on the same object (even from the same thread), it is a design fault. It is explicitly wrong to invoke Dispose() on an object if there is a chance (no matter how slim) that someone else is holding a reference to it (meaning that if you ever directly or indirectly expose a reference to an object outside of your class, you should never dispose the object).
Further, Dispose() cannot be invoked unless the object is alive, so it can never conflict with the finalizer being invoked by the GC.
The most common pattern for implementing IDisposable that I've seen is:
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
}
disposed = true;
}
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
~MyClass()
{
Dispose(false);
}
Note: Written from memory, beware of spelling mistakes. Google for "IDisposable pattern" and you will get all the examples you need (good and bad).
Later,
--
Peter
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
