|
|
RickSharp wrote: This code will throw an exception because of the object not being set to a reference.
Then you need to fix that bug. Glancing at your code it seems you are using the variable ckBxSelect without setting it to refer to any object.
|
|
|
|
|
The only way I know how to refer to a checkbox in a TemplateField is by using GridViewRow in a foreach loop. If there is another way to find that control then i would love to know.
|
|
|
|
|
I don't know what relevance this has to do with my comment. If you do not understand the error "object not being set to a reference", then I would suggest rereading your C# documentation on objects and references.
|
|
|
|
|
Thanks for the insight. I'll go reread my C# manual...
So i read it, and I guess I'm too stupid to understand it. Maybe someone else can help.
|
|
|
|
|
I have resolved this issue by reading an asp lablel key into a dictionary. then if the dictionary had that label insert into my database. Sorry if I was vague but I'm very new to all of this so I mostly i just make others made by asking inane questions that are apparently to unclear to understand. 
|
|
|
|
|
In a C# 2008 windows application, my initial install of the code obtained the message,
"Cannot access a disposed object.". This was valid at the time.
However now I corrected the problem in the code and reinstalled the corrected application. I am still getting the error message, "Cannot access a disposed object.".
Thus my question is once I reinstalled the corrected code why would I still be getting the message,
"Cannot access a disposed object."?
|
|
|
|
|
Reinstalling will have no effect. Your code is trying to access something that has been disposed. This is a bug in your code.
|
|
|
|
|
classy_dog wrote: why would I still be getting the message,
Because despite what you think you did, you did not fix it.
Some possibilities
- It is a different object, so a different bug.
- You are still running the old software (you didn't install the new stuff.)
- You didn't actually fix the bug.
|
|
|
|
|
When reading about IDisposable, I get the impression that the consensus is that once you introduce it, everything that's even heard about it need to be made IDisposable too. Can this really be correct?
I have a class DriverWrapper that holds an IntPtr to a DLL with a C interface. This class is IDisposable, and implements the standard Dispose pattern, with a finaliser. It also has a number of abstract functions, some delegate definitions, and a helper function to get a delegate from the loaded DLL.
From this class, I derive some other classes, which implements the abstract functions by creating delegates to DLL functions. (The reason for this is that I have three related DLLs, all doing effectively the same thing to different bits of hardware, so to a user in the application it makes sense that they all have the same, shared interface. Unfortunately, the DLLs have different names, and in some cases different signatures, for their functions.)
Now, the derived classes are already IDisposable from DriverWrapper, but if they only hold delegates, which aren't IDisposable themselves, is there any need to override Dispose(bool) in these? I think not, but I'm no expert on C#.
(Oh, and I'm not concerned with the using idiom, as these will be alive throughout the lifetime of their owner. Neither am I interested in whether I should implement it in case I will at some future point have a managed and disposable member, or hypotheticals like that.)
Next question:
There is an abstract base class Model which takes a DriverWrapper as a constructor parameter, and takes ownership of it. The classes derived from this only override one function, and are just meant to provide different types of DriverWrapper-derived classes. I'll need to have access to the DriverWrapper for the whole lifetime of the Model.
abstract class Model
{
DriverWrapper theDriver;
Model(DriverWrapper driver)
{
theDriver = driver;
}
...
}
class DriverWrapper : IDisposable
{
~DriverWrapper()
void Dispose()
void Dispose(bool)
}
class DriverA : DriverWrapper
{ ... }
class DriverB : DriverWrapper
{ ... }
class DriverC : DriverWrapper
{ ... }
class ModelA : Model
{
public ModelA()
: base (new DriverA())
{}
}
Would Model have to be IDisposable? Surely the DriverWrapper is now managed, and will be tidied away when the Model is? If not, would ModelA-C need to override Dispose even if they have no further data?
(Honestly, at times like this I really miss RAII and typedefs from C++)
|
|
|
|
|
Any classes derived from a disposable class are already disposable so there is no need to override Dispose(bool) unless it holds additional resources, in which case it should override, free the additional resources then call base.Dispose(disposing).
Any wrapper classes that wrap a disposable class should be disposable so they can dispose the wrapped object properly.
|
|
|
|
|
Orjan Westin wrote:
When reading about IDisposable, I get the impression that the consensus is that once you introduce it, everything that's even heard about it need to be made IDisposable too. Can this really be correct? |
No, otherwise the whole framework would implement it.
Orjan Westin wrote: Would Model have to be IDisposable?
No, what you have is perfectly reasonable.
What can happen is that in taking control of when an object is disposed, it results in the impulse to chain IDisposable all the way up calling classes. Really you you only need to implement IDisposable where it makes sense: e.g. for memory performance or objects interacting with IO of some sort. As an example, I often write repository classes for EF/Linq TO SQL as the Datacontext is IDisposable and I want to pass the control of the datacontext's disposal up to the repository's controlling class I make the repository IDisposable but the calling class generally uses the using statement, or explicitly calls the destructor depending on the operations I am actually performing against the backing store.
|
|
|
|
|
Adding IDisposable never hurt anyone. A big part of me wishes Object had a Dispose and there was no interface -- I think that would be cleaner.
(This is not likely to be a popular opinion.)
|
|
|
|
|
PIEBALDconsult wrote: Adding IDisposable never hurt anyone. A big part of me wishes Object had a Dispose and there was no interface -- I think that would be cleaner.
May be not. You don't have to Dispose() all the objects. Only those which holds up resources that needs deterministic cleanup.
PIEBALDconsult wrote:
(This is not likely to be a popular opinion.)
True 
Best wishes,
Navaneeth
|
|
|
|
|
Adding IDisposable never hurt anyone
Actually, it does, by adding unneeded clutter and complicating the class.
|
|
|
|
|
Orjan Westin wrote: When reading about IDisposable, I get the impression that the consensus is that once you introduce it, everything that's even heard about it need to be made IDisposable too. Can this really be correct?
Not really. It depends on how you want to maintain lifetime of your resources. Only those who take ownership of resources should care about Dispose().
Orjan Westin wrote:
Now, the derived classes are already IDisposable from DriverWrapper, but if they only hold delegates, which aren't IDisposable themselves, is there any need to override Dispose(bool) in these? I think not, but I'm no expert on C#.
If it has nothing to dispose, you should be good with the base class implementation.
Orjan Westin wrote:
Would Model have to be IDisposable? Surely the DriverWrapper is now managed, and will be tidied away when the Model is? If not, would ModelA-C need to override Dispose even if they have no further data?
You can model it either way. If model is responsible for managing lifetime of a DriverWrapper, I'd put Dispose() to model which calls DriverMapper's Dispose(). But since model gets DriverWrapper through constructor, you would be constructing it somewhere else. In this, it'd be cleaner to model it like who creates DriverWrapper will dispose it when done.
More than that, if your DriverWrapper will be initialized when your application starts and needs to be alive till it ends, and in Dispose() all you do is reclaiming native allocated memory, then you probably shouldn't worry about dispose pattern because when the application exits, OS will reclaim all it's memory. And implementing dispose pattern would be an overkill.
Orjan Westin wrote: Honestly, at times like this I really miss RAII
That's what using keyword tries to do. But dispose pattern is different than RAII and not sure if both can be compared. A Dispose() call with never destruct a class. All it does is to provide a mechanism to release resource before GC does it by calling Finalize(). Where in RAII, the object will be removed and memory wlll be reclaimed. In .NET there is no way to do deterministic cleanup.
Best wishes,
Navaneeth
|
|
|
|
|
Orjan Westin wrote: Now, the derived classes are already IDisposable from DriverWrapper, but if they only hold delegates, which aren't IDisposable themselves, is there any need to override Dispose(bool) in these? I think not, but I'm no expert on C#.
No. As you say they already implement IDisposable through inheritance, and if they don't specify any expensive resources that you need to clean up before the GC gets around to collecting your object, then you don't need to specify additional dispose behaviour.
Would Model have to be IDisposable?
If you want it to be cleaned up before the GC notices it, then yes. And since it's wrapping a class which you already decided should be disposable, then so should the wrapper, and its Dispose should call the driver's Dispose. These two sets of classes seem so closely related that I wonder if you need to have two sets of classes at all, though.
If not, would ModelA-C need to override Dispose even if they have no further data?
No (see first point).
You need to implement IDisposable if you are allocating resources that you want to have guaranteed return at a known time on, but you don't have sufficient control over the context to explicitly call a close method to release them. It's also convenient to implement it when you do have that context, but you want to use the class in a using(x) block, or if you might forget you're supposed to call a close method (as Dispose will get called in GC cleanup too).
You don't need to implement it if the resources you're allocating in a class are so small and unlimited in number available that you don't mind if they don't get collected for a while. That applies to most managed objects, unless they're really huge and there's a memory impact (though the GC will notice this and run a collection sooner than otherwise), and to unmanaged resources that aren't limited (e.g. non-locking file handles, sockets, bitmap handles etc). The other case is that if you know you need a resource for the entire lifetime of your process you don't need to implement IDisposable either, as the one time that finalisers are guaranteed to be called is in process shutdown (assuming it's a clean shutdown), and even if it doesn't get run, the OS will clean up after you.
|
|
|
|
|
In my winforms project I have a PropertyGrid which can be changed at runtime. I need to capture the double mouse click events to open a dialog window where you entered the code of the event. Can anyone help me?
|
|
|
|
|
|
Hi Richard,
I am testing various methods and events of the PropertyGrid class but could not capture the double click an event, nor the automatic generation of the event name using the method CreateUniqueMethodName.
I need to intercept this action to open my dialogue will be informed where the event code.
Can you be more specific?
Thanks
|
|
|
|
|
Your original question stated: I need to capture the double mouse click events
If you check the documentation there is a method called OnMouseDoubleClick[^] and an event called MouseDoubleClick[^]. Is there some reason why neither of these will do the job?
|
|
|
|
|
I had already tested the events MouseDoubleClick and both DoubleClick and not fired.
myPropertyGrid_MouseDoubleClick void (object sender, MouseEventArgs e)
{
MessageBox.Show ("MouseDoubleClicked");
}
myPropertyGrid_DoubleClick void (object sender, MouseEventArgs e)
{
MessageBox.Show ("DoubleClicked");
}
|
|
|
|
|
It would appear that the documentation is not very clear. Since almost everything within the property grid is a control, they are all consuming the mouse clicks. I found the only place where it responds is by clicking in the small space between the main property table and the description below it.
|
|
|
|
|
Sorry Richard, but did not. I clicked all over the place and does not fire any of the two events (DoubleClick / MouseDoubleClick).
|
|
|
|
|
It's a very small gap between the two windows. When the mouse is over it the cursor changes to a little dark horizontal line with an up and down arrow on it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
