Re: Application crashes on handled error. Why?
From: J French (erewhon_at_nowhere.com)
Date: 04/25/04
- Next message: J French: "Re: Add information into an exe file"
- Previous message: Sandro G: "Changing BackColor for MDIForm"
- In reply to: Dmitriy Antonov: "Re: Application crashes on handled error. Why?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 25 Apr 2004 07:31:52 +0000 (UTC)
On Sat, 24 Apr 2004 23:51:19 -0400, "Dmitriy Antonov"
<antonovdima@netzero.net_NOT_FOR_SPAM> wrote:
>> I have found that VB is in a very fragile state in the Initialize and
>> Terminate Events
>More important - they often behave differently in IDE and compiled version.
>This my recent problem is one example. Another example - if you have
>circular references at the end of the program you expect all of your objects
>to be destroyed enforcedly. This is how it works in the IDE. And this is how
>it doesn't work in compiled version. I didn't test weather or not objects
>are destroyed, but terminate events on those objects are not fired.
>
>> Trying to do something with a 'Nothing' Object Reference would
>> possibly create a new instance (if you have used Dim XX As New
>> cSomething)
>No, I never use this syntax. Well, maybe in some places, where I create
>object, call no more than one method and destroy immediately. Even then I
>try to shut up my laziness in most cases.
Same here - I generally clean them up later
>
>> I am not too happy about zapping a reference to a Parent in a Child
>> from within the Parent's Terminate Event
>> - that reference should /prevent/ the Terminate Event firing
>
>It is difficult to avoid circular references in something a bit more than
>trivial. And there is no question that circular reference prevents both
>objects from destroying. I always destroy at least one reference (usually
>reference to parent from child) prior to destroying parent object. I usually
>pay special attention to circular references and sometimes do some redundant
>mechanisms to kill them.
Well... IMO a Child can Raise an Event to notify its parent of
something
- I've become very mean on giving out references
>
>> Digressing slightly, I had serious problems with a UserControl, where
>> I was exposing a standard Textbox
>> - everything looked Ok, but after a bit the App would run out of
>> memory
>> - I tracked it down to the Terminate Event not actually firing
>
>If you are still curious what happened then you might find it useful to
>check this out.
>
>http://support.microsoft.com/default.aspx?scid=kb;en-us;190511&Product=vbb
Hmm - better just monitor the Terminate event
>
>That was the first time, when I'd encountered huge memory leak in my own
>program. When you read aforementioned KB article make sure you disregard,
>what Microsoft tells you - it is wrong (partially). The reason isn't control
>array, but rather the fact you are assigning control to object variable
>(regardless of whether or not you have control array). Probably this is why
>you had this problem too.
Well their 'problem' is a Private additional reference
- mine was because I made it Public
- and a pal of mine had a similar problem that took him days to pin
down
>Microsoft gives two ways to go around. The first way is not good by itself,
>because it goes from the wrong stated reason of the problem, as I said. The
>second way - to provide public method to destroy reference, IMO, is
>absolutely not acceptable. Can you imaging buying an ActiveX control, in
>which you must explicitly call some method to destroy something inside, and
>otherwise your program might go out of memory?
Well, it does seem a bit naff
- but that is the way Delphi works so I'm less concerned about that
In a way :
Unload frmMain does something similar
- and one does all sorts of cleanup in the Unload/Query_Unload event
>Unless it is something
>incredibly necessary, you, probably, would avoid such Trojan Horses within
>your program.
It would be nicer not to have them
>Now I do have UserControls with control arrays inside with no memory leaks.
>I just do not assign those controls to variables.
You mean 'expose' sub controls
- and/or create extra references
>I still don't know, what actually went wrong in my OP code. There is a
>combination of: call to trivial method of previously destroyed object,
>Terminate event, error handling in the form of "On Error Resume Next" and
>compiled version of the application. Some of those or all of them or
>something else, which is in my understanding (but not in VB's
>"understanding") is totally unrelated. Some of those factors cause that
>unexpected behavior (which is, probably, just another MS bug). Still a
>question. May be somewhere in the future I'll build testing app with only
>those conditions and see. Just don't want to spend time on this now.
Understood
I really would look at getting the Children to RaiseEvent
- rather than letting them know anything about their parent
(not so easy if one Parent has dozens of Children)
- Next message: J French: "Re: Add information into an exe file"
- Previous message: Sandro G: "Changing BackColor for MDIForm"
- In reply to: Dmitriy Antonov: "Re: Application crashes on handled error. Why?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
