asked on Access VBA User type not User-defined type not defined
Hi
I get the error "User-defined type not defined" in the first line of the following code
I get the error "User-defined type not defined" in the first line of the following code
Sub DisplayTextFile()
Dim fso As New FileSystemObject
Dim t As TextStream
Dim strFilePath As String
Dim strBuffer As String
strFilePath = "C:\test.txt"
If fso.FileExists(strFilePath) Then
Set t = fso.OpenTextFile(strFilePath, ForReading, False)
strBuffer = t.ReadAll
MsgBox strBuffer
t.Close
End If
Set t = Nothing
End Sub
Microsoft AccessVBA
Last Comment
Murray Brown
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Just a comment:
The existence check is not necessary, cause it is prone to a race condition. File could be deleted between the exists call and opening it.
Just use an appropriate error handler for the open call.
Further reason for error handling instead of defensive development:
The exists call can return true, but the open call can fail on the open, when the file still exists. E.g. when the file is locked.
The existence check is not necessary, cause it is prone to a race condition. File could be deleted between the exists call and opening it.
Just use an appropriate error handler for the open call.
Further reason for error handling instead of defensive development:
The exists call can return true, but the open call can fail on the open, when the file still exists. E.g. when the file is locked.
That's not the only problem....you also loose performance (10-15%)Sorry but fake argument, with today's computers running at lightning speed, the peformances decrease isn't even noticeable.
Plus, VBA isn't designed for high performances since it is an interpreted language.
On the other hand, early binding is a source of troubles with heterogeneous environment (wich happen more often than you think).
<<Sorry but fake argument, >>
No, it's not an argument, but a statement of fact. If you late bind, any statement dealing with that reference will be 10-15% slower because it has to resolve it at runtime. Those are tangible CPU cycles, not something that disappears because a machine happens to be faster. Whether you consider that important or not depends on the situation.
Even with today's computers, you can still notice the difference. For example, if I was writing a an app that worked with thousands of e-mails at a time, you'd bet I'd early bind. However if I have an app that sent only a handful of e-mails throughout a day, then yes, it would make little difference.
So he needs to be aware of the difference, and then decide what's best for his situation.
Jim.
No, it's not an argument, but a statement of fact. If you late bind, any statement dealing with that reference will be 10-15% slower because it has to resolve it at runtime. Those are tangible CPU cycles, not something that disappears because a machine happens to be faster. Whether you consider that important or not depends on the situation.
Even with today's computers, you can still notice the difference. For example, if I was writing a an app that worked with thousands of e-mails at a time, you'd bet I'd early bind. However if I have an app that sent only a handful of e-mails throughout a day, then yes, it would make little difference.
So he needs to be aware of the difference, and then decide what's best for his situation.
Jim.
ASKER
thanks
You need to set a reference to the "Microsoft Scripting Runtime" in VBA, which the File System Object is part of.
Jim.