gizmo83

ok heres a sniplet of my code:




Sub RefreshPics(FormName As String)

If FormName = "form1" Then
Dim FormName2 As Form1
End If


Dim lFoundPos As Long

Dim lFindLength As Long

Dim MakeSure As Boolean

GoTo Skip
Start:
MakeSure = True
Skip:

lFoundPos = FormName2.txtout.Find(">", 0, , rtfNoHighlight)

End Sub





When i call this i get an error that reads:
Object Varible or With block varible not set

and when i debug it says its on the line that reads:
lFoundPos = FormName2.txtout.Find(">", 0, , rtfNoHighlight)




anyone know why??? what am i doing wrong? now on that line if i change FormName2 to Form1 then it works fine... but i check and FormName2 is set to Form1 (with dim FormName2 as Form1)

gallicus

Don't you have to use the 'Set' when you create an instance of a form?

Set Formname2 = new Form1

polarbear199

I'm not the best to answer this one but I'll try. Do you have the properties set to Option Explicit? If you do then I think I see the problem.

The only way this line will work without error...
lFoundPos = FormName2.txtout.Find(">", 0, , rtfNoHighlight)

is if this little bit of code is found true.
If FormName = "form1" Then
Dim FormName2 As Form1
End If

My guess is that FormName not = "form1" and your FormName2 variable is never set.

I hope this is a help. Let me know will you?

jayceepoo

To solve your problem you have to instantiate FormName2 like this.

If you put the new key word in there it will actually create the form, otherwise, the memory is just being set aside for the form.

And by the way, if you use the code i mentioned before, you do not need to use the Set keyword.

If you want the use Set, you have to do it like this.
Hope I helped....

ChiefRedBull

jayceepoo - while that will work, it is better to use the method that gallicus suggested above, because there is less overhead involved. When you Dim an object variable as New, VB has to check if the object has been created each time it is used. However, if the Set keyword is used instead, this isn't need, speeding up the access.

Banjo

I hadn't heard that Chief. Why does it need to check each time?

ChiefRedBull

Since the New keyword is used in the Dim statement, it is assumed that no Set will be used. So COM has no way of knowing if the object has been instantiated yet, so it has to check first, by doing a QueryInterface, and if it fails - it creates the object.

When the New keyword isn't used with the Dim, no checking is done, because it is assumed that the object will be instantiated via Set.

Banjo

Surely it should be the other way around. If the New keyword is used as part of the Dim then the object should always be valid (unless you set it to Nothing). If it isn't then it would have check every time to check.

ChiefRedBull

But the object is only instantiated the first time it is used. Since COM doesn't know when this is, it has to check every time.

Volte

I believe that when using New within the Dim statement,
the instance of the object is not created until the first reference
of it, whereas when using Set, the object in instantiated
immediately.

Edit: Argh. I went off to MSDN to verify it, and Chief already posted.

Volte

When an object is created, regardless of the method used, is it
not always in memory? I thought that the QueryInterface only happened
once, and that is when the object is initialized (Set statement or
otherwise).

Banjo

Ah, now that's the info I was missing. I figured that it was created with the New keyword every time.

ChiefRedBull

Volte - you're right, once created it is in memory, but - there is no flag set anywhere to say that it has been created, so, COM has to check it via QueryInterface.

When using Set, it is assumed that the programmer will call Set before using the object, so no QueryInterface is needed (only once when it is created). With Dim as New, since it's all done automatically on the first time the object is used, but VB can't tell when the first instance is, it has to check each time if it's been created yet.

I'm not very good at this explaining malarky...

Volte

I understand what you're saying, I just wasn't sure if we both
thought the same thing.

Banjo

And so the "Object variable not set" error that VB throws is just a COM error that is nicely wrapped and handled for you. It is not VB keeping track of which object references are instaniated

ChiefRedBull

I would assume so, yes.

Thinker

I believe the overhead is actually in the code generated by the VB
compiler to check each time the object variable is used. I don't
believe it has anything specifically to do with COM. The way that
Chief described it is otherwise correct (to my understanding).

Banjo

I wasn't suggesting that the overhead was part of COM. I was saying that due to the VB implementation, the, when you get an Object variable not set error, it is just a COM error that VB is wrapping nicely for you rather than VB checking if the object is valid. If it was VB doing it then the overhead would be the same regardless of declaration method.

Thinker

Part of what I am saying is that VB isn't just wrapping some COM
error. The overhead comes from using the New keyword as part
of the object variable declaration. This isn't a COM thing. Let me
give you an example. Look at this code...
Since the word New was used in the declaration, code has to be
inserted in all three subs to check if cn has been instantiated, and
if not then automatically do it. It isn't just trying to use the object
and then trapping the error and then instantiating the object.
If New isn't in the declaration, VB will raise the Object variable not
set error, but I don't think it is just passing an error through from
COM, it is actually checking the object pointer to see if it points to
a valid object.

Banjo

No, no. I understand what you are saying. I was refering to the case where you don't use new in the dim statement. In that case VB does not check that the object has been instantiated, correct? So if you don't Set it then you receive an error if you try to use it. I was assuming that the error was not VB generated as that would require VB to check the object's validity, hence making this method as slow as the inline New.