|
well its like this
when i run the program a form shows up and it has a button like this
form2 F = new form2();
F.show();
this F form is the one making all the operations, saving changes, deleting etc, when the error occurs this F form calls ITS dispose method to close the F form, when i tried to see why it was being called (exception.stacktrace or exception.source) it only showed me the exception was originated in my class ( that F form.cs) i dont know why it gives me that exception, i dont know what object its refering to, the form itself?
after it closes the F form the first form shows me another exception here
static void Main()
{
try
{
Application.Run(new Form1());
}
catch (Exception ex)
{
}
}
that exception's stacktrace is huge, something like " ex.StackTrace at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc....... "
|
|
|
|
|
Hi,
I suggest you look at the first stacktrace line that mentions a file name with line number; that is where you should start looking.
BTW: if a release build does not give that information, try a debug build instead.
[ADDED]
FYI: The ideal way of implementing Dispose(), from the excellent article Implementing IDisposable and the Dispose Pattern Properly[^] by Scott Dorman:
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
}
}
disposed = true;
base.Dispose(disposing);
}
[/ADDED]
|
|
|
|
|
thanks for the advice man, by the way my dispose method is the same as that one you posted, i didnt create it , visual studio puts it in there for me, it has it like this :
protected override void Dispose(bool disposing)
im gonna look at ex.stacktrace once again though, i hope i find something there
the thing that i cant understand is that i know all the methods involved, i thought one of them would be the problem but they all work fine!, even when the error occurs
this is the method's order: beforeselect(treeview), InfoChanged(this one i created), updateInfo(this one i created), SQLUpdate(this one i created to update database registries), AfterSelect(treeview)
when the error occurs it occurs AFTER all my methods, it evens saves the changes, is there any way this could be some random visual studio problem or something? because i do the same steps over and over again and the error occurs only sometimes.
|
|
|
|
|
i mean why does the program calls Dispose after everything is done if i didnt call it myself?????
|
|
|
|
|
Hi,
there are several ways Dispose() may get called implicitly:
- through the using statement as in using Form myDialog=new Form() {...}
- through some method that cleans up and basically hides Dispose under another name (File.Close, Form.Close, ...) ;
- by the GC finalizer once it decided your object is no longer alive (i.e. all references to it have vanished);
- and maybe more.
[ADDED]
When an app is done, most if not all objects are no longer alive, and might get
collected, hence their Dispose() called, however the process is not guaranteed to do that; just exiting is good enough to clean everything. If you happen to have an app that intends to exit, but remains somewhat alive (because of a thread for which you forgot to set IsBackground=true), a lot more Dispose() calls would eventually occur. In that case Task Manager would no longer show the app (under the Applications tab) but it would still show the process (under the Processes tab).
[/ADDED]
|
|
|
|
|
hey i havent seen this post, i will check right now maybe there is something like this in my program thanks a lot man you are very helpful every time i come here
|
|
|
|
|
Hi,
a program running fine most of the time probably indicates it is mostly correct;
however a single failure indicates it is not completely correct.
IIRC you mentioned a null ref exception and a Dispose being called twice; I do not understand how these fit together though, a correct Dispose is protected against null refs; and maybe the double Dispose is due to Dispose() calling Dispose(bool)?
Anyway, you have only two handles to the problem: source code review, and analysis of the symptoms.
Once you know the exact line (and calling context) where the fatal exception occurs,
and assuming you have the source, you could add logging information writing lots of
useful stuff to a file, so next time it fails you can work from there.
If it really is a null ref, it should be rather easy to figure which reference is bogus,
and then analyze how that is possible...
FWIW: Are you sure your try-catch constructs don't discard exception information,
i.e. if a catch block is empty, an earlier exception may got consumed unnoticed, making it much harder to figure out what caused later symptoms.
|
|
|
|
|
hi man, well no not one of my try catches are empty so i know when an exception happens, what i was refering to when i said dispose called itself was that i added a little piece of code to my dispose method, a call to the method that checks if any changes has been made, so whenever i close my form , the form lets me know if there were in fact any changes, this call im talking about has as parameter a treeeview node name, at first i thought this was the problem, maybe i havent selected any nodes so if i make the reference treeview.selectednode.text it would make sense that it gave me a nullreference exception since nothing is selected, but i erased that line and left the dispose method as visual studio puts it for me and the error still happens sometimes.
i mean even if i messed up in the dispose method by adding a line of code with a null reference, the program , as far as i know, only calls the dispose method when im closing the form, so why would the dispose method call itself after i saved my form's changes IF I HAVENT EVEN CLOSED THE FORM YET???
and ONLY sometimes, i mean i do the same steps over and over again and most times nothing bad happens and dispose method doesnt call itself for no reason, until i actually close the form.
thanks for your replies
|
|
|
|
|
Hi,
one must be careful about the things executed while in Dispose: the object itself may be dead (when Dispose got called by the GC finalizer), whatever it's state it may (probably will) still reference other objects that may or may not be alive (alive when other live
objects also refer to them).
e.g. a Form that gets closed holds all its Controls in a Controls collection, and
all these Controls refer to the Form as their parent, so they are likely to be
an island of dead objects. Now if you start doing something to one of them, that may
bring some of them back from the dead, really confusing the GC.
Say all its Controls got Disposed of before the Form.Dispose() gets called; if you now move one of its Controls (they are still in the Controls collection and possibly in some of the Form's data fields!) to another Form, that Control is alive again, and your app is 1) likely to crash and 2) if not, may well call Dispose on that Control again.
|
|
|
|
|
Sorry I didn't get back sooner, but it looks like Luc has you in the right direction.
Bar fomos edo pariyart gedeem, agreo eo dranem abal edyero eyrem kalm kareore
|
|
|
|
|
<br />
{<br />
form2 F = new form2();<br />
F.Show();
}<br />
Consider using ShowModal(), which blocks until the form is closed. Otherwise you'll have to keep a reference to F somewhere to keep it from being collected.
|
|
|
|
|
Well, since you mentioned that a NullReferenceException is being thrown, it just sounds like that exception is bubbling up to the highest level and causing the application to exit. If you have a Try/Catch around your Application.Run call, and you don't actually do anything with the exception, then the app will exit without displaying any error message.
Dispose may get called more than once if the class has a finalizer, which will force the GC to stick the type in the finalization queue. Finalization is an ugly process, and objects can get revived by the GC for cleanup up to several times before they are actually deleted and the memory freed. Revived objects may get disposed of again. The Form object uses unmanaged resources, and does have a Finalizer, which could lead to the multiple invocations of Dispose you are seeing (depends on exactly how memory cleanup goes for each run of the application).
There are some exceptions that can not be recovered from, like OutOfMemoryException. If you are handling the NullReferenceException, its possible that whatever triggered it may have resulted from an OOM exception, which would ultimately cause the application to end (usually you would see it...your exception handling policies may be hiding it though).
Hope this helps.
|
|
|
|
|
thanks man this seems to be the problem for me i guess, but why does it only happen sometimes and most times nothing happens??
in every try catch i have i put a messageBox.show(exception.message) so i notice when an error occurs, after my form2 closes itself with dispose(), then the first form,form1 calls its dispose method and after that it gives me and exception here
[STAThread]
static void Main()
{
try
{
Application.Run(new Form1());
}
catch (Exception ex)
{
string e=ex.StackTrace;
MessageBox.show(ex.message);
}
its something like unsafeNative etc etc
if i see it again i will post it here
i havent seen it again though, thanks man
|
|
|
|
|
I am guessing it only happens some of the time because only a subset of the data that your Save method encounters is causing the problem. If you really want to nip this thing in the bud, you need to try and catch the exceptions sooner. Part of the reason your having trouble is your catching the exception too late...its bubbling up the call stack, and in the process, its causing objects like your Forms to fail (which in turn causes them to be disposed and garbage collected). You are catching the exception, but only at the very last possible moment, after the application has essentially crashed.
I can't give you specifics with the information I have at hand, but you need to wrap a try/catch around code farther up the call stack. If you can trap the exception early, you can find out what is causing it because you will be able to use the VS debugger to examine object instances and values (which are all garbage collected by the time your exception hits the catch you posted above). (If you can post some of your code related to this save operation, particularly where you think the NullReferenceException may be getting thrown, I can help more.)
|
|
|
|
|
yeah i think you are right i didnt want to post code because its pretty big but im going to post the code involved in save operation, thing is i dont have a clue where this exception is being thrown because even when the error occurs and te program shuts down, even then it SAVES THE CHANGES (thats why i dont think there is anything wrong with my sqlite connection or anything, its a forms thing) after it closes i look at my database and the changes took place, everything is updated.
this will take a little while thanks everyone for your help
|
|
|
|
|
well they asked me to make some changes to the code so i will post it when im done with the changes, i hope this thing doesnt happen again thanks everyone for your time
|
|
|
|
|
Hi,
I'm a long-time C++ programmer and relatively new in C#.
I have not been working with UI-related stuffs for a while.
Recently I had a project that is related to a GUI-based application, which requires a custom-style listview control. I found some listview controls in "the code project" that may fit to my purpose. But most of them are written in C# and it's output is a Class Library (DLL). In general, is there any way for me to use those custom listview controls written in C# in my Win32 C++ project (using Visual Studio 2005)? Or is it simply impossible? Thanks a lot for your help in advance.
|
|
|
|
|
|
|
Is it urgent?
"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
|
|
|
|
|
|
What if he just needs teh codez?
modified 12-Sep-18 21:01pm.
|
|
|
|
|
John Simmons / outlaw programmer wrote: Is it urgent?
Yes, I just find out that my project submission is tomorrow
|
|
|
|
|
oh ok I guess you failed then. Do better next time. 
|
|
|
|
|
It sucks to be you, then.
"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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
