VSCode integration issues

[pludikar]

@goyals 

The October update has certainly made the process of developing code less onerous, and I know that VSCode integration is still in its infancy and there are still some (very) rough edges - could you please add the following to your todo list (ideally, as a matter of urgency):

• The run(context) function appears to be invoked after the application is manually shut down at the addIn dialog - this means that buttons/controls and any other feature initialized by run() always remain visible, even after shutting down the addIn.
• I've regularly had synchronization issues between actual python files and those that appear to be created within Fusion 360 itself.  For example, I get an error message that something is awry on line xxx of module yyy.  I correct the error, save, disconnect, restart - and it's as if I hadn't done anything - same error.  I shut down the addIn from F360 - same again.  The only way to clear the issue is to restart F360!
• I've had several occasions where the disconnect button has failed to disconnect VSCode - the button bar with the disconnect disappears and no way to reinstate it.  Attempting to invoke the debugger from the AddIn dialog results in the message that an attached debugger already exists - restarting F360 appears to be the only remedy.
• Pressing disconnect and/or restart does not always restart the debugging process - occasionally it seems to hang up around the run/stop functions.
• The indicator showing that an addIn is running is not always consistent with the state of the debugger  - I've regularly had the debugger running correctly only to find that when something has gone wrong - you can't actually stop the addIn from the addIn dialog, because the indicator isn't active.

It would be nice if you had a way to force a hard reset from VSCode as a work around until you get the integration fixed - restarting F360 several times a day is a real pain.

Regards

Peter

[goyals]

Hi @pludikar,

Thanks for reporting these issues. I am pretty sure run method is never called on add-in shutdown. My guess is that probably you need to explicitly clear controls in stop(context) method of add-in as it is shown in API samples here http://help.autodesk.com/view/fusion360/ENU/?guid=GUID-

We will try to reproduce the VSCode issues mentioned in the list and get back to you.

[pludikar]

Hi @goyals 

I’m very familiar with the stop(context) - when I put break points on the stop function and the run function, I see the stop activated, followed by deletion of controls, then the run function followed by the creation of the buttons that just got deleted.  This has been working perfectly for almost 2 years with spyder, but VSCode is exhibiting this now.

Unfortunately I haven’t found the exact steps to recreate most of the problems I outlined, but it happens regularly. I’ll try to recreate the problem with a simpler addIn script.

Another issue I forgot to mention is that I use the directory %appdata/autodesk/autodesk fusion 360/API/AddIns to develop my code ( as suggested in the user manual, under creating scripts and Add-Ins), but this is not inherently included in the pythonpath - which means that packages etc. are not recognized by python.  I have to put code into the script to ensure that the working directory is included - it should be unnecessary.

peter

[pludikar]

Hi @goyals 

I tried a simpler example and had no problems.  However the code I have is full of bugs and missing bits - I'm actually refactoring a version that was working, in order to add features to it. There's just under 2000 LOC in 7 or 8 files, 2 packages plus main, so not a minor undertaking.

I suspect that the debugger has issues with code that doesn't actually work - bizarre since that's when you want to use a debugger.  It's quite possible that there are unsatiated events or incorrectly attributed adsk calls which cause F360 to hiccup - when that happens the first thing to probably go wrong is the synchronization between F360 and the attached debug config.

If you are interested, here is the code I presently have.  It's still a work in progress and definitely full of issues.  

Regards

Peter Ludikar

[pludikar]

Hi @goyals

I'm not sure if this is relevant, but there appears to be a lot a false positive exceptions when running with breakpoints triggered by "raised exceptions".  As a minimum, they emanate from the creation of event handlers during button/command creation.  In my case, commandEventHandler uses an overloaded notify method - and it's a technique that I inherited from the original code developer (Corey Schafer - who was one your employees at the time).

If I break on raised exceptions - I get a report of attributes error.  If I run past the errors the control dialog works as expected.  However there may be some underlying issue that causes the VSCode debugger to lose sync that's not obvious.

Regards

Peter

[goyals]

Thanks for doing this investigation. So far we are not able to reproduce the problem but we will again try based on the information provided by you.

[pludikar]

Hi @goyals 

Thanks for letting me know.  

One of the raised errors comes from line 55 of core.py

The debugger shows that the parameters class_type and name are filled appropriately (afaik) - in this case <class CommandCreatedEventHandler>, and 'this', but 

line 55 : class_type.__swig_getmethods__.get(name,None) returns None, which then raises an error on the next line. 

'this' should have either been recognised or translated to a viable name, but it looks like VSCode integration has missed something.  It almost feels like one or more of the adsk libraries hasn't been found properly by VSC during runtime.  It's not the first time I've seen adsk go missing. 

