Community
Participate
Working Groups
The remote file open funcitonality (--launcher.openFile) picks up any running Eclipse instance that fits the specified name ("Eclipse" by default). If an "old" Eclipse application is running (say, Eclipse 3.5 SDK), the launcher will pick it up as the target of the "--launcher.openFile" command even as it can't process this request. We probably should try to iterate through open Eclipse processes until we find one that can accept the "--launcher.openFile" command.
I don't think this is true. The win32 launcher code looks for a window with the title "SWT_Window_XXX" where XXX is what ever string was set in Display.setAppName(). If you are running Eclipse 3.5, the launcher will (likely) never find a window with that title. On gtk we use atoms instead of window names but the principle is the same and on mac the user will have to associate files with eclipse in the info.plist file and that wasn't done in Eclipse 3.5. There have been a couple builds where the SWT and launcher support was included, but the workbench support wasn't. That was unavoidable, and not a serious problem since it's unlikely anyone will be running those builds after M5 ships.
(In reply to comment #1) > I don't think this is true. You are right, at least on Windows, Eclipse 3.5 and Eclipse 3.6M2 are not picked up. I was confused by having several recent I-builds of Eclipse 3.6 which were picked up by the launcher.
Referring to: eclipse_version.exe --launcher.openFile whereas _version can be replaced with your installed versions if you have more than one. The command worked but why it asks to create workspace. It should directly open the file. It is not that one is going to work in a project. Any comments about it? Thanks.
