Closing image viewing software

[cheekybuddha]

No. The same error message.
File not found.
As I said, Microsoft.Photo.exe is protected by system and can not be accessed.

Thanks for the clarification.

I don't have this version of MSPhotos to test with.

What happens if you try a variation of one of Daniel Pineault's suggestions?

Function OpenNEF() As Long

  With CreateObject("WScript.Shell").Exec("ms-photos:FilePath=D:\images\008.jpg")
    OpenNEF = .ProcessID
  End With

End Function

 

[KitaYama]

What happens if you try a variation of one of Daniel Pineault's suggestions?

Function OpenNEF() As Long

  With CreateObject("WScript.Shell").Exec("ms-photos:FilePath=D:\images\008.jpg")
    OpenNEF = .ProcessID
  End With

End Function

If I copy ms-photos:FilePath=D:\images\008.jpg into run command (win key+R), the file opens.

 

[sonic8]

@KitaYama , did you notice that the backslashes in the path were replaced with the Yen currency symbol in your screenshot?

 

[KitaYama]

@KitaYama , did you notice that the backslashes in the path were replaced with the Yen currency symbol in your screenshot?

Yes. Some languages have a different backslash, but Windows behave them as backslash in background.

In Japanese:

• Visual appearance: ¥ (Yen sign) instead of \
• Reason: The character 0x5C (ASCII 92) is rendered as ¥ in many Japanese system fonts.
• Actual character: Still a backslash \ in the data/logic.

In Korean:

• Visual appearance: ₩ (Won sign) instead of \
• Reason: Similar to Japanese, legacy encoding (e.g., CP949) maps 0x5C to a currency symbol.
• Actual character: Remains as \ internally, but displayed as ₩.

Why this happens?
The root cause is legacy single-byte encodings like:

• Shift-JIS (Japanese): maps 0x5C to ¥
• CP949 (Korean): maps 0x5C to ₩

But the character at 0x5C in Unicode is unambiguously a backslash \. So this is only a font-rendering or encoding-display issue, not an actual character change.

 

[KitaYama]

@sonic8 To prove it's a font problem, and en currency is still backslash, here's the same machine, the same code, but when the font in option is changed to Lucida.

Most fonts shows backslash as en. The following (and possible few others) show it as it should be.
Segoe UI
Courier New
Lucida Console
Consolas

 

[cheekybuddha]

Why this happens?
The root cause is legacy single-byte encodings like:

Very interesting! Must make your code feel very expensive!

 

[sonic8]

@KitaYama and @cheekybuddha, I get the impression that you completely skipped an important step:
How do you know that Microsoft.Photo.exe is actually the application the user has configured for viewing these types of files?

I would rather use ShellExecuteEx to invoke the verb ("open") and then use process id of the created process to close the application later.

I really wonder why nobody pursued this approach, which, in theory, would be simple and reliable. - Maybe you were so much more informed than I and knew in advance about the following problem...

The ShellExecuteEx-approach works perfectly reliable to run, identify, and close the picture viewer. - But only once.

The problem is, that Photos.exe doesn't operate like a "normal" application that will create just one process for opening a file. Instead, Photos.exe will create multiple processes. If you close the window displaying your picture, either with code or manually, this will only terminate one of the multiple Photos.exe processes.
If there is at least one Photos.exe running when you use ShellExecuteEx to open an image file, the existing Photos.exe process will spin off more than one other Photos.exe processes. One of those new processes will then show the image while the others may or may not terminate again automatically. The ProcessId retrieved via ShellExecuteEx will be the one belonging to the very first process create which most likely terminates itself immediately. It will not be the process displaying the picture.

I tried to take and analyze a snapshot of the process list to figure out the heritage of the running processes and trace their lineage back to the MsAccess process. - This would probably even work, but only if MsAccess exclusively would create new processes of the picture viewer. As the user could also run the picture viewer manually, this approach cannot be relied upon.

As a side product my code can be used to detect the viewer application's .exe-name and that name can be used to terminate all processes of this application. - I don't think this is an acceptable solution!

Nonetheless, I publish my code as attachment for review and potential enhancement. The attached module is in the state of being abandoned work in progress and is not meant to be used in production without further revision!

 

[Edgar_]

@sonic8
I was referring to this key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts

 

[sonic8]

I was referring to this key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts

Ok, I misunderstood this, but ...
...actually...
I don't think this is a good idea.
And I think, you will agree...

On my computer a .jpeg file will open by default in an application, which identifies itself as Photos.exe.
Now look at the registry key you were referring to:

 

[Edgar_]

And I think, you will agree...

I agree, Photos.exe is not there.

Looking further, I found this:

Then I looked that ProgId up using the find tool and it took me here:

When I switch defaults to Firefox, it showed Applications\firefox.exe

So, there could be some information here. I can't conclude this is the right way, though. By the looks of it, whatever you do, it will depend on the OS.

If you open the same kind of file in Windows 8.1, the process is DllHost.exe, but the FileExt/UserChoice key shows this:

And this is jpegfile in HKCR/Applications

I see DllHost in the original suggestion:

You could work something out with that. However, if the user is meant to open the file via MSAccess, there could be a way to also control the closing of it. I think you and others have suggested this. I wish I had a better answer, but I don't currently have it.

 

[arnelgp]

I don't think the OP is interested on any of this? or maybe looking at another forum? well, see.

 

[arnelgp]

if the OP is opening one NEF file, one at a time and after viewing need to close the viewer, he can can use this demo db and
insert the path of the nef file on testToOpen sub (Module1). then when he is done viewing, he can close the file/viewer using the sub testToClose.