Up to my neck in poo! Sub Finalize
-
I have written a class which has: Sub New: Set Property "Disposed = false" Sub Dispose: Cleans up and sets property "Disposed=True" sub Finalize: If Property Disposed = False throws expection Property Disposed The class basically stops you from letting object go out of scope without first Disposing them. So in all my uses of the above class I do this.... Sub MySub () Dim lObject as MyClass() .... lObject.Dispose End Sub Its impossible for this object to descope without me having called the Dispose method. YET!...In my live code, which is obviously a little more complex, I have put some message boxes in so I can do a simple trace. First of all, my live code draws buttons, and I get loads of mesage boxes coming up, where I thought they would come up one at a time, this suggests to me that every button is being drawn on a different thread, am I right? Next, how the heck can I find out why my class is being destructed before my sub dispose is called. The thing is when I look at the call stack it only has the current method on it and no parent calls. That's doing my head in. I started to get lots of problems on my project when I began using the DefaultValue attribute. This is a great feature, I love it, but am I taking the right approach? You see, when .NET starts my app in design mode it fires off lots of property sets. Each time a property changes, in my property handlers, I call a sub called PropertyChanged. That is responsible for invalidating my control area and redrawing. Should I be doing it that way? I instinctively feel I should not, because I want all the properties to be set, THEN, I want to draw. I dont want to redraw each time because the location changes, then again when the forecolor changes then the shape of the button changes. I feel SuspendLayout and ResumeLayout will be used, but I don't know how, because when the user changes properties like color I dont think OnLayout is called, so if my control is only redrawn in OnLayout it wont be redrawn to reflect new values when non-layout type properties change. Guys, I am sorry this message is such a mish mash, and thank you for your patience. You can see my frame of mind is somewhat dazed! Chris. Nursey
-
I have written a class which has: Sub New: Set Property "Disposed = false" Sub Dispose: Cleans up and sets property "Disposed=True" sub Finalize: If Property Disposed = False throws expection Property Disposed The class basically stops you from letting object go out of scope without first Disposing them. So in all my uses of the above class I do this.... Sub MySub () Dim lObject as MyClass() .... lObject.Dispose End Sub Its impossible for this object to descope without me having called the Dispose method. YET!...In my live code, which is obviously a little more complex, I have put some message boxes in so I can do a simple trace. First of all, my live code draws buttons, and I get loads of mesage boxes coming up, where I thought they would come up one at a time, this suggests to me that every button is being drawn on a different thread, am I right? Next, how the heck can I find out why my class is being destructed before my sub dispose is called. The thing is when I look at the call stack it only has the current method on it and no parent calls. That's doing my head in. I started to get lots of problems on my project when I began using the DefaultValue attribute. This is a great feature, I love it, but am I taking the right approach? You see, when .NET starts my app in design mode it fires off lots of property sets. Each time a property changes, in my property handlers, I call a sub called PropertyChanged. That is responsible for invalidating my control area and redrawing. Should I be doing it that way? I instinctively feel I should not, because I want all the properties to be set, THEN, I want to draw. I dont want to redraw each time because the location changes, then again when the forecolor changes then the shape of the button changes. I feel SuspendLayout and ResumeLayout will be used, but I don't know how, because when the user changes properties like color I dont think OnLayout is called, so if my control is only redrawn in OnLayout it wont be redrawn to reflect new values when non-layout type properties change. Guys, I am sorry this message is such a mish mash, and thank you for your patience. You can see my frame of mind is somewhat dazed! Chris. Nursey
OK...Well, as far as I can tell, your method of "preventing an object from going out of scope" won't work. Scope isn't controlled by how long an object lives, it's the other way around. As an example:
Public Class MyObject
Private Sub MenuItem4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MenuItem4.Click
Dim strText As String
strText = RichTextBox1.SelectedText.Replace(ControlChars.Lf, ControlChars.CrLf)
Clipboard.SetDataObject(strText, True)
End Sub
End ClassThe object 'strText' goes out of scope when you get to End Sub because strText was declared inside the sub and is not visible outside this sub. But if you change when the object is declared, you also change its scope:
Public Class MyObject
Dim strText As String
Private Sub MenuItem4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MenuItem4.Click
strText = RichTextBox1.SelectedText.Replace(ControlChars.Lf, ControlChars.CrLf)
Clipboard.SetDataObject(strText, True)
End Sub
End ClassNow, strText won't go out of scope until the class it's in is destroyed. It is now visible to all the subs/functions in the class. Are you trying to keep an object from being destroyed before your finished with it? We need to see a little sample code to figure out whats going on. Buttons: Buttons (and just about all controls) are created on the thread the form is on, not seperate ones. We need a couple more details about what your ultimately trying to do. RageInTheMachine9532
-
OK...Well, as far as I can tell, your method of "preventing an object from going out of scope" won't work. Scope isn't controlled by how long an object lives, it's the other way around. As an example:
Public Class MyObject
Private Sub MenuItem4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MenuItem4.Click
Dim strText As String
strText = RichTextBox1.SelectedText.Replace(ControlChars.Lf, ControlChars.CrLf)
Clipboard.SetDataObject(strText, True)
End Sub
End ClassThe object 'strText' goes out of scope when you get to End Sub because strText was declared inside the sub and is not visible outside this sub. But if you change when the object is declared, you also change its scope:
Public Class MyObject
Dim strText As String
Private Sub MenuItem4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MenuItem4.Click
strText = RichTextBox1.SelectedText.Replace(ControlChars.Lf, ControlChars.CrLf)
Clipboard.SetDataObject(strText, True)
End Sub
End ClassNow, strText won't go out of scope until the class it's in is destroyed. It is now visible to all the subs/functions in the class. Are you trying to keep an object from being destroyed before your finished with it? We need to see a little sample code to figure out whats going on. Buttons: Buttons (and just about all controls) are created on the thread the form is on, not seperate ones. We need a couple more details about what your ultimately trying to do. RageInTheMachine9532
Hey Rage, I think we are about to run up each other's backside here 8-) I understand all about scope so I am not sure what you're trying to explain. I also understand that I am typing questions like a shell shocked idiot 9-) My object get's finalized apparently without ever seeing a call to Dispose. So this is a sequence issue. My sub Finalize was called without me ever having called Dispose, that's impossible when I look at my example sub routine. The odd thing is the only call on the stack was Finalize, so who the hell called it? If the CLR called it then why did it? I haven't let the object go, if I had I would have called finalize first. Look, I think this problem has strangely gone away...but the very strange thing is that when I put my MsgBox trace in a ton of them came up, they didn't come up one at a time and wait for one to be dismissed before the next one came up. That's what made me think loads of threads had been created to draw each of my controls. If that was true I would have layed an egg! 8-) I think for somereason, which is most likely attributable to me hitting a problem then moving to a different part of my project whilst a I think about it, I just seem to get strange behavior, which when my code stablises again, things all seem to come out shiney and new again! Still, I have a problem of having toolbox bitmaps assigned to my controls in the control library and only two of the four controls display their bitmaps. At design time, the enabled property of my control seems to stay at true, even when the property grid says false. These are all things that when I return to sanity, I am sure will get worked out, but sometimes its very hard to believe things are as stable in .NET as they should be when at times my Property window won't open, until I exit and restart, or I start to see call stacks with only a destructor on them. All these little "sometimes" bugs just unnerve me. Thanks anyway. Nursey
-
Hey Rage, I think we are about to run up each other's backside here 8-) I understand all about scope so I am not sure what you're trying to explain. I also understand that I am typing questions like a shell shocked idiot 9-) My object get's finalized apparently without ever seeing a call to Dispose. So this is a sequence issue. My sub Finalize was called without me ever having called Dispose, that's impossible when I look at my example sub routine. The odd thing is the only call on the stack was Finalize, so who the hell called it? If the CLR called it then why did it? I haven't let the object go, if I had I would have called finalize first. Look, I think this problem has strangely gone away...but the very strange thing is that when I put my MsgBox trace in a ton of them came up, they didn't come up one at a time and wait for one to be dismissed before the next one came up. That's what made me think loads of threads had been created to draw each of my controls. If that was true I would have layed an egg! 8-) I think for somereason, which is most likely attributable to me hitting a problem then moving to a different part of my project whilst a I think about it, I just seem to get strange behavior, which when my code stablises again, things all seem to come out shiney and new again! Still, I have a problem of having toolbox bitmaps assigned to my controls in the control library and only two of the four controls display their bitmaps. At design time, the enabled property of my control seems to stay at true, even when the property grid says false. These are all things that when I return to sanity, I am sure will get worked out, but sometimes its very hard to believe things are as stable in .NET as they should be when at times my Property window won't open, until I exit and restart, or I start to see call stacks with only a destructor on them. All these little "sometimes" bugs just unnerve me. Thanks anyway. Nursey
Your right about the CLR. The garbage collector will call Finalize (never calls Dispose) when your object falls out of scope. You can't really hold it open without it actually being referenced. I haven't seen the code so I don't know exactly what your doing. I don't mean to make anyone out to be stupid, and, frankly, I wrote the entire message and posted it before I figured out it was you. (Just look at the name - Duh! :-O) Sorry! RageInTheMachine9532
-
Your right about the CLR. The garbage collector will call Finalize (never calls Dispose) when your object falls out of scope. You can't really hold it open without it actually being referenced. I haven't seen the code so I don't know exactly what your doing. I don't mean to make anyone out to be stupid, and, frankly, I wrote the entire message and posted it before I figured out it was you. (Just look at the name - Duh! :-O) Sorry! RageInTheMachine9532
s'ok mortal, I forgive yah! 8-) The whole point is that I was calling Dispose before the CLR could finalize it. It's horrible when problems like this just go away though, coz you wonder what the hell your code could be doing that would cause this. It's like returning to the bad old days of C/C++ and corrupting memory or the krapping on the stack! Ah, them were the days. Perhaps I need to get my hands on a decent trace tool. Do you know of any good free trace tools out there? Nursey. Nursey
-
s'ok mortal, I forgive yah! 8-) The whole point is that I was calling Dispose before the CLR could finalize it. It's horrible when problems like this just go away though, coz you wonder what the hell your code could be doing that would cause this. It's like returning to the bad old days of C/C++ and corrupting memory or the krapping on the stack! Ah, them were the days. Perhaps I need to get my hands on a decent trace tool. Do you know of any good free trace tools out there? Nursey. Nursey
I remember those days! Oh what fun! Try overriding the Finalize event and move the Displose code to it? Can't say I know of any good trace tools that don't cost an arm and a leg! RageInTheMachine9532