Hope that gives you some clues

Peter

[pludikar]

Hi @goyals 

I think I found a way to reproduce the issues - at least on my machine

• Start F360 - to get fresh initial conditions
• Open AddIn dialog
• select the AddInSample example
• Start debug
• Check 'Raised Exceptions' in the breakpoint menu
• In VSC - start debugging
• Click continue, and the resulting dialogs as many times as needed to get the application installed and running.
• Click the control button to activate and start the addIn.

At this stage everything should be working as expected.

• Shut down the AddIn - disconnect and Shut down from the F360 AddIn dialog
• In VSC create another file - say util.py
• Move one of the defs (eg destroyObject) from the main sample file to the new one
• Add from util import destroyObject to the top of the main file
• Start debugging
• Click continue 
• It should throw an exception because it can't find util
• change util to .util in the import
• Try again
• It will probably still be working at this stage
• Next, move another def to util (eg commandControlByIdForPanel)
• disconnect, stop addIn and restart
• add commandControlByIdForPanel to from 'util import destroyObject' 
• debug - It'll throw an error looking for adsk
• Add import adsk.core, adsk.fusion to util
• and try again
• Around this time my machine can't find the newly moved def in util - I suspect yours may not too.  However, if it still works try moving more defs to util - in particular, deliberately do not check that the move brought over all the necessary imports and use VSC to throw up what's missing (hopefully emulating a typical brute force debugging process)

It appears that the process causes F360 to lock into a version of the AddIn (and/or its dependent modules) and won't refresh on disconnect and stop/restart

If you still can't reproduce this, then it could be something on my machine - although similar things have happened on two independent machines.

Regards

Peter

[pludikar]

Hi @goyals 

Have you been able to reproduce this issue?  

Unfortunately, whether it's something I've done (hopefully not likely), something wrong with the standard setup, or a bug, it results in VSC being totally unusable and has put a full stop on any progress with my add-In development.

I am very happy to work with you to help solve this issue - I have the time.

Regards

Peter

[goyals]

We tried to reproduce the issues you mentioned with the code you shared but no luck so far. I understand you might not like it if I suggest you to install VSCode extension again but may be worth to try considering that you are stuck at the moment. This is the location where ~/.vscode/extensions are installed.

1. Delete all folders starting with name "ms-python-python".

2. Launch Fusion and try to edit any script. This step will install latest version of this extension automatically.

3. Now you need to downgrade to 2019.9.34911 version of extension because new version is not working correctly. How to downgrade to the old extension is shown in this video https://forums.autodesk.com/t5/fusion-360-api-and-scripts/api-debugger-doesn-t-work-after-oct-2019-u...

If these steps did not help you then we can connect on zoom call if it works for you? I am working from India so let me know what is the best time to connect.

Regards,

Shyam Goyal

[pludikar]

@goyals 

Hi Shyam,

I already had the  2019.9.34911 version of VSC installed (In practice you can't actually open up VSC from fusion unless this version is active).  

I'm now back home on my main PC (I was working from my laptop before) and I am getting exactly the same problem.  I've now uninstalled both VSC and deleted the extension folders ms-python-python*.  Both have been reinstalled and although it seems a bit more stable, I still do not get updated code reflected in the debugger (particularly when it's not in the main package). I have Bitdefender AV and disabling that didn't seem to make any difference.

I'd be happy to connect on a zoom call.  I'm located in Toronto (Eastern Standard Time GMT/UTC -5) - perhaps you could PM me so we're not cluttering up this thread.

Regards

Peter

[pludikar]

@goyals 

Hi Shyam,

I think I found the main issue - I have a password manager (stickypassword) that appears to interfere with the event chain between VSC and F360.  This is common between all my computers, and hence the same behaviour.  As much as I love Stickypassword, it is particularly intrusive as it is aiming to provide a fully integrated password manager to ALL windows apps.  Once I added vscode to the ignore apps list, the disconnect and run/debug seems to behave as expected.  Previously, rerunning debug after disconnect would invoke the stop() event entrypoint, but wouldn't go beyond that - now it does.

Regards
Peter

[pludikar]

@goyals 

Hi Shyam,

I've had a chance to further test VSC without the StickyPassword App, and there is still a fundamental problem.  I put my Windows 10 into Safe Mode to see if there were any other Apps that may be interfering but MOST of the issues I've reported have NOT gone away.

StickPassword certainly interferes with the Event Queue between VSC and F360, but there continues to be other issues.  Mostly any changes to the files are NOT captured in the debug - as reported at the start of this thread, and one or two other occasions.  VSC still remains unusable for any meaningful development.

Can you PM me to setup a Zoom call - as you suggested before the Holidays.

Best regards
Peter