This question already has answers here:
What does a hash do to a variable in VB?
(2 answers)
Closed 8 months ago.
I have often seen such code:
Dim fnum As Integer
fnum = FreeFile()
Open "myFile.txt" For Binary As #fnum
Put #fnum, 1, CA
Close fnum
It seems a bit strange to me. In "Open For", the author uses "#fnum", and in "Put", too, but not in "Close".
Therefore I would like to ask what it actually used for.
Does this originate from version of Visual Basic earlier than 6?
They are file handles:
https://stackoverflow.com/a/22847396/2467152
Those VB6 commands (FreeFile, FileOpen, FileClose, LOF, etc.) were present at least as far back as QBasic. I expect that the file number was originally an MS-DOS file handle.
Back in QBasic (if memory serves), the FileOpen command opened the file and reserved the file handle. The FileClose command closed the file and freed the handle.
FreeFile was just a convenience method to get an unused file handle: if you knew that you didn't have (for example) file #1 open, then you could just call OPEN "C:\DOS\RUN" FOR INPUT AS #1 and not bother calling FreeFile. You would still close it with CLOSE #1
Related
I am using libusb bulk transfer to read a file that has multiple carriage returns throughout the file. Every time it reads 0xd, it puts two 0xd characters in the receive buffer. Using Visual Studio C++ with Windows 10 OS. Has anyone else seen this or have an idea of how to get rid of this?
Problem solved. I was trying to use traditional C or C++ methods to write out my data. My input file had characters that these methods couldn't handle. I changed my output file to handle binary data and it solved the problem:
outFile.open(fileName, ios::out | ios::binary);
I'm working on small project in Pascal for school.
I'm using Lazaruz 1.0.2
I have problem with wirteLn function when writing to file.
After some time it just stops writing to file.
Take for example this program:
var oFile: Text;
i: LongWord;
begin
Assign(oFile, 'test.txt');
ReWrite(oFile);
for i:=1 to 4096 do
WriteLn(oFile, 'ThisIsTest');
CloseFile(oFile);//Added as suggested
end.
This is output:
...
4072 ThisIsTest
4073 ThisIsTest
4074 ThisIsTest
4075 ThisIsTe
As you can see it just stops at the middle of sentence and it is not writing all.
All depends on how long is one WriteLn insturction and how many times it is called.
How to fix it?
I tried to use WinApi function from "Windows" module called WriteFile but I failed to pass last 3 arguments to it.
BIG UPDATE
Thanks. That works (Closing file) in that example. But I have little bit more complex program where I'm passing opened file handle to functions that are writing to it via "var". And even after closing that file at the and does nothing. It is strange.
You should Close(oFile) at the end of your program to be sure the output is flushed.
It's also possible to update a file without closing it by adding (in this example)
Flush(oFile);
after a Writeln
This is useful where you might have a long file and want to make sure it's updated regularly. Of course, you should still close the file when finished.
I wish to send input to multiple emulated mice using dsf(device simulation framework) incuded in the current windows ddk. My code is below the problem is device manager recogizes the device got added but my program (mouse mischief - also microsoft) doesnt create the addtional pointer like its supposed to:
WriteLine "Create first input report to send to the consumer control"
Dim strMessage
strMessage = "Press Enter key to stop looping"
WriteLine strMessage
Do While NOT WScript.StdIn.AtEndOfLine
Dim InputReport1(4)
InputReport1(0) = CByte(0)
InputReport1(1) = CByte(100)
InputReport1(2) = CByte(100)
InputReport1(3) = CByte(0)
InputReport1(4) = CByte(0)
'PromptAndWaitForEnterKey "Queue input reports for processing"
GenericHIDDev.QueueInputReport(InputReport1), 10
'PromptAndWaitForEnterKey "Wait for the device to finish enumerating. Press enter to start processing input reports."
GenericHIDDev.StartProcessing
'WriteLine "You may send additional input reports at this time..."
'PromptAndWaitForEnterKey "Press enter at any time to stop processing input reports and start cleanup."
GenericHIDDev.StopProcessing
Input = WScript.StdIn.Read(1)
Loop
Note: this is the only section i modified of the TestGenericHid sample included with the dsf in the windows ddk(device driver kit). After install of windows ddk go to c:\Program Files\dsf\GenericHid or something similar to access the vbscript file.
Need mousmischief and windows ddk to fully understand whats going on and to correctly answer this. Dont worry all samples are in vbscript and can be redone in vb.net but i dont wish to waste time converting until i get the vbscript to work.
I have since I posted this got it working with multiple mouse and within 2-3 months time will have a nice beta upload of my whole kinectmultipoint project here:
http://kinectmultipoint.codeplex.com
The code above is in a zip file at the address above in the preceding sentence.
Before anyone says it, I know this isn't the way it should be done, but it's the way it was done and I'm trying to support it without rewriting it all.
I can assure you this isn't the worst bit by far.
The problem occurs when the application reads an entire file into a string variable.
Normally this work OK because the files are small, but one user created a file of 107MB and that falls over.
intFreeFile = FreeFile
Open strFilename For Binary Access Read As intFreeFile
ReadFile = String(LOF(intFreeFile), " ")
Get intFreeFile, , ReadFile
Close intFreeFile
Now, it doesn't fall over at the line
ReadFile = String(LOF(intFreeFile), " ")
but on the
Get intFreeFile, , ReadFile
So what's going on here, surely the String has done the memory allocation so why would it complain about running out of memory on the Get?
Usually reading a file involves some buffering, which takes space. I'm guessing here, but I'd look at the space needed for byte to character conversion. VB6 strings are 16 bit, but (binary) files are 8 bit. You'll need 107MB for the file content, plus 214 MB for the converted results. The string allocation only reserves the 214 MB.
You do not need that "GET" call, just remove it, you are already putting the file into a string, so there is no need to use the GET call.
ReadFile = Input(LOF(intFreeFile), intFreeFile)
I got the same error . And we just checked the taskmanager showing 100% resource usage . we found out one of the update application was taking too much ram memory and we just killed it.
this solved the issue for me. One more thing was we gone in to config settings.
START->RUN->MSCONFIG
and go to startup tab and uncheck the application that looks like a updater application or some odd application that you dont use.
Continuing from this question:
When I am trying to do fopen on Windows, I get a "Too many open files" error. I tried to analyze, how many open files I have, and seems like not too much.
But when I executed Process Explorer, I noticed that I have many open handles with similar names: "\Device\NamedPipe\Win32Pipes.00000590.000000e2", "\Device\NamedPipe\Win32Pipes.00000590.000000e3", etc. I see that the number of these handles is exactly equal to the number of the iterations that my program executed, before it returned "Too many open files" and stopped.
I am looking for an answer, what are these handles, and could they actually cause the "Too many open files" error?
In my program I am loading files from remote drive, and I am creating TCP/IP connections. Could one of these operations create these handles?
Are you remembering to fclose() your pipe each time through the iteration? (see -> below).
If not you are leaking open pipes.
for(i = 0; i < lotsOfIterations; i++)
{
FILE *fp;
fp = fopen(filename[i], "r");
if (fp != NULL)
{
... do work, etc
fclose(fp); // finished with this file handle (add this line!)
}
}
However, if your intent is have a lot of file handles open at once, then the other thing to be aware of is that the C runtime typically specifies a number of file handles you can have open at any one time. This number will typically be a lot less than the operating system is capable of providing. To use the OS provided file handles you will need to use Win32/Win64 API functions:
CreateFile
ReadFile
WriteFile
GetFileSize
CloseHandle
OS provided file handles are of type HANDLE not FILE *