|
That why i'm asking,
Set nothing to collection, it won't free or remove the items of the collection.
|
|
|
|
|
Well, if the collection is the only place a reference to the objects exists, then they are orphaned and will be GC eventually. But, if you have other references to them, then no
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 )
|
|
|
|
|
This collection only the reference to the object. so do i need to remove the item and delete it by external?
|
|
|
|
|
Depends. If they are objects that have a Dispose method, then yes, you should call the Dispose method. If not, what can you do ? you can't delete the objects, this is a GC environment, remember ?
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 )
|
|
|
|
|
|
Let's see exactly what happens with your code...
Dim MyCollect as Collection
Set MyCollect = new Collection
Dim Data as Integer
So far nothing surprising. A reference variable is declared, an object is created and it's reference is stored in the variable, and an integer variable is declared.
Data = 1
MyCollect.Add Data
Here it starts to get interresting. You can only store reference types (i.e. objects) in a collection. As an integer is a value type, it can not be stored in the collection, so what happens is that a new object is created automatically, and the integer value is copied to that object. This is called boxing.
Data = 2
MyCollect.Add Data
Data = 3
MyCollect.Add Data
Here you are saved by the boxing. If Data would have been a reference type, the collection would contain a reference and not a separate object, so you would change the contents of the only one object, and you would have ended up with a collection that contained three references to the same object. The boxing creates separate objects for each value, so you get three separate objects in the collection.
What happens after this statement is where it gets really interresting. As the collection isn't used any more in the code, it's now eligible for garbage collection. The garbage collector can determine that the reference to the collection is never read after this, so the reference is deemed inactive from here on. Eventhough the variable contains a reference to the collection, it doesn't count as the reference is inactive, so there are no longer any active references to the collection.
If a garbage collection would happen at this point in the code, the collection and all the objects that it contains could (and most likely would) be garbage collected.
Set MyCollect = Nothing
This statement actually serves no purpose what so ever in your code. As the garbage collector knows that the reference is alredy inactive at this point, you can put whatever you like in the reference, and it will not change how any objects are garbage collected in any way.
Despite everything, the person most likely to be fooling you next is yourself.
modified on Thursday, June 26, 2008 7:23 AM
|
|
|
|
|
In my actual code that is reference type only. and also collection item used in my actual code (using the collection item i did something), at the end i just set nothing to the collection. is it really remove the collection items and delete the items object.
See the sample
Dim MyCollect as Collection
Set MyCollect = new Collection
Dim Nd as Node 'Node - is a our own class object.
MyCollect.Add Nd 'Add 10/15 object to the collection
'Iterate MyCollect and using it by MyCollect.Item(i)
Set MyCollect = Nothing 'What happend in this line.
Is it really remove the items (10/15) and delete object (Node)?
|
|
|
|
|
Sakthivel P wrote: Set MyCollect = Nothing 'What happend in this line.
Is it really remove the items (10/15) and delete object (Node)?
No, it doesn't.
As I explained, the collection and all that it contains (assuming that there are no other references to it) are up for garbage collection from the moment that it's not used any more. By the time that you set the reference to Nothing, the collection is already unreachable, so setting the reference to Nothing accomplishes nothing at all. The garbage collector already knows that the collection is no longer used.
In some cases it can be useful to clear a reference, that is if the variable is a member in a class, or if you use the variable later in the code. However, clearing a reference doesn't cause anything at all to happen. It can make an object unreachable so that it can be garbage collected, but it never causes a garbage collection to happen.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: As I explained, the collection and all that it contains (assuming that there are no other references to it) are up for garbage collection from the moment that it's not used any more. By the time that you set the reference to Nothing, the collection is already unreachable, so setting the reference to Nothing accomplishes nothing at all. The garbage collector already knows that the collection is no longer used.
Does that behavior apply in debug mode, or only in final-build mode? I would expect that the compiler should keep variables around even after the last reference, as long as the procedure is in scope, since the variable could be accessed in many ways (including via the Immediate and Watch windows, or even via late modifications to the code).
|
|
|
|
|
supercat9 wrote: Does that behavior apply in debug mode, or only in final-build mode? I would expect that the compiler should keep variables around even after the last reference, as long as the procedure is in scope, since the variable could be accessed in many ways (including via the Immediate and Watch windows, or even via late modifications to the code).
That is correct. In debug mode all variables stay active as long as they are in scope.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Hi Guys,
Need some advice on downtime management...
I am writing an client-server application in a manufacturing environment that needs to do the ffg.
The client will scan a barcode at the begining of a cycle, say the cycle consists of (A,B,C,D)
At 'A', the scan take place and this barcode needs to be vaildated against the server.
If the barcode is valid then i need to drop the barcode in a text file on the local PC for processing(server has a folder watch on this folder)
This barcode cannot be scanned again until it is released at 'D' and then proceeds back to 'A'.
If for some reason the network/server goes down this scanning process must not stop.
For one i wont be able to validate against the server since there is no connection, but i can still create the text file with the barcode in it.
I would think the best solution would be to create the text file on the local pc, let the folder watch pick up files and validate the file for processing(when online).
Could you help me with other ideas, bearing in mind that the barcode when return to point 'A' (physically) can possibly be scanned again when the system is still offline.
Thanks
Anoop
|
|
|
|
|
Is this a real world situation?
Do you expect the server to fail often?
Are you over engineering the business process?
If the server is so unreliable as to fail regularly then you need to address the server issue. Engineering a software solution to a hardware problem is probably not a good idea.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hi,
The Server and H/ware is good, operating in a stable environment...
but there are factors to be considered. network issues can occur, damaged cabled etc...
i just wanted to know any other ideas,
thanks for your comment though!
|
|
|
|
|
Sure, I agree, thats called disaster recovery (DR) and every organisation needs to address it. The usual SOP is to have a duplicate system off site where processing can continue with the minimum loss of income. Engineering for work interuptions (not DR) may be also valid but only if the ROI is adequate.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I am using VB6 with MS access
If rs1.State = 1 Then
rs1.Close
End If
my control enter in if statement
but give error while closing
|
|
|
|
|
and error given is
Operation is not allowed in this context
|
|
|
|
|
Hiii
Use Rs1=Nothing
mai be is do same work and not throw any error.
Thanx
Mitesh Khatri
|
|
|
|
|
~Khatri Mitesh~ wrote: Use Rs1=Nothing
mai be is do same work and not throw any error.
No, it does not do the same work. Setting a reference to Nothing doesn't close the recordset, it only makes it unreachable.
It's imperative that all recordsets and connections are closed correctly, otherwise the connection to the database remains open until it times out.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Why are you checking the state of the recordset? If you don't know if the recordset is supposed to be open or not, that suggests that the code doesn't really have the firm control over the connections and recordsets that it ought to have.
Have you already closed the connection when this code runs? If you close the connection before the recordset, the recordset might be left in a state where it thinks that it's still connected, but it can't close correctly. You should close all recordsets before you close the connection.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
You might have made changes to the record set without having committed or abandoned them.
In vb6, I believe setting a record set variable to nothing will force an immediate close, though it may generate an error if there are pending changes (the same case where a .close fails). I would consider such code to be very sloppy, however, and it would be likely to cause problems if the code is ported to vb.net.
I have had to work with code that never bothered to close record sets except when trying to reuse them. I see no reason ever to write such code(*), and I have no idea how such practices came into being. Is there some popular book that illustrated the 'global allocate/lazy close' technique? The code is more cumbersome than code which closes record sets when they are no longer needed; using local variables in VB6 or using blocks in VB.net will avoid problems even when connections are left open. So why the kludge?
(*)There are a few cases where it might make sense to leave a record set open even when a program is "idle", if the program needs to be able to respond quickly to asynchronous events. Even in such cases, however, the decision of when to close a connection would be made deliberately.
|
|
|
|
|
My complete code
On Error GoTo religionerror
Dim religion As String
religion = InputBox("Enter Religion", "Religion", "")
If rs1.State = 1 Then
rs1.Close
End If
rs1.Open "select * from religion", cn1, adOpenDynamic, adLockOptimistic
rs1.AddNew
rs1("religion") = religion
rs1.Update
rs1.Close
cmb_religion.AddItem religion
Exit Sub
religionerror:
If Not religion = "" Then
MsgBox "Relgion Already exists Or you Enter Nothing", vbInformation, "SMS WARNING"
End If
End Sub
Its working poperly
but when some error while updating then the code
If rs1.State = 1 Then
rs1.Close
End If
not working properly
|
|
|
|
|
Hi,
I am new to VB and VB.NET. My Application is upgraded from VB6 to VB.NET. But I got some problems as "Couldn't resolve default property of object Me.". How Can I resolve these kind of warnings. Here is my code:
Private ReadOnly Property IParameter_LeseLaenge() As Integer Implements _IParameter.LeseLaenge
Get
'UPGRADE_WARNING: Couldn't resolve default property of object Me. Click for more: 'ms-help://MS.VSCC.2003/commoner/redir/redirect.htm?keyword="vbup1037"'
Return I_IParameter(Me).laenge
End Get
End Property
//I_IParameter method is:
Public Function I_IParameter(ByRef obj As _IParameter) As _IParameter
I_IParameter = obj
End Function
One More:
Public WriteOnly Property SelButton() As System.Windows.Forms.Button
Set(ByVal Value As System.Windows.Forms.Button)
mSelBtn = Value
If mParent.IsAlive Then
'UPGRADE_WARNING: Couldn't resolve default property of object Me. Click for more: 'ms-help://MS.VSCC.2003/commoner/redir/redirect.htm?keyword="vbup1037"'
Parent.AddCtrl(mSelBtn, Me)
End If
End Set
End Property
//AddCtrl method:
Public Sub AddCtrl(ByVal ctrl As System.Windows.Forms.Control, ByVal descriptor As _IFieldDescriptor)
'UPGRADE_ISSUE: ObjPtr function is not supported. Click for more: 'ms-help://MS.VSCC.2003/commoner/redir/redirect.htm?keyword="vbup1040"'
mCtrls.Add(descriptor, CStr(ObjPtr(ctrl)))
End Sub
Could any one of you please let me the solution?
Thanks in Advance.
AR Reddy
|
|
|
|
|
In vb.net Me always refers to the current form... I think if u look ur code with this information u can find the issue
|
|
|
|
|
Thanks, Ill try it out.
AR Reddy
|
|
|
|
|
nishkarsh_k wrote: In vb.net Me always refers to the current form
Wrong, but I can see why you'd think this is true. Me always refers to the current instance of the class in which it is used. Since a Form is nothing but a class, Me works just like it is used in any other class code.
modified on Monday, June 30, 2008 12:37 PM
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
