I'm having trouble using pipes in a larger application and so I created a minimal test application to investigate the problem.
I'm creating a pipe:
Dim sa As SECURITY_ATTRIBUTES
Dim R As Long
sa.nLength = Len(sa)
sa.bInheritHandle = 1
R = CreatePipe(hRead, hWrite, sa, 0) //hRead declared globally
Debug.Print "CreatePipe: " & R
and then I'm reading from it:
Const BufSize As Long = 1024
Dim Buffer(BufSize) As Byte
Dim lBytesRead As Long
Dim R As Long
R = ReadFile(hRead, Buffer(0), BufSize, lBytesRead, 0)
Debug.Print "ReadFile: " & R
Debug.Print Err.LastDllError
Now as far as I understand the ReadFile call should block, because nobody has written any data into the pipe.
The problem: That only happens iff I put the code right after the CreatePipe code. As soon as I put it into a separate function, it fails with the last error being ERROR_INVALID_HANDLE. (I confirmed that the value of hRead does not change)
I have absolutely no idea what's causing this kind of behaviour.
I found the solution myself. It was a rather stupid beginner's mistake, but I found some users having the same problem and since the error symptoms where not at all pointing in the right direction, I'll post my solution.
First I did further refactorings to dumb down the code even more. After making each and every variable global, I finally got a "invalid calling convention" error on the ReadFile call.
To make a long story short, the import declaration and the actual call of ReadFile were wrong for the last parameter (the OVERLAPPED parameter)
This is what I did:
Declare Function ReadFile ..., lpOverlapped As Any) As Long
Call ReadFile(..., 0)
Correct would be any one of these:
Declare Function ReadFile ..., lpOverlapped As Any) As Long
Call ReadFile(..., ByVal 0)
Declare Function ReadFile ..., ByVal lpOverlapped As Long) As Long
Call ReadFile(..., 0)
Declare Function ReadFile ..., lpOverlapped As OVERLAPPED) As Long
Call ReadFile(..., myVariableOfTypeOverlapped)
Related
My software (written in VB6) needs to import csv files that can be large. Users are using copy/paste to place the files in the input folder.
How can I be sure the files I want to read are fully copied before processing them?
Things I tried :
Compare GetFileSizeString over a span of seconds : doesn't work, I get the final value even if the file has just begun to copy.
FileSystemObject.DateLastModified : same
FileSystemObject.DateLastAccessed : same
FileLen : same
FileDateTime : same
EDIT - Added Samba/Linux Info (from comments):
I'm having a hard time dealing with is from Samba/Linux. I don't know why, but when the file is copied by Samba, the read only attribute doesn't matter.
I've used this method which uses the API to test for exclusive access. I've never tried it on a platform other than Windows so, I guess result may vary. I use this in a module of frequently used methods, but I believe I have included the API calls, types, and constants used.
Private Const ERROR_SHARING_VIOLATION = 32&
Private Const GENERIC_WRITE = &H40000000
Private Const INVALID_HANDLE_VALUE = -1
Private Const OPEN_EXISTING = 3
Private Type SECURITY_ATTRIBUTES
nLength As Long
lpSecurityDescriptor As Long
bInheritHandle As Long
End Type
Private Declare Function CloseHandle Lib "kernel32" (ByVal hObject As Long) As Long
Private Declare Function CreateFile Lib "kernel32" Alias "CreateFileA" (ByVal lpFileName As String, ByVal dwDesiredAccess As Long, ByVal dwShareMode As Long, lpSecurityAttributes As SECURITY_ATTRIBUTES, ByVal dwCreationDisposition As Long, ByVal dwFlagsAndAttributes As Long, ByVal hTemplateFile As Any) As Long
Public Function CanOpenExclusive(ByVal vFileName As String) As Boolean
Dim lngResult As Long
Dim udtSA As SECURITY_ATTRIBUTES
On Error GoTo errCanOpenExclusive
If Len(vFileName) > 0 Then
udtSA.nLength = Len(udtSA)
udtSA.bInheritHandle = 1&
udtSA.lpSecurityDescriptor = 0&
lngResult = CreateFile(vFileName, GENERIC_WRITE, 0&, udtSA, OPEN_EXISTING, 0&, 0&)
If lngResult <> INVALID_HANDLE_VALUE Then
Call CloseHandle(lngResult)
CanOpenExclusive = True
Else
Select Case Err.LastDllError 'some errors may indicate the file exists, but there was an error opening it
Case Is = ERROR_SHARING_VIOLATION
CanOpenExclusive = False
Case Else
GoTo errCanOpenExclusive
End Select
End If
End If
Exit Function
errCanOpenExclusive:
Err.Raise Err.Number, Err.Source & ":CanOpenExclusive", Err.Description
End Function
I would use the FileDateTime function to work with to calculate when a date/time value indicating the date and time that a file was created or last modified.
You can read up more on the file system usage HERE.
In the syntax above, pathname is a string expression specifying a valid path (it may optionally include the drive); drive is a string expression specifying a drive letter; and filespec, oldfilespec, and newfilespec are string expressions that specify a file (they may optionally include the drive and path).
Following is a set of functions that can be used with files (all are functions except SetAttr, which is a statement):
Function
Description
Syntax
FileDateTime
Returns a date/time value indicating the date and time that a file was created or last modified.
FileDateTime(filespec)
GetAttr
Returns an integer representing the attributes of a file, directory, or folder
GetAttr(filespec)
SetAttr
Statement that lets you specify the attributes for a file
SetAttr(filespec, attributes)
CurDir$ (or CurDir)
Returns a string that indicates the current path for a specified disk drive. In the syntax on the right, drivename is a string expression that specifies a valid disk drive designation
CurDir$(drivename)
Dir$ (or DIr)
Returns a string that indicates a file or directory matching specified conditions
Dir$(filespec [,attributes])
FileLen
Returns a Long specifying the length of a file in bytes. If the specified file is open when the FileLen function is called, the value returned represents the size of the file immediately before it was opened.
FileLen(pathname)
LOF
Returns a Long representing the size, in bytes, of a file opened using the Open statement.
FileLen(filenumber)
I'm using Visual Basic 6.0 (I know, it's outdated, but what can I say? I'm old-timey like that). I've been trying to get a program to work that makes the mouse click on a predetermined point on the screen after clicking a button (that's not what the whole program will be, but I'm still building it and this is my roadblock)
[System.Runtime.InteropServices.DllImport("user32.dll")]
Private Declare Function mouse_event Lib "user32.dll" Alias "mouse_event()" (ByVal dwFlags As Long, ByVal dx As Long, ByVal dy As Long, ByVal cButtons As Long, ByVal dwExtraInfo As Long)
Private Const MOUSEEVENTF_LEFTDOWN = &H2
Private Const MOUSEEVENTF_LEFTUP = &H4
Public Function Mouse_LeftClick()
mouse_event MOUSEEVENTF_LEFTDOWN, 0, 0, 0, 0
mouse_event MOUSEEVENTF_LEFTUP, 0, 0, 0, 0
End Function
Private Sub Command1_Click()
Dim X As Long
Dim Y As Long
Dim mouse_x As Long
Dim mouse_y As Long
X = CLng(1285)
Y = CLng(134)
mouse_x = CLng(X * 65535 / Screen.Width)
mouse_y = CLng(Y * 65535 / Screen.Height)
i = mouse_event(MOUSEEVENTF_ABSOLUTE + MOUSEEVENTF_MOVE, mouse_x, mouse_y, 0, 0)
n = Mouse_LeftClick()
End Sub
Private Sub Command2_Click()
End
End Sub
(This is literally the entire program so far)
To be clear, I'm relatively new at this, so this code was almost entirely taken from another website. But I have since forgotten what that website was, unfortunately.
Now, before I had that first line there (the DllImport), VB6 was telling me that "mouse_event()" didn't exist in user32.dll -- which, to my understanding, it still doesn't.
Once I researched that problem, though, I found the DllImport line which I placed exactly where the internet told me to place it, but now that very same line is producing this error message:
Compile error:
Invalid outside procedure
...Which only confused me, since I got that from people who actually knew what they were doing (I assumed so, anyways).
Anyways, it's been so long since this program's worked, I can't actually remember the last time I was able to run it without getting some critical error that ends the program, so I turn to StackOverflow to tell me what I've done terribly wrong with my code.
Thank you in advance for anyone who offers their help.
Remove the DLLImport stuff. It's VB.Net, it's not valid VB6 at all.
[System.Runtime.InteropServices.DllImport("user32.dll")]
And then, like Hans said, remove the parentheses from the alias in the Declare.
I've been trying to figure out why the function below throws an error saying "Type Mismatch" when it returns. From what I know about VB6, this should work without any issue, yet it obviously does not. Can anyone see what I am doing wrong here and let me know how I can fix it? Thanks in advance.
Private Function GetByteArray(source As Variant, index As Integer, length As Integer) As Variant
Dim buff() As Byte
ReDim buff(0 To length - 1)
Dim i As Integer
For i = 0 To length - 1
buff(i) = CByte(source(index + i))
Next i
GetByteArray = buff
End Function
It turns out that the problem did not have anything to do with the Function I posted, but rather with what I was doing with the result. I was using the method to get the bytes of a double, and then using CDbl to get the double value. This is where the error was really happening.
The way I should have been doing this is to use the following code:
CopyMemory rfcTest.rfcFloat, GetByteArray(buff, 0, 8), Len(rfcTest.rfcFloat)
Note that in order to use this, you must also declare the CopyMemoryMethod like this:
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (pDest As Any, pSrc As Any, ByVal ByteLen As Long)
Wondering why a particular binary write operation in VB is so slow. The function reads a Byte array from memory and dumps it into a file like this:
Open Destination For Binary Access Write As #1
Dim startP, endP As Long
startP = BinaryStart
endP = UBound(ReadBuf) - 1
Dim i as Integer
For i = startP To endP
DoEvents
Put #1, (i - BinaryStart) + 1, ReadBuf(i)
Next
Close #1
For two megabytes on a slower system, this can take up to a minute. Can anyone tell me why this is so slow?
Edit: The reason for choosing VB6 is that it runs on 100% of our target platforms as a single EXE, without any separate dependencies (except VBRUN, which is on pretty much everything).
Well, are you reading and writing each byte 1 by one? In that case you are iterating through 2 million elements instead of just taking a chunk of data at a time and write it to the stream.
Take out the DoEvents call. If you're writing two megabytes of data one byte at a time, that loop has 2097152 DoEvents calls. That will really really slow down the process.
Dim startP, endP As Long -- here you declare startP as Variant and endP as Long.
DoEvents -- yields control to the OS, calling on each iteration makes virtually any loop endless.
And then, if you want to save a piece of an array to a file, that should be...
Hmm... What should it be then?
Option 1.
Declare another array to hold the piece, CopyMemory the data into it and put it into a file using a single Put:
Put #1, , arrName
That, however, may be not wise memory-wise.
Hence, Option 2.
Create an array that refers to the data in the big array. This way nothing will be allocated twice:
Dim bigArray(1 To 1000) As Byte
Dim chunk() As Byte
Dim i As Long
'Filling the array for test purposes
For i = LBound(bigArray) To UBound(bigArray)
bigArray(i) = Rnd * 254
Next
'Create an array that refers to 100 bytes from bigArray, starting from 500th
CreateSAFEARRAY ArrPtr(chunk), 1, VarPtr(bigArray(500)), 1, 100
Open "c:\1.txt" For Binary Access Write As #1
Put #1, , chunk
Close #1
'Always destroy it manually!
DestroySAFEARRAY ArrPtr(chunk)
This code requires the following helper functions (put in a separate module):
Option Explicit
Private Declare Function SafeArrayAllocDescriptor Lib "oleaut32" (ByVal cDims As Long, ppsaOut As Any) As Long
Private Declare Function SafeArrayDestroyDescriptor Lib "oleaut32" (psa As Any) As Long
Public Declare Function GetMem4 Lib "msvbvm60" (ByVal pSrc As Long, ByVal pDst As Long) As Long
Public Declare Function PutMem4 Lib "msvbvm60" (ByVal pDst As Long, ByVal NewValue As Long) As Long
Public Declare Function PutMem8 Lib "msvbvm60" (ByVal pDst As Long, ByVal NewValueLow As Long, ByVal NewValueHigh As Long) As Long
Private Const S_OK As Long = 0
Public Declare Function ArrPtr Lib "msvbvm60" Alias "VarPtr" (arr() As Any) As Long
Public Function CreateSAFEARRAY(ByVal ppBlankArr As Long, ByVal ElemSize As Long, ByVal pData As Long, ParamArray Bounds()) As Long
Dim i As Long
If (UBound(Bounds) - LBound(Bounds) + 1) Mod 2 Then Err.Raise 5, "SafeArray", "Bounds must contain even number of entries."
If SafeArrayAllocDescriptor((UBound(Bounds) - LBound(Bounds) + 1) / 2, ByVal ppBlankArr) <> S_OK Then Err.Raise 5
GetMem4 ppBlankArr, VarPtr(CreateSAFEARRAY)
PutMem4 CreateSAFEARRAY + 4, ElemSize
PutMem4 CreateSAFEARRAY + 12, pData
For i = LBound(Bounds) To UBound(Bounds) - 1 Step 2
If Bounds(i + 1) - Bounds(i) + 1 > 0 Then
PutMem8 CreateSAFEARRAY + 16 + (UBound(Bounds) - i - 1) * 4, Bounds(i + 1) - Bounds(i) + 1, Bounds(i)
Else
SafeArrayDestroyDescriptor ByVal CreateSAFEARRAY
CreateSAFEARRAY = 0
PutMem4 ppBlankArr, 0
Err.Raise 5, , "Each dimension must contain at least 1 element"
End If
Next
End Function
Public Function DestroySAFEARRAY(ByVal ppArray As Long) As Long
GetMem4 ppArray, VarPtr(DestroySAFEARRAY)
If SafeArrayDestroyDescriptor(ByVal DestroySAFEARRAY) <> S_OK Then Err.Raise 5
PutMem4 ppArray, 0
DestroySAFEARRAY = 0
End Function
I am testing an application that checks if a file exists across a network. In my testing, I am purposefully pulling the network plug so the file will not be found. The problem is this causes my app to go unresponsive for at least 15 seconds. I have used both the FileExists() and GetAttr() functions in VB6. Does anyone know how to fix this problem? (No, I can't stop using VB6)
Thanks,
Charlie
Unfortunately, VB doesn't make this easy, but luckily the Win32 API does, and it's quite simple to call Win32 functions from within VB.
For the LAN/WAN, you can use a combination of the following Win32 API calls to tell you whether the remote connection exists without having to deal with a network time-out:
Private Declare Function WNetGetConnection Lib "mpr.dll" Alias _
"WNetGetConnectionA" (ByVal lpszLocalName As String, _
ByVal lpszRemoteName As String, ByRef cbRemoteName As Long) As Long
Private Declare Function PathIsNetworkPath Lib "shlwapi.dll" Alias _
"PathIsNetworkPathA" (ByVal pszPath As String) As Long
Private Declare Function PathIsUNC Lib "shlwapi.dll" Alias "PathIsUNCA" _
(ByVal pszPath As String) As Long
For the Internet, you can use the Win32 API call:
Private Declare Function InternetGetConnectedState Lib "wininet.dll" _
(ByRef lpdwFlags As Long, ByVal dwReserved As Long) As Long
Const INTERNET_CONNECTION_MODEM = 1
Const INTERNET_CONNECTION_LAN = 2
Const INTERNET_CONNECTION_PROXY = 4
Const INTERNET_CONNECTION_MODEM_BUSY = 8
This VB site has more discussion on path oriented functions you can call in the Win32 API through VB.
use this too
Dim FlSize as long
flsize=filelen("yourfilepath")
if err.number=53 then msgbox("file not found")
if err.number=78 then msgbox("Path Does no Exist")
I'm not sure you can handle this much more gracefully - if the network is having problems it can take a while for timeouts to indicate that the problem is severe enough that things aren't working.
If VB6 supports threading (I honestly don't recall) you could spin the file open into a background thread, and have the UI allow the user to cancel it (or perform other operations if that makes sense), but that introduces a pretty significant amount of additional complexity.
VB6 has some networking functions that can test to see if the network is connected. You should be able to add in under 'References' the 'NetCon 1.0 Type Library'. This adds for you the NETCONLib. Once implemented, you should be able to test for network connectivity first, then test for the FileExists and GetAttr.
Let me know if this helps!
VB is inherently single threaded, but you can divert work to a COM component to do an asynchronous file check and flag an event when it is done. This way the UI thread stays at responsive at least. Trouble is - this is all theory, I don't know such a component.
But wait! Google just turned up this: Visual Basic 6 Asynchronous File I/O Using the .NET Framework. Does that help, maybe?
Also, they have something similar over at CodeProject: Asynchronous processing - Basics and a walkthrough with VB6/ VB.NET
this code only used for check connection (maybe can help you) for one of your problems :
Private Declare Function InternetGetConnectedState Lib "wininet.dll" (ByRef dwFlags As Long, ByVal dwReserved As Long) As Long
Private Const CONNECT_LAN As Long = &H2
Private Const CONNECT_MODEM As Long = &H1
Private Const CONNECT_PROXY As Long = &H4
Private Const CONNECT_OFFLINE As Long = &H20
Private Const CONNECT_CONFIGURED As Long = &H40
Public Function checknet() As Boolean
Dim Msg As String
If IsWebConnected(Msg) Then
checknet = True
Else
If (Msg = "LAN") Or (Msg = "Offline") Or (Msg = "Configured") Or (Msg = "Proxy") Then
checknet = False
End If
End If
End Function
Private Function IsWebConnected(Optional ByRef ConnType As String) As Boolean
Dim dwFlags As Long
Dim WebTest As Boolean
ConnType = ""
WebTest = InternetGetConnectedState(dwFlags, 0&)
Select Case WebTest
Case dwFlags And CONNECT_LAN: ConnType = "LAN"
Case dwFlags And CONNECT_MODEM: ConnType = "Modem"
Case dwFlags And CONNECT_PROXY: ConnType = "Proxy"
Case dwFlags And CONNECT_OFFLINE: ConnType = "Offline"
Case dwFlags And CONNECT_CONFIGURED: ConnType = "Configured"
Case dwFlags And CONNECT_RAS: ConnType = "Remote"
End Select
IsWebConnected = WebTest
End Function
in your event :
If checknet = False Then
...
else
...
end if
I agree with Will. Something like this is simple to handle with Script.FileSystemObject:
Dim objFSO As New FileSystemObject
If objFSO.FileExists("C:\path\to\your_file.txt") Then
' Do some stuff with the file
Else
' File isn't here...be nice to the user.
EndIf
Accessing files over a network can cause these hangs.
It's been a while, but I remember multi-threading in VB6 being relatively painful to implement. A quick solution would be to have a small .exe (perhaps also coded in VB) that can handle this. You could use DDE for inter-app communication or the ever so easy but kludgey file-based pipe, by which I mean a file that both apps will mutually read/write to handle inter-app communication. Of course, using file-based pipes, depending on the details of this scenario, may simply exaggerate the File I/O lag.
If there's a reasonable degree with which you can predict where the user will be selecting files from, you may consider preemptively caching a directory listing and reading that rather than the file directly - assuming the directory contents aren't expected to change frequently. Note: getting a directory listing over a network will cause the same lag issues as individual file I/O over a network. Keep that in mind.