View Full Version : F1 not loading doc, even if selecting easy lookup like Ext.Date

21 Nov 2016, 2:31 PM

I have latest version of the plugin, 1.0.1

22 Nov 2016, 2:00 AM
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

22 Nov 2016, 3:24 AM
Project created with Sencha Cmd V6.x, currently upgrade and running using Sencha Cmd v6.2.0.103.
Ext JS
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": [
"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...

22 Nov 2016, 9:50 AM
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-' 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-"

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

1 Dec 2016, 7:31 AM
The latest nightly build 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?

12 Dec 2016, 1:50 PM
The latest nightly build 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.

12 Dec 2016, 1:56 PM
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.

22 Dec 2016, 5:28 AM
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-, 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-” 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.