lastest update for october 2020 broken plugins

[superclod3W6YQ]

anyone else finding that the update October 2020 Product Update
V.2.0.9142 has broken plugins purchased from the store?

i get the contact author plug in error on startup. manual starting the plugin won't work.

great my day is ruined getting work done.

[RajkumarIlanchelian]

@superclod3W6YQ @It’s possible that the add-ins may need to be updated with changes APIs etc. 

which add-in in particular are you receiving this message? 

[superclod3W6YQ]

i would imagine this is due to the Sketch and text changes.

this is all the plugs ins created by Shwivel

https://apps.autodesk.com/en/Publisher/PublisherHomepage?ID=HNK2PN6ZY74X

i have emailed the author. however it appears to have broken some other older plugs ins i have as well.

[marcinszydlowski.1984]

Hello @superclod3W6YQ , @RajkumarIlanchelian ,

I'm the author of those plugins. The reason is the adsk.core.ToolbarPanel.isVisible setter is no longer available. If this change was intended I need to know to update my plugins and inform clients.

[RajkumarIlanchelian · Accepted solution]

@marcinszydlowski.1984 @Thank you for reaching out. I have reached out to our engineering team and should hear back shortly. Either I or someone from the team will reply back here. 

[goyals]

@marcinszydlowski.1984 I think ToolbaPanel::isVisible was only a get property always and set was never available. We made fix with October update to return the correct value for this property based on Fusion UI state. Thanks.

[marcinszydlowski.1984]

@goyals Now it make sense. That's why I never noticed difference between setting this parameter True of False.

Are there any other API fixes in this update?

[goyals]

With October release, We tried to fix all the samples available in API public documentation. There is a sample "WriteUserInterfaceToFile" which was broken for some time and showing the wrong status of toolbarPanel in write out file. We fixed it with this Fusion update.

We fixed isEnabled property also on command defintion class. It was not working as expected before.  A smaller issue in Joint area. Most of new additions are documented in What's New section of API documentation.

Let us know if you notice any issue related to our fix. Thanks.

[marcinszydlowski.1984]

@goyals I also noticed that Python expressions for indexing/slicing arrays stopped working, ex. something like this:

for b in circularBoxPattern.bodies[1:]:

throws an error:

for b in circularBoxPattern.bodies[1:]:
  File "C:/Users/Marcin/AppData/Local/Autodesk/webdeploy/production/dd9f6f358a2fb3275dcc42ca1789a2eb0e9d89a7/Api/Python/packages\adsk\fusion.py", line 5111, in __getitem__
    if i < 0 or i >= len(self):
TypeError: '<' not supported between instances of 'slice' and 'int'

I've made a quick bypass for this but if it's some kind of changes in translating Python -> C++ I think it's need to be mentioned in the forum as separate topic for other users/authors of plugins. I haven't found an information about it in the section of last changes in API.

[goyals]

We also updated SWIG to version 4.0. SWIG is used for translating interfaces from C++ to Python. I agree it is a good point to update in What's New section. 

[Maciej_Rogowski]

I also noticed an error in all my add-ins after the October 2020 update.

AttributeError: module ‘importlib’ has no attribute ‘util’

It appears only at startup. The error doesn't appear when the add-in is started from the add-ins window. It looks like some built-in Python functions aren't available at startup.

[marcinszydlowski.1984]

@goyals @RajkumarIlanchelian Is it possible to inform developers of plugins about prepared changes in API before Fusion release? Or maybe some link if such information is available somewhere in online help?

[pludikar]

I would second that request for a heads up.  Even Microsoft and Apple give their developers time to update 3rd party apps - it would be embarrassing for them to release a significant new OS version and find that most of their apps are broken.  Maybe AD can take that as a lead.

Peter 

[JeromeBriot]

+1

[goyals]

This is a good idea and We need to find right mechanism to serve the purpose. Things like updating python and swig versions, deprecating any API are potential reasons where existing add-ins might break.

Not sure informing add-in developers a two or three releases before about the potential change which might cause some issue will be helpful or not. We are following it for "Support for Javascript API going away fully soon".

Feel free to let us know if you have any idea. Thanks. 

[pludikar]

I'd suggest this is essential if you don't want to spend a lot of time fixing your public relations!

There are 2 approaches I've seen, both of which rely on a beta release model:

1. allow developers to subscribe to the beta release program, so that they are notified of any new upcoming releases and have access to the pre-release.  This will typically be a minimum of a month before public release for minor version releases (eg bug fixes), and 3 or more months for a major version release (eg new features, or major changes to underlying system - new IDE/debugger as a prime example). (see apple or microsoft )
2. Allow users to tag pre-release in the F360 preferences, but this must be reversible. 

Users will understand, through notes and warnings, that operating with a Beta version is potentially prone to errors,  faults and instabilities.  The upside to AD is you get debugging feedback from the community prior to release - potentially hundreds of free testers (or 1 or 2 if you mess this up)!

This does mean that F360 will probably have to miss at least one development sprint cycle for public release, but after that no one will notice.

Peter