Open text file with CreateFile API

G

Guest

Hi, All
I am using Windows XP, VS .NET 2003 Windows CE Device platform, i am trying
to convert my application from eVB to VB .NET:
I need to use CreateFile(), GetFileSize, SetFilePointer(), ReadFile(),
CloseHandle()
CreateFile return file handle sometimes negative large number or positive
when i use Err.LastDLLError to check error it is 183 "Cannot create a file
when that file already exists" and GetLastError() returns "-2147482643".
Please, any advice why it is not as easy as in eVB ? see my code below:

Public Const GENERIC_READ = &H80000000
Public Const OPEN_EXISTING = 3
Public Const FILE_BEGIN = 0

<DllImport("coredll.dll", EntryPoint:="CreateFileW", SetLastError:=True)> _
Public Shared Function CreateFile(ByVal lpFileName As String, _
ByVal dwDesiredAccess As Integer, ByVal dwShareMode As Integer, _
ByVal lpSecurityAttributes As Integer, ByVal dwCreationDisposition As
Integer, _
ByVal dwFlagsAndAttributes As Integer, ByVal hTemplateFile As Integer)
As Integer
End Function

sPath = "\Program Files\PTSCOF.DAT"
If rFile.Exists(sPath) = True Then
fHandle = CreateFile(sPath, GENERIC_READ, 0, 0,
OPEN_EXISTING, 0, 0)
lerr = Err.LastDllError
If fHandle <> 0 Then
lsize = GetFileSize(fHandle, 0)
If lsize > 0 Then
outBuffer = New String(CChar(" "), lsize)
SetFilePointer(fHandle, 0, 0, 0)
ReadFile(fHandle, outBuffer, lsize, dwRead, 0)
pos = InStr(1, outBuffer, sSearch, CompareMethod.Text)
End If
If CloseHandle(fHandle) = True Then
End If
End If
 
G

Guest

Hi, Peter
Thank you for reply, i am going to try System.IO, my concern is The text
file about
1 megabytes and i have to perform the search less then a 1 second, i hope it
will be possible with System.IO
But still i wonder why CreateFile return error "183"...
 
S

Stuart Celarier

Elena said:
my concern is The text file about 1 megabytes and i have to perform the
search less then a 1 second, i hope it will be possible with System.IO

Here are a couple words about performance. P/Invoke all by itself has a
significant cost, it is switching between managed and unmanaged code, so
don't assume that making calls down to the unmanaged APIs will always be
faster than working with the Framework Class Library.

Second guessing the .NET managed execution environment is difficult.
People are often surprised that their assumptions about how .NET works
turn out to be incorrect.

Try not to optimize your code too early. Optimizing code is costly,
requiring your time and adding complexity. Instead, write solid code and
then measure the performance. Optimize only when you need additional
performance. And, most important, be sure to actually measure the
performance before and after the optimization: don't assume that a
change actually improves the performance, prove that it does.

Searching a 1 MB file in under 1 second seems a bit ambitious to me, but
a lot depends on how much work needs to be done as part of the search.
For example, organizing the data in the file in order to facilitate
rapid access could be more important than worrying about using System.IO
rather than P/Invoking.

There is a lot of help on performance. For example, see Improving .NET
Application Performance and Scalability [1] from Microsoft Patterns &
Practices.

Cheers,
Stuart Celarier, Fern Creek

[1] http://msdn.microsoft.com/library/en-us/dnpag/html/scalenet.asp
 
G

Guest

Hi,Stuart
Thank you for your advice, what i had in eVB was a Fixed-Lenght record File
and by using CreateFile and ReadFile was really great and search was done
less than a second.

Stuart Celarier said:
Elena said:
my concern is The text file about 1 megabytes and i have to perform the
search less then a 1 second, i hope it will be possible with System.IO

Here are a couple words about performance. P/Invoke all by itself has a
significant cost, it is switching between managed and unmanaged code, so
don't assume that making calls down to the unmanaged APIs will always be
faster than working with the Framework Class Library.

Second guessing the .NET managed execution environment is difficult.
People are often surprised that their assumptions about how .NET works
turn out to be incorrect.

Try not to optimize your code too early. Optimizing code is costly,
requiring your time and adding complexity. Instead, write solid code and
then measure the performance. Optimize only when you need additional
performance. And, most important, be sure to actually measure the
performance before and after the optimization: don't assume that a
change actually improves the performance, prove that it does.

Searching a 1 MB file in under 1 second seems a bit ambitious to me, but
a lot depends on how much work needs to be done as part of the search.
For example, organizing the data in the file in order to facilitate
rapid access could be more important than worrying about using System.IO
rather than P/Invoking.

There is a lot of help on performance. For example, see Improving .NET
Application Performance and Scalability [1] from Microsoft Patterns &
Practices.

Cheers,
Stuart Celarier, Fern Creek

[1] http://msdn.microsoft.com/library/en-us/dnpag/html/scalenet.asp
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top