windows Visual Studio C++/Visual Basic file locking
-
What would be the best way to have a C++ program write(append) to a file and at the same time have a Visual basic program read sequentially all that's been written and when it reaches EOF wait for more? How would file/record locking be used to accomplish this?
-
What would be the best way to have a C++ program write(append) to a file and at the same time have a Visual basic program read sequentially all that's been written and when it reaches EOF wait for more? How would file/record locking be used to accomplish this?
A named pipe would be a good candidate for this requirement. The C++ program can create and write to the pipe -
CreateNamedPipe/WriteFile. The VB program can open and read from the pipe -CreateNamedPipe/ReadFile.«_Superman_»
I love work. It gives me something to do between weekends. -
What would be the best way to have a C++ program write(append) to a file and at the same time have a Visual basic program read sequentially all that's been written and when it reaches EOF wait for more? How would file/record locking be used to accomplish this?
for your info only - memory mapped files is another option you can have, though its complex than using named pipes.
Creating Named Shared Memory -
What would be the best way to have a C++ program write(append) to a file and at the same time have a Visual basic program read sequentially all that's been written and when it reaches EOF wait for more? How would file/record locking be used to accomplish this?
Options in increasing order of complexity/robustness: - Those mentioned, uncontrolled access by both apps/threads. - LockFileEx() / UnlockFileEx() - OS level read/write locking, critical if multiple threads will be appending. - Transactional NTFS - TxF API to perform transacted reads/writes, critical if multiple writes to different data sources (file, registry, database) may need to be rolled back and readers need consistant view across all.
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack