You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then using it to convert a a BlockInstance with Converter.ConvertToNative().
This works fine if we leave the ReceiveMode to the default value Update but we if we change it to Create or Ignore, Converter.ConvertToNative() returns null when converting the same object twice.
Added the following to the converter setup block above:
With this configuration, Converter.ConvertToNative() returns the expected result on the first execution but null on all the following runs.
We need to convert the same object multiple times, with ReceiveMode.Update the object is replaced instead of creating a new object.
I tried replacing the id and applicationId on the BlockInstance, is there something else that needs to be done before calling Converter.ConvertToNative()?
To Reproduce
Setup a Converter with Converter.ReceiveMode = ReceiveMode.Create;
Call Converter.ConvertToNative() on a BlockInstance (successful)
Call Converter.ConvertToNative() on the same BlockInstance (returns null)
Expected behavior
Converter.ConvertToNative() always returns the converted BlockInstance adding a new block to the Document every time.
System Info
Grasshopper: 7.32.23221.10241
Speckle.Core: 2.15.3
Speckle.Objects: 2.15.3
Failure Logs
No logs, also Converter.Report has no errors.
Proposed Solution
Add documentation and examples on how to change the converter receive mode
The text was updated successfully, but these errors were encountered:
Thanks for reporting this. It seems the converter is failing to create the same block definition over again, which causes the conversion to return null. On Update the converter will remove the block with the same name before adding the new one, but for create the behaviour is it will just fail.
You may be seeing a message like this on the Rhino command window
Your use-case seems valid, and I'll admit it's not ideal to have things fail with no developer feedback so I'll talk to the team and try to come up with a way forward that is more intuitive and hopefully better documented! 🙌🏼
Thanks for the quick support.
As I understand from your message you will add some form of logging of the error.
But how would we avoid hitting the error altogether?
Should we rename the BlockInstance or the Definition?
Would assigning a new ID be enough?
Renaming the definition to something else would do. Block definitions are matched by name from the RhinoDoc.ActiveDoc.InstanceDefinitions property, so you could try checking for that.
Ideally, this is something we should both fix so that create mode works and also clarify what should be the expectation for it.
Prerequisites
What package are you referring to?
Converters/ConverterRhinoGh
Describe the bug
We are setting up a Rhino Converter as follows:
Then using it to convert a a
BlockInstance
withConverter.ConvertToNative()
.This works fine if we leave the
ReceiveMode
to the default valueUpdate
but we if we change it toCreate
orIgnore
,Converter.ConvertToNative()
returns null when converting the same object twice.Added the following to the converter setup block above:
With this configuration,
Converter.ConvertToNative()
returns the expected result on the first execution but null on all the following runs.We need to convert the same object multiple times, with
ReceiveMode.Update
the object is replaced instead of creating a new object.I tried replacing the
id
andapplicationId
on theBlockInstance
, is there something else that needs to be done before callingConverter.ConvertToNative()
?To Reproduce
Converter.ReceiveMode = ReceiveMode.Create;
Converter.ConvertToNative()
on aBlockInstance
(successful)Converter.ConvertToNative()
on the sameBlockInstance
(returns null)Expected behavior
Converter.ConvertToNative()
always returns the convertedBlockInstance
adding a new block to the Document every time.System Info
Failure Logs
No logs, also
Converter.Report
has no errors.Proposed Solution
The text was updated successfully, but these errors were encountered: