I have a small dot matrix printer I have been trying to use with my program. For many reason, I cannot use a printer driver. I have it working, more or less, but am having one issue. I have the code tied to a button to print all the text, but when I hit the button it does nothing. If you hit it again, it gives you the error "run time error 55: file already open". And once you press end, it prints right away, and does it just how I lwanted it to. Why does this error pop up? and why doesnt it print until you hit end? Thanks.
Printing directly through COM1 issues using VB
- Thread starter proben930
- Start date
- Local time
- Today, 08:23
- Joined
- Feb 28, 2001
- Messages
- 30,566
I am going to presume that you did something like
When you open a device as a file in VBA, you are using the Windows file driver. It uses some buffer structures (just like any other file) and holds your output in the buffer, waiting for a time when it must send that buffer to your chosen device. Not CAN. MUST. I.e. it wants to wait before it sends anything to a device.
Your button needs to check whether the file is opened already before you open it a second time. You can issue the error yourself (through a message box), which is far less disruptive, or just ignore the second button-click event, which is least disruptive but somewhat misleading.
Another side effect of being buffered like a file. If your output fits entirely within the existing buffers, Windows has no reason to flush the buffer yet. You see, file I/O is designed to minimize device interactions. This is because physical device I/O is a relatively expensive operation when compared to the number of CPU cycles you could accomplish in the same time as it takes to do the device I/O.
Windows buffers are not sent to a device until the last allowed buffer is in use (I think.) And make no mistake, Windows (not VBA) is managing that file. If your END function includes that you Close the file, that action triggers a buffer flush. I'm not saying you can't do this another way, but if my guess about how you are doing this is correct, it would explain what you report.
Code:
Open "COM1:" for Output as File # 1When you open a device as a file in VBA, you are using the Windows file driver. It uses some buffer structures (just like any other file) and holds your output in the buffer, waiting for a time when it must send that buffer to your chosen device. Not CAN. MUST. I.e. it wants to wait before it sends anything to a device.
Your button needs to check whether the file is opened already before you open it a second time. You can issue the error yourself (through a message box), which is far less disruptive, or just ignore the second button-click event, which is least disruptive but somewhat misleading.
Another side effect of being buffered like a file. If your output fits entirely within the existing buffers, Windows has no reason to flush the buffer yet. You see, file I/O is designed to minimize device interactions. This is because physical device I/O is a relatively expensive operation when compared to the number of CPU cycles you could accomplish in the same time as it takes to do the device I/O.
Windows buffers are not sent to a device until the last allowed buffer is in use (I think.) And make no mistake, Windows (not VBA) is managing that file. If your END function includes that you Close the file, that action triggers a buffer flush. I'm not saying you can't do this another way, but if my guess about how you are doing this is correct, it would explain what you report.
