Cannot find file 'C:\Windows\system32\W'

[tmiecz]

This is great. I'm so close, I can smell it.

Running windows OS / PhpStorm 2018.3.1
I trigger a link: phpstorm://open?url=file://W:/index.php&line=15

First it shows a popup:
"Cannot find file 'C:\Windows\system32\W'"

Then it opens up the file and jumps to line 15.

Any tips to prevent the first popup? It already opens the right file, but the popup each time is a pain.
Also any tips on making PhpStorm focus after the link is clicked?

[aik099]

The format of URLs you're generating in your app is incorrect.

It should be:

phpstorm://open?file=/path/to/file.php&line=15

You're using:

phpstorm://open?url=file://path/to/file.php&line=15

.

[tmiecz]

Thanks for the reply @aik099 - I appreciate it!

I tried the alternative style link:
phpstorm://open?file=W:/index.php&line=15

It's the same issue with prompt:
Cannot find file 'C:\Windows\system32\W

Once I click "OK" the actual index.php opens up.
Hmm... maybe I need to tweak the run_editor.js some more. I'll keep looking. If I find a solution I will post it here.

[aik099]

Strange. I wasn't having such an issue when developing & testing this on Windows 7. People using Window 10 also reported it to be working out of the box (once you configure where PhpStorm is located).

What is the Windows version you're using?

[tmiecz]

It's Windows 10 Home version 20H2.
Maybe it's an issue because the drive is a network drive... so maybe it's trying to locate actual drive (no match, but still the path is valid so it opens it up)? I'll test it on the computer that has the code tomorrow, but I've already added to all of my debug pages online - it's a true game changer. Thanks for doing this.

[aik099]

Try installing some JavaScript debugger or use the free app (if available on Windows) so do real-time debugging of the run_editor.js file. This way you can find where it fails exactly.

My guess would be the ActiveX component registration problem.

You can also run wscript ... command (from the run_editor.reg file) by hand with the actual path put instead of %1 and see what happens.

[tmiecz]

Hmm, I wouldn't know how to begin debugging windows JS, I'll just deal with the issue.
After I updated PhpStorm to newest version, instead of throwing an error it opens up a path that doesn't exist:
C:\Windows\system32\W
Honestly no clue where to begin fixing that, so I'll just leave it and perhaps someone else comes around with a solution.

---

On another note, I looked through your code and found shell.AppActivate call that never worked for me. When PhpStorm has a specific project open, the window title becomes the name of the project. So in my case, I named the project "whois" and then I hardcoded that value to the window switching call: "shell.AppActivate('whois');" - that opens up the file and switches to my project.

The problem now is that I will have another PhpStorm window open with bunch of empty W files that I will need to keep closing every now and then. :)

My suggestion for window switching would be to allow another parameter to be passed in the URL for the project name... would be great if we could have 2 projects open and the link would know which project to open this file in, i.e:

phpstorm://open?file=/path/to/file.php&line=15&project=whois

[aik099]

Hmm, I wouldn't know how to begin debugging windows JS, I'll just deal with the issue.
After I updated PhpStorm to newest version, instead of throwing an error it opens up a path that doesn't exist:
C:\Windows\system32\W
Honestly no clue where to begin fixing that, so I'll just leave it and perhaps someone else comes around with a solution.

Agreed.

My suggestion for window switching would be to allow another parameter to be passed in the URL for the project name... would be great if we could have 2 projects open and the link would know which project to open this file in, i.e:

phpstorm://open?file=/path/to/file.php&line=15&project=whois

For me window title is:

project name [/path/to/project] - .../relative/path/to/opened/file.php

I'm on Mac though. Maybe the window title on Windows is different and more static.

Anyway the shell.AppActivate('... call is only activating window as configured. For example:

• either you either use JetBrains Toolbox integration and it guesses window title
• or you define "window_title" setting upfront