This is going to be about Rhino Connector: I was trying to debug the ConnectorRhino7 by implementing the steps below:
First: I updated my speckle-sharp fork.
Second: I made sure Speckle Manager does not consist Rhino Connector as manually installed.
Third: I dragged the file of SpeckleConnectorRhino.rhp at ...\speckle-sharp\ConnectorRhino\ConnectorRhino7\bin\Debug\win-x64 filepath to the Rhino V7 while it is runing and made sure I can see the Speckle at the Command line as seen in the ss:
After building Rhino folder under the All solution at Visual Studio, I run the ConnectorRhino7 for debuging, hovewer Rhino started and got frozen as can be seen via link below:
Your steps seem OK unless you put some debug breakpoint into Plugin.OnLoad function. If you use a single monitor and VS and Rhino init window overlaps sometimes it happens that you can’t see catch on the breakpoint.
I can’t access your screen recording. (Requested access)
Thank you @oguzhankoral for your attention.
Sorry for the inconvenience regarding the access to the record, you can access now.
It was not a single screen, there was not the overlap.
I put the breakpoint to the OnLoad method and went after each steps.
The dialog you are having seems weird because it says something about SAP2000.
I highly suggest that you not debug connectors from All.sln file. In each connector folder, we have .slnf files that filter All.sln file for your connector. Can you try to debug it from that .slnf file?
I also wondered what happens if you click Continue Debugging?
Yeah it seemed weird to me though, let me try this one.
After i try, i’ll let you know.
By the way, the last ss (the warning one ) i posted was the result of the “Continue Debugging”.
Thank a lot @oguzhankoral
Best.
You can also try to remove bin and obj folders from your project destination and Objects folder from %APPDATA&/Roaming/Speckle/Kits to have a clean start.
Now you’re sorted I’m free to get excited about what have in mind. Are you working on an improvement of the Speckle connector or a custom form with some whizz bang features?
I’ve planned to first improve myself on Etabs and SAP2000 connectors, and - of course - improve those as well.
Then I realized, the Rhino connector seemed to me a more convenient place to start debugging to map the connectivity of code blocks in my mind. I’ve been reading the Dev Docs for a while, and now I can see what is really going on.
After becoming a bit familiarized with Rhino and seeing how Speckle objects are received from authoring apps and sent to another one, I believe it’ll be easier to implement the - hopefully - close procedure at Etabs and SAP2000. Also, I may spot some points to put better functionality into the connectors as I’ve been using those apps for more than eight years.
Do you think my approach makes sense? I’d be very glad to hear from you.
We warmly welcome external contributions to our platform. However, to ensure that we can effectively review and integrate these contributions, we focus on cases where:
A specific problem or improvement opportunity is identified.
There’s an agreed approach to address or implement the change.
The proposed changes align with our submission guidelines.
I can follow the logic of your approach to starting with the Rhino connector to map out the connectivity of code blocks. It’s often helpful, to begin with a familiar territory to understand Speckle Connectors’ broader architecture and workflows. As you’ve identified, understanding how Speckle objects are received and sent across authoring apps can provide a solid foundation for working on other connectors like Etabs and SAP2000.
But, with that in mind, it’s essential to note that while Speckle connectors share a broadly similar architecture, they differ in crucial aspects such as:
Initialization is specific to each host application and generally doesn’t require much external intervention.
Conversion functionality is highly idiosyncratic based on the host application’s API. Contributions that fill gaps in the NativeToSpeckle or SpeckleToNative conversions are particularly welcome.
Capabilities for caching and/or providing a Speckle opinionated experience need careful consideration. When there’s no “right” way to do something, proposing modified behaviour is crucial to review with the Speckle team and our community before implementation.
We strongly encourage (require?) you to share your thoughts and any proposed changes with the community and the Speckle team early in the process. This collaborative approach ensures that your contributions are well-aligned with our mission, values, and technical standards, enhancing the chances of a smooth integration into the Speckle ecosystem.
We’re here to support you in this journey and look forward to seeing your contributions come to life. Your expertise and insights are a great asset to the Speckle community.
Please offer any thoughts on the developer documentation, which we are reviewing for improvement. We document the SDK behaviours more than we do the ins and outs of our existing connectors, so you experience may vary in success with docs alone.
Without a doubt, I will be in close contact with the Speckle Team and will be following the speckle/sharp repository to ensure that any potential changes align perfectly with Speckle’s culture during this time.
As for the documentation, I prefer to analyze technical or reference documents in an academic manner. I believe this approach may better guide external users to gain effective benefits. I must say, the documents are well organized for this purpose. With that said, I will share any logical thoughts if I have in this regard, considering the main mission that Speckle aims for.
