I think I'm seeing a bug when traversing a list of ModelParameter objects. If I have a particular component, I can get its requisite model parameters with component.modelParameters and iterate through this list as follows (code in Python):
paramList = component.modelParameters paramCount = paramList.count for i in range(paramCount): param = paramList.item(i) ...
For each param there are attributes such as: role, name, unit, expression and createdBy. Except the createdBy attribute is not always returning an object. It usually returns a Base object which has a derived object class of, say, ExtrudeFeatures or CircularPatternFeatures etc. However for Sketches, the createdBy attribute is always None (or NULL). In the UI, the information is being retrieved so either I'm missing a subtlety of operation or the API isn't filling in that information correctly.
Thanks, Conor.
Actually, as the createdBy parameter is Null for Joints as well, this isn't a bug. This is more of a "you have to find out some other way". I'll start hunting 🙂
Edit: I see. The parameter is convenience mechanism that isn't filled in for certain ModelParameter entries. You can find out the others by recursing through the Component parameter entries and cross referencing the parameters in there to the list of ModelParameters found in component.modelParameters. Oh well. Maybe in future that information will be placed into createdBy but I don't see a lot of demand for doing so, so I won't worry about it...
Actually, I would say this is a bug. In the case of sketches we should be returning the SketchDimension that's associated with that Parameter and we should also be returning the Joint. I don't see an easy workaround for this besides querying everything to see what's related to that parameter. I've logged a bug for this problem.
Thanks Brian. I would mark it pretty low priority if I'm the only person who has ever seen it 🙂
I was traversing the joints and sketches but it's a bit involved for my poor brain at the moment. I found the joints a bit of a twisty maze - I'd have to experiment to find out how they are stored. Which goes to show that it's not in any way a straightforward fix. Personally I'd "fix by documentation" - let the documentation show that createdBy returns Null in the case that that information is not available.
Aside: Another tricky one is whether a sketch is fully constrained. I don't see how Autodesk is supported to do this in the UI (The changing the colour of lines when sketch is fully constrained feature). I'm struggling to figure out how to do this in code. A line segment is constrained if that segment's end points are connected to the endpoints of constrained sketch curves or connected to the midpoints of constrained sketch curves and the segment has a angular dimension or is otherwise angularly constrained or.... etc. Good grief! If a sketch isn't fully constrained, awful things happen if a body based on that sketch is projected and you change a dimension!
Good news! This is getting fixed in our upcoming May update!
... unfortunately it has not been fixed ..
"
, line 990, in listParamsAll
createdName = modelParam.createdBy
File "C:/Users/MichaelT/AppData/Local/Autodesk/webdeploy/production/18af90c2424c43b71dc6c52891abb31ac6897320/Api/Python/packages\adsk\fusion.py", line 37387, in _get_createdBy
return _fusion.ModelParameter__get_createdBy(self)
RuntimeError: 2 : InternalValidationError : res
"
This is an error log. I ran the old script on the old design ... it has been working without problem ... until the last update..
Could you please look at the issue once again?
With Regards
MichaelT
Hello,
I am sorry to hear the issue didn't get solved in your side. For the error message, it looked be there are internal objects which we don't implement API yet for. It would be great if you can send me(marshal dot tu at autodesk dot com) a copy of design which you had issues with. We will investigate the fix.
Thanks,
Marshal
Here there is the file ... old one ... I have already posted it in the thread with the name Drag Chain or similar
The problem is persistent across many others ...
I hope it is not a difficult issue to resolve!
Regards
MichaelT
Hello,
Thank you for sharing the design. I can reproduce your issue with it. It did contain some objects(e.g. Motion Link) which we didn't implement API yet. In the case, a null object will be returned from ModelParameter.createdBy and meanwhile an exception is thrown for Python and Javascript language. I would like to recommend you catch exception when call the method. The following codes are for your reference.
We need update document for the method to describe the behaviour. In addition, we will also consider if it is necessary to thrown exception in the case. If we don't throw exception, developers need check the return value from the method to avoid null object exception.
Thanks,
Marshal
#Author- #Description- import adsk.core, adsk.fusion, adsk.cam, traceback def dumpModelParameter(ui, comp): for param in comp.modelParameters: try: owner = param.createdBy ui.messageBox('Parameter name is {}, created by {}'.format(param.name, owner.objectType)) except: ui.messageBox('Parameter name is {}'.format(param.name)) def run(context): ui = None try: app = adsk.core.Application.get() ui = app.userInterface design = adsk.fusion.Design.cast(app.activeProduct) root = design.rootComponent dumpModelParameter(ui, root) subcomps = {} for occ in root.allOccurrences: comp = occ.component subcomps[comp.name] = comp for compname in subcomps.keys(): dumpModelParameter(ui, subcomps[compname]) ui.messageBox('Done') except: if ui: ui.messageBox('Failed:\n{}'.format(traceback.format_exc()))
Thank you Mr Tu,
... it was quick!
I am nevertheless curious, ... why the script/design worked seamlessly before. Wouldn't be wise to look what was a change to the code ( from previous version) which inflicted the damage?
Regards
MichaelT
Hello,
The fix we made in latest update brought the behaviour change, which throw exception once we find return value is null. Almost all API methods follow the same behaviour. This was why you saw it worked well before the update.
Sorry for the trouble. We have to be careful when we make the kind of changes in the future.
Now we may have to keep current behaviour(throw exception) be unchanged. Otherwise, it would break apps again in future updates if we don't throw exception and clients like you have used try-catch for the method.
Thanks,
Marshal
It nice to hear it ... sensibility is always appreciated.
Regards
MichaelT
Hello,
Today Brian and I reviewed the behaviour of ModelParameter::createdBy again. Both of us think it would be better not to throw exception for the case which new feature objects are not implemented API. We are worrying about some clients aren't aware of the behaviour change yet in Fusion May release. So the decision is made to revert the behaviour back. The changes will be included in late June release.
It means you have to check the result of the method before using it. Once new Fusion update is available, no try-except statement is needed to wrap the calling of the method up. However I would suggest to use try-except to be compatible with Fusion May update. For example:
try: owner = param.createdby except: pass if owner: # do something # ......
Sorry for the trouble.
Thanks,
Marshal
Thanks,
and a kudos for the decision! Why not return the simple NULL (across all spectrum of iterators) and give an user a chance to handle it?
Regards
MichaelT