F1 not loading doc, even if selecting easy lookup like Ext.Date

[SebTardif]

Ext.Date.PNG

I have latest version of the plugin, 1.0.1

[AlexanderDrackaProfiq]

Hello SebTardif,
I am sorry for inconvenience. I am not able to reproduce your issue, my F1 navigation works just fine, eg. Ext.Date.isDST.
Could you please provide some additional information about your issue?:
Is this application created by the VSC Plugin?
Which Ext JS framework and CMD are you using? If it is >6.0, which toolkit are u using?
In which file you invoked F1?

Thank you for your reply
Alexander Dracka

[SebTardif]

Project created with Sencha Cmd V6.x, currently upgrade and running using Sencha Cmd v6.2.0.103.
Ext JS 6.2.0.981
F1 doesn't work everywhere. app.js under classic, or app.js under root, or anywhere else.

The contextual code complete feature works, so... the plug-in understand something, weird that the easiest feature to implement doesn't work.

Do you have a better log file I could send you or with more verbosity?

2016-11-22T11:18:32.372Z - info: spawning tern: C:\Program Files (x86)\Microsoft VS Code\Code.exe C:\Users\stardif\.vscode\extensions\Sencha.vscode-extjs-1.0.1\node_modules\sencha-tern\bin\tern --dir c:\workspace\ees\apps\nextt\ui\nextt
2016-11-22T11:18:33.853Z - info: [tern output] - environment: unknown (tern v{build})


2016-11-22T11:18:35.124Z - info: [tern output] - found config.json at c:\workspace\ees\apps\nextt\ui\nextt\.sencha\ide\config.json


2016-11-22T11:18:35.131Z - info: [tern output] - contents:


2016-11-22T11:18:35.132Z - info: [tern output] - {}


2016-11-22T11:18:35.135Z - info: [tern output] - include [ 'C:\\workspace\\ees\\apps\\nextt\\ui\\nextt' ]


2016-11-22T11:18:35.135Z - info: [tern output] - contents after postprocessing:


2016-11-22T11:18:35.135Z - info: [tern output] - {
	"include": [
		"C:\\workspace\\ees\\apps\\nextt\\ui\\nextt"
	],
	"apps": [],
	"exclude": []
}


2016-11-22T11:18:35.373Z - info: [tern output] - Found apps:
[
	{
		"path": "C:\\workspace\\ees\\apps\\nextt\\ui\\nextt",
		"sdk": {},
		"name": "Nextt"
	}
]


2016-11-22T11:18:49.885Z - info: [tern output] - loading 4661 js files in project...

[SebTardif]

It break a lot because the plug-in is hardcoding too much about where ExtJS framework is. Before I change ext folder to default 'ext' from 'ext-6.2.0.981' it didn't even load the browser. Now it mostly always load http://docs.sencha.com/extjs/6.2.0/index.html, the root of the help, even if I choose very easy thing to lookup, like a full class name.

It doesn't read workspace.json:

 "frameworks": {
               "ext": "ext-6.2.0.981"
    },

I'm not convince it should need to find an SDK to know where to go online...

[Mark.Brocato]

The latest nightly build 1.0.0.132 uses app.json and workspace.json to determine the path to the sdk. I believe this will fix your issue. Can you give it a try and let me know?

[SebTardif]

The latest nightly build 1.0.0.132 uses app.json and workspace.json to determine the path to the sdk. I believe this will fix your issue. Can you give it a try and let me know?

It's not working. I suggest you make the plug-in debuggable by creating a useful log that I could upload to you.

[Mark.Brocato]

You can access the log from the command palette via "Show Ext JS Plugin Log File". It would also be helpful if you could send your app.json, workspace.json and .sencha directory in the root of your app or workspace. You can email me using my forum username @sencha.com.

[SebTardif]

For the interested, the issue and solution described by Mark Brocato:

You’re opening the project at ui\nextt and the sdk is at ui\ext-6.2.0.981, which is outside of the vscode project root. The extension is smart enough identify the sdk based on workspace.json, but it doesn’t index it. You could add “..\\ext-6.2.0.981” to the “include” array in your intellisense config to fix this. I’m also going to make it so that all sdks referenced by apps in the project are indexed, even if they are outside of the project so you won’t have to modify your config in the future. The latest nightly on the support portal will now automatically index the framework even when it’s outside of the framework. So you should be able to exclude the target directory again.