Some files are more open than others?

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, is the Compilers and General Programming sub-forum an acceptable location for a general (non-AVR) programming question?

If not, then perhaps this could get moved to the Off Topic sub-forum.

 

Understand that I'm not much of a programmer...

 

I am working on a PC to AVR Micro project, and I am currently working on the Windows PC side of the user interface.

I am programming in MS Visual Basic 2010 Express.

 

I am working with a User Configuration / Setup .txt file, stored in a fixed directory on the C: drive.

(Trying to keep it simple at the moment.)

 

I noticed that if the setup file is already opened with Windows Notepad or with Windows Wordpad I can STILL open and close it from within my VB program.

I can also rename the file from within Windows, (Windows explorer, R click, rename...)

 

However, if the setup file is already opened in MS Word, then attempting to rename it pops up the File is already in use message, and if I attempt to open/close it within VB it throws an exception error.

 

I was attempting to easily determine if the setup file is already opened, or not, before the VB program continued to work with the file.

It would appear that the Windows OS and VB both recognize a file as being already opened via MS Word, but that NotePad and Wordpad can slip through the system?

 

Don't ask me how many hours I spent this evening intentionally trying to get VB to throw an exception / error while I had the setup file opened (in WordPad), and couldn't figure out why I wasn't getting the error I expected...

 

Good think I don't program for a living!

 

JC

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not tested, but can you Catch the IOException ?
Working in reverse, you could open the file in VB and lock-out other processes via the share parameter in FileOpen()

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How cool.  I'd not yet come across the Share parameter.

It appears that by setting it to 0 I can prevent other programs from opening the file.

 

That is certainly better than not blocking access while my program is working with the file.

 

As it is currently, it isn't throwing an exception to catch when the file is already opened by NotePad, when my VB program then also opens the file.

 

Just odd, I don't know enough of Windows foundations to understand the "why" behind this.

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
If not, then perhaps this could get moved to the Off Topic sub-forum.
Conversely, as-is as your thread is visible to search engines.

Thanks for I've learned due to your thread.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That behaviour is quite normal for a text editor. What is surprising to me is that Notepad doesn't lock the file.

 

The reason is that you may well be viewing a logfile or more pertinately a compiler list/map file. If the file were locked the background process couldn't write a log entry or in the compiler case the build would fail.

 

Notepad being positively pre-historic doesn't watch the opened file for changes, but grown-up programs do. Almost all IDEs will inform you that the file was changed externally (Ha Ha Visual Studio Code does not. It will silently update the file, except if you have unsaved changes, then it ignores the external changes.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Setup .txt file,

Just to mention JSON which is possibly becoming the more widespread method for holding "config" these days. I'm sure there must be some JSON parsing available to use in VB.

 

Having said that there are, of course, the venerable old WritePrivateProfileString/GetPrivateProfileString which will write and read INI files for you. The modern version of that is WriteProfileString/GetProfileString - those don't use an INI file, they write and read keys in the registry.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Notepad being positively pre-historic...

Guess that explains my comfort zone...

 

Just to mention JSON  

Wow, I wasn't familiar with that.

Interestingly, my (simplistic) setup.txt file looks just like the JSON example in Wikipedia, (A list of Attribute: data values, one per line; human readable in ASCII).

 

 

WriteProfileString/GetProfileString

I might well have to hunt around VB for that, or its equivalent.

I read a chapter on Registry programming in a couple of books, plus an on-line article or two, and decided to Keep It Simple with an old school setup.txt file.

It appeared that I could screw up my computer in a big way if I messed up the Registry, and it just wasn't worth going there.

That said, I wasn't aware of the high level functions to Read/Write the Registry, everything I looked at was tackling the problem from a more primitive level.

 

JC

 

 

  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Somewhat an example of this, in a different environment.

 

I use Atmel Studio 7 on a Win10 laptop. It shares a DropBox with my iMac. (Also control the laptop from the iMac using TeamViewer). I do all the program editing on the iMac using TextWrangler, a full-featured programmer's text editor. So, I have it set up so that AS7 uses a directory inside DropBox as its working directory. TextWrangler is pointed to the corresponding DropBox directory on the iMac.

 

In the ilMac -> Win direction, it works beautifully. I can save a file in TextWrangler. Very soon after, a notice pops up in AS7, saying that a file in use by AS7 has been changed, and asks for permission to update the file in the current project. Very smooth.

 

BUT, in the Win->iMac direction, if I change a file in AS7, I get a notice of "file conflict" by TextWrangler and no real good way to resolve it other than deleting one file and renaming another. It works fine at the iMac end on files that are NOT open in TextWrangler.

 

The point of all this is that different programs handle files and file changes (that they are not responsible for) differently. It is up to you to figure out how to resolve this, up to and including changing to different software or different work flow. I suspect that the problems described in the original post are more of an issue of the applications rather than the file system.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Nov 12, 2018 - 05:55 PM