what is a difference between function,sub and property

plz need urgent hekp...i have different qustions
What is a default value assign to variable which is not intilized in VB 6.0?
What is adifference between class and module in vb 6.0?
What is a difference between function,sub and property in vb 6.0?
what is a difference between if we call function like
call functionname
and call it with using word call just write function name in vb 6.0
functionname?

Quote:

---

Originally Posted by faryalkhan

What is a default value assign to variable which is not intilized in VB 6.0?

---

Depends on what you assign that value. If you do no declare, VB will just assume. Always declare your variables.

Quote:

---

Originally Posted by faryalkhan

What is adifference between class and module in vb 6.0?

---

The main difference between classes and modules is that classes can be initialized as objects while standard modules cannot.

Quote:

---

Originally Posted by faryalkhan

What is a difference between function,sub and property in vb 6.0?

---

A function returns a value.

VB Code:

Public Function Hello() As String
      Hello = "Hello!"
End If
 
MsgBox Hello() 'This will return "Hello!"

A sub is really just like a function, but returns no value. They are used if you have a repetitive thing you need to do. Instead of making 1000 lines of code each time you need to do it, you create a sub to do it, and call that sub.

A property, if I'm not mistaken, if the value assigned to a control.

Like..

VB Code:

Text1.Width = 1000

Quote:

---

Originally Posted by faryalkhan

what is a difference between if we call function like
call functionname
and call it with using word call just write function name in vb 6.0
functionname?

---

Once again, if I'm not mistaken, it really doesn't matter.

Generally I call subs like..

VB Code:

Call SubRoutine()

but this also works..

VB Code:

SubRoutine

To all you VB6 vets, correct me if I'm wrong. :D

Quote:

---

Originally Posted by faryalkhan

What is a default value assign to variable which is not intilized in VB 6.0?

---

That depends on the type of variable. Strings are null, numerics are 0 and booleans are false.

Quote:

---

what is a difference between if we call function like
call functionname
and call it with using word call just write function name in vb 6.0
functionname?

---

Since functions return values you don't call functions, you use the return values, like i = intFunction
Calling a function or referencing it with just the name throws the return away and wastes code and time. If you're not going to use the return value make it a sub instead of a function.

Quote:

---

Originally Posted by Al42

That depends on the type of variable. Strings are null

---

That's not really correct, a string would contain an empty string "" which is something completly different from NULL.

Quote:

---

Originally Posted by Joacim Andersson

That's not really correct, a string would contain an empty string "" which is something completly different from NULL.

---

it wouldn't be an empty string either, it'd be the equivalent of vbNullString.

I personally prefer to do

Dim sSomething As String
sSomething = vbNullString

instead of doing
sSomething = ""
:)

Quote:

---

Originally Posted by bushmobile

it wouldn't be an empty string either, it'd be the equivalent of vbNullString.

---

It doesn't matter what address the string points to, it's still an empty string as far VB is concerned.

Quote:

---

Originally Posted by BrailleSchool

I personally prefer to do

Dim sSomething As String
sSomething = vbNullString

instead of doing
sSomething = ""

---

... and if you like to do it that way then keep doing it. The reason it is slightly faster to assign vbNullString compared to assigning "" is because vbNullString is a named constant already created by VB while "" is a new string that VB first have to create before it can assign it to your variable. However assigning vbNullString to a VB string doesn't mean that your string will be the same as vbNullString, it means it will only contain the same thing, which would be an empty string.

Quote:

---

Originally Posted by Joacim Andersson

It doesn't matter what address the string points to, it's still an empty string as far VB is concerned.... and if you like to do it that way then keep doing it. The reason it is slightly faster to assign vbNullString compared to assigning "" is because vbNullString is a named constant already created by VB while "" is a new string that VB first have to create before it can assign it to your variable. However assigning vbNullString to a VB string doesn't mean that your string will be the same as vbNullString, it means it will only contain the same thing, which would be an empty string.

---

that's not true. there is a big difference between assigning "" to a string or vbNullString. and the fact that vbNullString is faster has nothing to do with the fact that it is a constant. btw... "" is a constant as well.

VB Code:

Public Sub StrTest()
    Dim sTest As String
    
    Debug.Print StrPtr(sTest)
    
    sTest = vbNullString
    Debug.Print StrPtr(sTest)
    
    sTest = ""
    Debug.Print StrPtr(sTest)
    
    sTest = vbNullString
    Debug.Print StrPtr(sTest)
    
End Sub

