Hello gslender,
Thanks for the feedback. Is there anything else you want to see improved about autocomplete?Also be sure to try out the documentation viewer. You can open it via window->Documentation window. This will pull up the corona docs for any lua variable/function that currently has focus, this includes autocomplete and caret movements.
Regards,
M.Y. Developers
I guess adding better parameter options… ie expand newButton (options) into newButton (left ,top, width, height, defaultFile, overFile ,id ,label ,onEvent) etc… I’m guessing pulling this detail out of each method isn’t going to be easy, but would sure help if it preloaded the options with the correct table datanames.
G
The new analyzer actually does pull that stuff out of the methods. We will add this feature to the next update.
Regards,
M.Y. Developers
Sweet! Looking forward to the next update then!
@G,
There is an update that fixes the autocomplete issues. There are a few things you should be aware of:
When you invoke autocomplete on a table based function you will get additional entries like this:
http://view.xscreenshot.com/86837e349264865d0ebf99a1b5f7b8a3
It is based on our lua analysis engine so it should infer the keys properly based on your function. However, this currently only works for functions that have just one parameter, multiple parameters wont be expanded, But…
if you invoke autocomplete inside a table
http://view.xscreenshot.com/1ebdc5ca160a5c822624e37cee049d0d
You will get a list of table keys.
One more caveat. The corona autocomplete stubs we have right now are not up to date so you might not get this behavior for all functions. For instance, widget.newButton(table) should have all the args expanded out but will not because the stubs do not yet have this detail.
If you ctrl-click on it it will take you to the stub and it looks like this:
--- -- @param options @class table -- @return @class ButtonWidget -- function widget.newButton( options ) end
to support the table parameters, it ends up looking something like:
--- -- @param options @class table -- @return @class ButtonWidget -- function widget.newButton( options ) options.id = "" options.left = 1 options.right = 1 options.label = "" options.labelAlign = "" options.labelColor = {} options.labelXOffset = 1 options.labelYOffset = 1 end
There is nothing special about the stubs, the IDE treats them the same as your lua code.
Regards,
M.Y. Developers
How do you do that? and where is the docs for all this?
G
where is the docs for all this?
Have you updated to v 1.9.08 (Help->check for updates)? There is no doc yet for this as it is a new feature. You need to just invoke autocomplete between the two curly braces in a function call.
Regards,
M.Y. Developers
Yep updated fine.
I’m seeing this though and nothing like what you’ve shown above…
G
EDIT > I fixed the “new” operator mistake (hang over from Java coding) and still made zero difference. On Mac OS X btw.
For instance, widget.newButton(table) should have all the args expanded out but will not because the stubs do not yet have this detail.
The functionality is there but we need to update the content to match up. The corona docs have changed significantly and it might take us a while to update all the stubs to support this feature. This is why it may not work on all the api functions but it should work on your own functions that have table parameters.
Regards,
M.Y. Developers
Here is a quick code snippet to demonstrate the feature:
function tabFunc(tab) tab.param1 = 2 tab.param2 = "" tab.param3 = true tab.param4 = {} end tabFunc--invoke code compete here
Regards,
M.Y. Developers
…aaahhhhhh, so the IDE still need to be updated with some database that you release based on Corona Docs content which isn’t updated/parsed in realtime. If it works on your own functions in code, why not on the Corona supplied Lua code ??
G
ok, I think I’m showing my lack of knowledge about Corona development now… so the IDE is reading the Corona supplied Lua code, just that it is stubs with no table defs and so I’m blind… the updated stubs you provide outline this Lua table more so it can be used correctly for parameter stuff… am I close?
G
why not on the Corona supplied Lua code ??
There is no supplied Lua code. I bet most of the Corona specific api calls happen in C. Even if we had the Lua source for the library calls we would create stubs out of them anyway as it is much faster to parse stubs than it is to parse implementation code.
so the IDE is reading the Corona supplied Lua code
We created the stubs ourselves based on the Corona API docs. Basically the stubs tell the IDE a few things:
The stubs just give the IDE an idea about the environment your scripts run in. In this case its Corona but you can write stubs for your own execution environments. It uses the same lua analysis engine that analyzes your code.
If you are from a java background you can think of these stubs like java interfaces, they are a high level description of the implementation but do not actually do any of the work.
Regards,
M.Y. Developers