LabVIEW
Check if a File is Open using the File Express VI
Solved!
Interesting data: there was a bug a long time ago, fixed in LV2012, with the File dialog. The workaround then was to use this dll directly:
https://forums.ni.com/t5/Example-Code/File-Dialog-Using-NET-to-Select-Any-File-Path/ta-p/3532761
I can confirm your bug STILL happens calling the Windows OpenFileDialog() dll function directly, so it's definitely a Windows thing.
(yet more evidence but no solution: https://learn.microsoft.com/en-us/answers/questions/587197/issue-opening-file-using-winforms-applica...)
Aha! Found a workaround. Looks like the OpenFileDialog() in Windows is to blame. I'm not sure why this happens, but if you manually call OpenFileDialog() using the dll and set "ValidateNames" to False, it works:
Wrap this up in your own subVI and you should be good to go. Unfortunately this does make it not cross-platform but given that you're talking about OneDrive I doubt that's a problem for you.
(You can also set "ShowReadOnly" but that dramatically changes the appearance of the dialog box. There may be other options that fix this.)
@BertMcMahan wrote:
Aha! Found a workaround. Looks like the OpenFileDialog() in Windows is to blame. I'm not sure why this happens, but if you manually call OpenFileDialog() using the dll and set "ValidateNames" to False, it works:
Wrap this up in your own subVI and you should be good to go. Unfortunately this does make it not cross-platform but given that you're talking about OneDrive I doubt that's a problem for you.
(You can also set "ShowReadOnly" but that dramatically changes the appearance of the dialog box. There may be other options that fix this.)
I will try that. Thanks!
I was working on some .NET calls to the Process List to extract the Process ID to Excel, extracting the file path, then open a ActiveX task to see what Workbooks were open.
I'll try your suggestion before scrapping mine.
Eric
Weird. Do you get any errors? You may need to make sure the constructor is linked correctly. Could be some issue when I backsaved it. Can you open 2023 files?
OneDrive is cloud based and allows local and remote users to collaborate on the same MS office document at the same time. This probably necessitate a mechanism to prevent non-office programs from modifying office files to prevent a can of worms.
@Eric1977 wrote:
It helps to read. 😐
For me, if I have the file open and the run the supplied code, I still end up getting the message saying that the file is in use. Huh. I believe that you are right; there are some low-level Windows functions preventing users from selecting an already opened file...likely saving the users from themselves.
I'll look for a workaround to just display the workbooks (if Excel is open via the Task Manager) then use that as the file path to feed the Create Report.vi from the RGT Toolkit.
I'm sorry, I'm not following your posts. I'm not sure who you're replying to and who needs to read... did I miss something or are you talking about yourself, lol?
Anyway to be explicit- on my machine, if I run the code in my post above and set ValidateNames to False, that VI lets me select an open Excel workbook in a folder backed up to OneDrive. If I set ValidateNames to True, I get the same error as you had originally posted.
@Eric1977 wrote:
Are you replying about my code with the ValidateNames boolean on the Front Panel? If so, my questions remain- if you run it, what happens? Just, nothing at all? You didn't say if you got an error or not. Also, I mentioned trying to relink the constructor node, since there's a chance something got screwed up when I did a Save for Previous. Right click -> Select Constructor -> Assembly: System.Windows.Forms(4.0.0.0); Objects: OpenFileDialog; Constructors: OpenFileDialog(). I would assume Save for Previous works fine with .net constructors but it wouldn't surprise me if that's not the case.
And which OS/LabVIEW version are you on? I'm on Windows 11, LV 2023, 64-bit. As best as I can tell, the built in File Dialog function in Windows calls the same .net OpenFileDialog() that my code does, as you get the same issue there. I attached a non-backsaved for previous, 2023 version. See if that works.
@altenbach wrote:
OneDrive is cloud based and allows local and remote users to collaborate on the same MS office document at the same time. This probably necessitate a mechanism to prevent non-office programs from modifying office files to prevent a can of worms.
The File Select dialog seems like a weird place to put that mechanism. And you'd think it would be documented somewhere at least 😞