vbNullString creates an empty or uninitialized string (no memory allocated) whereas "" creates a string witch only contains two bytes (double null terminator) and the 4 bytes length filed (at least 6 bytes allocated)

:rolleyes:

@Agilaz: Of course "" is a constant (however it's not a named constant which I was talking about), so is "Hello World" but in both cases they are strings that VB has to create. VB also have to create vbNullString but when your application runs that is already done so assigning that to another string variable will be faster because of that fact. So vbNullString doesn't create anything... It's already a created string.

It's wrong to state that vbNullString doesn't have any memory allocated to it, vbNullString is a BSTR that simply points to 0. But all of this isn't that important for VB, since it doesn't compare or assign memory addresses when you compare or assign values to a string (or any other type), what VB do is copying the value. So as far as VB is concerned vbNullString is simply an empty string. The real use of vbNullString (and why it was added to VB) is for API calls that accepts a string or a NULL value. So you can pass NULL to the function without changing the API declaration to accepts a Long (ByVal) and pass 0.

We can go on discussing how VB handles its BSTR type strings but that wasn't my intention with my origional reply. Stating that an uninitilized string in VB is the same as NULL is still not really true, but it also depends on what we mean when we talk about NULL. For a C programmer NULL is simply 0 or a pointer to 0. But that is not the same thing as the NULL value a field in a database might contain. The NULL value from a database can really only be assigned to a Variant in VB but the value is pretty useless since you can't do anything with it. You can't even simply check if the value is NULL with the normal comparison operator since every boolean operation with a NULL value can only result in NULL which is neither True or False (so we need to use the IsNull function).

This is the second time in a little over a week that this debate of null strings and empty strings has attempted to actually become meaningful :D

And it really doesn't matter.

If one of my programmers ever wrote If strValue = vbNullString Then instead of If strValue = "" Then I would slap them upside the head (but that's just me!) - constants are great for magic numbers - like vbTab or vbKeyUp or vbKeyReturn.

vbNullString does not increase readability - only increases typing.

Quote:

---

Originally Posted by Joacim Andersson

@Agilaz: Of course "" is a constant (however it's not a named constant which I was talking about), so is "Hello World" but in both cases they are strings that VB has to create. VB also have to create vbNullString but when your application runs that is already done so assigning that to another string variable will be faster because of that fact. So vbNullString doesn't create anything... It's already a created string.

---

and again that's not true. constants like "Hello World" doesn't need to be 'created' when you run a complied program. they are already created by the compiler. there's no difference between a named constant and a constant anymore. both are stored inside the executable and are ready to use.

Quote:

---

It's wrong to state that vbNullString doesn't have any memory allocated to it, vbNullString is a BSTR that simply points to 0. But all of this isn't that important for VB, since it doesn't compare or assign memory addresses when you compare or assign values to a string (or any other type), what VB do is copying the value. So as far as VB is concerned vbNullString is simply an empty string. The real use of vbNullString (and why it was added to VB) is for API calls that accepts a string or a NULL value. So you can pass NULL to the function without changing the API declaration to accepts a Long (ByVal) and pass 0.

---

all i say is run that code and watch the memory usage of the program before and after pressing command1 and then after pressing command2.

VB Code:

Option Explicit
 
Private sStringArray(1000000) As String
 
Private Sub Command1_Click()
    Dim lngLoop As Long
    
    For lngLoop = 0 To UBound(sStringArray)
        sStringArray(lngLoop) = ""
    Next lngLoop
End Sub
 
Private Sub Command2_Click()
    Dim lngLoop As Long
    
    For lngLoop = 0 To UBound(sStringArray)
        sStringArray(lngLoop) = vbNullString
    Next lngLoop
End Sub

i don't know if that isn't an important difference for you, but it is for me.

An array with a million entries is not a common thing in programs we develop here.

For uncommon requirements extreme measures are sometimes needed ;)

Quote:

---

Originally Posted by szlamany

If one of my programmers ever wrote If strValue = vbNullString Then instead of If strValue = "" Then I would slap them upside the head (but that's just me!) - constants are great for magic numbers - like vbTab or vbKeyUp or vbKeyReturn.

---

What... why... that's horrible! They're both horrible!

If LenB(strValue) = 0 Then

So much better! I feel good and relaxed!


(I adjusted my comment to the quality of the thread)

wasting a few bytes here and wasting another few bytes there...who cares. modern computers have lots of memory and fast CPUs, right? ;)

...and good programmers get slapped upside their head :sick:

@merri - the LENB() trick is great - just like Right("00"+CStr(lngVal),2) will right-justify a number with leading zeroes (way faster then a FORMAT() call). Some tricks we do here and some we don't - we gotta live with each other and conventions are more important then anything else.

I'm glad you are relaxed now :p

@agilaz - I want to slap coders upside the head constantly - but instead I just grit my teeth and explain for the 100th time why something has to be done this way and tested that way and blah, blah, blah, blah...

@szlamany

i'm glad you're not my boss. i'm sure one day you'd slap me :lol:

Quote:

---

Originally Posted by Agilaz

all i say is run that code and watch the memory usage of the program before and after pressing command1 and then after pressing command2.

---

And all that does is confirming what I've already said... When you use "" VB will create a new string every time you run it and of course that will consume a lot more memory than one that is already created.

Constant like "" or for that matter "Hello World" (or whatever) will NOT be created by the compiler during compile time simply because if that would be the case they would exist during the life time of your application. Local variables and values will be created and destroyed every time you execute a Sub/Function. They are not created during compile time. That is the difference between a local value and a global (or public) value. vbNullString is on the other hand not a local value so that is created during compile time regardless if you use it or not.

The LenB trick is also quicker than using an empty string since VB simply doesn't have to create a new string if you use that. The VB string handling is so slow that even the overhead of calling a function like LenB is faster. It is however a myth that using LenB instead of the Len function on a string would be faster... It IS NOT. The Len function used on a string will simply look at the BSTR memory location that mention the length of the string, while LenB would need to do a calculation of that value to come up with the correct result.

Joacim: I have tested the speed of LenB and seen it is indeed faster; I wouldn't use it otherwise. And I'm not the only one who has done this test. So why it is faster? The length of the string is stored as a number of bytes and not as a number of characters as you claim in your post. Basically Len is LenB \ 2, except that Len is faster than doing LenB \ 2 with VB code (which I've also tested out of curiosity).

LenB is also faster in this case for the pure fact it simply makes a copy of 32 bits from the position StrPtr - 4 returning that value, then all that VB needs to do is a value comparison... and nothing is faster with modern processors than doing a comparison of two 32-bit values, Long is the fastest datatype in VB6.


vbNullString doesn't really even exist in memory; it doesn't point to anywhere. It is not "created" at all. When you use it on a string variable, that string variable's pointer is erased to zero; basically, the only thing that is done is that old string is marked as free area in memory and string's pointer is erased. This is the great difference between vbNullString and "": compiled code of vbNullString is only half the job.

Huh ..? I read vbNullString is faster than using "" .. regardless of how it is being called, just in general .. was I Scammed??

Hmmm, i use Len( etc ... what is the diff between LenB and Len???

also, is this faster
If LenB(Text$) Then

instead of ..
If LenB(Text$) <> 0 Then

Quote:

---

Originally Posted by Merri

vbNullString doesn't really even exist in memory; it doesn't point to anywhere. It is not "created" at all. When you use it on a string variable, that string variable's pointer is erased to zero; basically, the only thing that is done is that old string is marked as free area in memory and string's pointer is erased. This is the great difference between vbNullString and "": compiled code of vbNullString is only half the job.

---

Of course it is created... It's a named constant , VB needs to create the constant and store that in memory. The fact that it's a pointer to 0 is beside the point. But otherwise you are correct.

Quote:

---

Originally Posted by szlamany

This is the second time in a little over a week that this debate of null strings and empty strings has attempted to actually become meaningful :D

And it really doesn't matter.

If one of my programmers ever wrote If strValue = vbNullString Then instead of If strValue = "" Then I would slap them upside the head (but that's just me!) - constants are great for magic numbers - like vbTab or vbKeyUp or vbKeyReturn.

vbNullString does not increase readability - only increases typing.

---

if i have to type more to make the app a little faster then fine by me hehe.
none-the-less, as it has been seen a billion times on VBF and in any kind of publication/company.... people have their own likes and personal preference. what one coder "likes", another isnt going to "like". im sure that facts been proven time and time again already :)

will have to look more into LenB though. sounds interesting.

I can't find any difference in speed between Len and LenB. I ran the following code in compiled form with all optimizations turned on and sometimes LenB was reported slightly faster and at others Len was faster (as expected if they would run at the same speed).

VB Code:

Private Declare Function GetTickCount Lib "kernel32.dll" () As Long
 
Private str As String
 
Private Sub LenBTest()
    Dim x As Long
    x = LenB(str)
End Sub
 
Private Sub LenTest()
    Dim x As Long
    x = Len(str)
End Sub
 
Private Sub Main()
    Dim n As Long
    Dim t As Long, t1 As Long
    'Create a 64K string
    str = String(65535, "A")
    'Run the LenB test
    t = GetTickCount
    For n = 0 To 5000000
        LenBTest
    Next
    t = GetTickCount - t
    'Run the Len test
    t1 = GetTickCount
    For n = 0 To 5000000
        LenTest
    Next
    t1 = GetTickCount - t1
    'Report:
    MsgBox "LenBTest: " & t & vbCrLf & "LenTest: " & t1
End Sub

I admit that GetTickCount isn't the most reliable timer but that isn't too important in this test you can just add/subtract 10 ms from the result which makes no difference to the test itself.

All in all the speed difference that might exist between these two functions can be ignored even in an application in which you really need every bit of speed you can get... If it would be that important for the speed I would on the other hand write the code using another tool besides VB. I use VB for the speed of development not for the speed of the source, the speed difference between most C and VB applications aren't important at all for the user.

The search for speed might be interesting for study purposes but I have not yet found a client that is willing to pay me the extra it would cost them for the time it would take me to cram a few extra milliseconds out of their business application. They want it done and have it working, preferably yesterday.

As I already mentioned, if I really is in the need of speed I go with a different tool and develop it in C or Delphi with inline assembler if necassary.

You made the classic VB6 benchmarking mistake: you ran benchmarkings in the same sub. For an odd reason I haven't yet discovered a reason to is that if you do two benchmarks in one procedure, both or either one's results are biased a bit. The only way I have found to be reliable to run benchmark is to add the testable code within a command button and click it multiple times to be sure of the general result line it gives; and it must test only one code at once.

Separate the benchmarks and then tell what you can see.


Also, you're benchmarking a lot more than just Len and LenB there. You're timing a procedure call, a creation of a variable and so on. Those things even the difference quite a bit.

What's the difference between function, sub and property? :eek2:

I feel sorry for the original poster!

Wasn't the question answered already, so we're entirely free to offtopic? :D

Sub is faster than Function which is faster than a Property. There you go. Ontopic!

Quote:

---

Originally Posted by Merri

You made the classic VB6 benchmarking mistake: you ran benchmarkings in the same sub. For an odd reason I haven't yet discovered a reason to is that if you do two benchmarks in one procedure, both or either one's results are biased a bit.

---

As I mentioned in my (edited) post above I'm not interested in that. The speed difference is so small that it just doesn't matter. Even when runned 5 million times the speed difference is ignorable and I have yet to write an application in which I use either Len or LenB more then a few times. The time it would take Windows and my application to send and respond to the actual event (of clicking a button for example) is much larger then it would take to run either the Len or LenB function. It's my opinion that those searching for that extra millisecond of speed often try to filter mosquitoes while swollowing camels. :)

Quote:

---

Originally Posted by Merri

Sub is faster than Function which is faster than a Property. There you go. Ontopic!

---

Well, that would also depend on how the property is implemented. A property is data within a class and could (even though it's not recommended) simply be implemented as a public variable. In VB we have the special property procedures, in Delphi, for example, properties are implemented as pointers that either point to a procedure (sub or function) or a private variable (or both, one for reading and one for writing the value). Of course you may now say that this isn't a Delphi forum and you would be correct however I might be using a COM component written in Delphi.

Quote:

---

Originally Posted by Joacim Andersson

And all that does is confirming what I've already said... When you use "" VB will create a new string every time you run it and of course that will consume a lot more memory than one that is already created.

---

ok, let's try another named costant, vbcr for example. if the above said is true the difference in memory usage should'nt be that big anymore as no new string needs to be crated this time.

VB Code:

Option Explicit
 
Private sStringArray(1000000) As String
 
Private Sub Command1_Click()
    Dim lngLoop As Long
    
    For lngLoop = 0 To UBound(sStringArray)
        sStringArray(lngLoop) = vbCr '  another named constant 
    Next lngLoop
End Sub
 
Private Sub Command2_Click()
    Dim lngLoop As Long
    
    For lngLoop = 0 To UBound(sStringArray)
        sStringArray(lngLoop) = vbNullString
    Next lngLoop
End Sub

now how do you explain that?

Quote:

---

Constant like "" or for that matter "Hello World" (or whatever) will NOT be created by the compiler during compile time simply because if that would be the case they would exist during the life time of your application. Local variables and values will be created and destroyed every time you execute a Sub/Function. They are not created during compile time. That is the difference between a local value and a global (or public) value. vbNullString is on the other hand not a local value so that is created during compile time regardless if you use it or not.

---

and how do you explain the following ...

VB Code:

Option Explicit
 
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (lpvDest As Any, lpvSrc As Any, ByVal cbLen As Long)
 
Private lngStrPtr As Long
 
 
Private Sub Command1_Click()
    
    'get the pointer to the constant string
    lngStrPtr = StrPtr("i'm a local constant! once you know where i'm located, you can use me in any sub or function!")
    
End Sub
 
Private Sub Command2_Click()
    Dim sTest As String, lngOldPtr As Long
 
    'make sTest point to the constant
    CopyMemory ByVal VarPtr(sTest), lngStrPtr, 4&
    
    MsgBox sTest
    
    'clean up and restore the old string pointer (NULL)
    CopyMemory ByVal VarPtr(sTest), vbNullString, 4&
    
End Sub

click command1 then command2.

Quote:

---

Originally Posted by Agilaz

and how do you explain the following ...

VB Code:

Option Explicit
 
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (lpvDest As Any, lpvSrc As Any, ByVal cbLen As Long)
 
Private lngStrPtr As Long
 
 
Private Sub Command1_Click()
    
    'get the pointer to the constant string
    lngStrPtr = StrPtr("i'm a local constant! once you know where i'm located, you can use me in any sub or function!")
    
End Sub
 
Private Sub Command2_Click()
    Dim sTest As String, lngOldPtr As Long
 
    'make sTest point to the constant
    CopyMemory ByVal VarPtr(sTest), lngStrPtr, 4&
    
    MsgBox sTest
    
    'clean up and restore the old string pointer (NULL)
    CopyMemory ByVal VarPtr(sTest), vbNullString, 4&
    
End Sub

click command1 then command2.

---

The only thing that proved is that you may read from the memory already allocated by the program. The local string is no longer in use however the memory haven't been overwritten by something else yet so it still contains the same text. I fail to see the point.

Quote:

---

Originally Posted by Joacim Andersson

The only thing that proved is that you may read from the memory already allocated by the program. The local string is no longer in use however the memory haven't been overwritten by something else yet so it still contains the same text. I fail to see the point.

---

i knew you would say something like that :p

so how about this...

VB Code:

Option Explicit
 
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (lpvDest As Any, lpvSrc As Any, ByVal cbLen As Long)
Private Sub Command1_Click()
    Dim lngStrPtr As Long
    Dim ff As Integer
 
    'get the pointer to the constant string
    lngStrPtr = StrPtr("i'm a local constant! once you know where i'm located, you can use me in any sub or function!")
    
    'write the pointer to a file
    ff = FreeFile
    Open App.Path & "\strptr.bin" For Binary As #ff
    Put #ff, , lngStrPtr
    Close #ff
    
End Sub
 
Private Sub Command2_Click()
    Dim sTest As String, lngOldPtr As Long, lngStrPtr As Long
    Dim ff As Integer
    
    'get the pointer from the file
    ff = FreeFile
    Open App.Path & "\strptr.bin" For Binary As #ff
    Get #ff, , lngStrPtr
    Close #ff
 
    'make sTest point to the constant
    CopyMemory ByVal VarPtr(sTest), lngStrPtr, 4&
    
    MsgBox sTest
 
    'clean up and restore the old string pointer (NULL)
    CopyMemory ByVal VarPtr(sTest), vbNullString, 4&
    
End Sub

compile it, run it, press command1. close the program. restart your computer if you want. start the program again and press command2.

Hi ,
I have one question?.
What is the diff. between ado and Dao.where we have to use dao and ado.

Quote:

---

Originally Posted by danasegarane

Hi ,
I have one question?.
What is the diff. between ado and Dao.where we have to use dao and ado.

---

This thread will explain: http://www.vbforums.com/showthread.p...=ado+dao+oledb

Quote:

---

Originally Posted by rory

Hmmm, i use Len( etc ... what is the diff between LenB and Len???

---

Since the computer is running on word boundaries, the arithmetic (in the cpu itself) is a bit faster with LenB than Len (which has to figure out a "half step"). The difference isn't much, though.

Quote:

---

also, is this faster
If LenB(Text$) Then

instead of ..
If LenB(Text$) <> 0 Then

---

Since there's an extra test in the second case (actually 2 extra steps - a test for less and a test for more), the first one is smaller and should execute faster. You could speed the second one up by just dropping the '<' - the length can't be less than 0. (Same thing with If strString <> "" - it can't be less than "".)