I would like to open up a discussion about what we (the community) want and expect out of the Solid Edge SDK. I see this as an opportunity for us to provide constructive guidance and direct input into what Solid Edge puts into their future SDK's. Please be as specific as possible. Feel free to list items that have already been listed by others.
Here is my quick list.
Regular updates between versions.
More embedded code examples of API's.
Add examples for Synchronous API.
Need more complete examples in the Custom folder.
Posted by: Jason Newell
Post date: 8/18/2009 9:17:31 AM
4. Glossary of terms used in help manual.
5. Concept Manual - Explain concepts that span across multiple API tasks.
In case Volunteers are needed, I am ready.
Posted by: Vilas Date
Post date: 8/18/2009 9:35:16 AM
You pretty much nailed my wishlist...
I would add, although it really goes without saying, that the code examples should be well commented, clean code in different languages - I haven't looked at them in a while, but the auto-upgraded version (from vb6 to .net) of the nSidePolygon macro made my stomach turn...
Just my 2c
Posted by: Calum McLellan
Post date: 8/18/2009 10:30:56 AM
In SolidEdge SDK on the fly examples are very few and not much explanatory.
It should be like a live help, like the help given for Modeling.
If some one has to start learning then it is very difficult to understand and time consuming.
Posted by: Sandeep Shewale
Post date: 8/18/2009 10:52:16 PM
totally agree with previous comments.
- Better Documentation (some function are present in the help, but it's difficult to figure
out ho wto use it).
- Examples in VB,C# and C++
- SolidEdge should include Visual Basic for application
- Macro recording and playing capability
This will help also beginners to record actions, see how things are done
and use this as a template to start developing.
Posted by: Massimo Magris
Post date: 8/18/2009 11:42:25 PM
i also totally agree with previous statements.
In future releases of Solid Edge (SDK) i wish more or enhanced capabilities of manipulating Solid Edge data files without the need to use Solid Edge (COM) automation.
Typical tasks which currently scale bad are
- web browser capable viewing and structure analyzing of Solid Edge data files using actual web technology
- file conversion and printing
- property management also for multithread environments
Also a new Solid Edge file format, zip-container and XML based, similar to Microsoft's new Office 2007 file format, would probably be very convenient to be processed by .NET languages using LINQ etc.
Posted by: Wolfgang Kunert
Post date: 8/19/2009 4:04:27 AM
And very big. One problem with XML is the data is string based. Works fine for files that are basically string based (like Word). But binary data, like your modeling data does not fit the mold. XML supports binary data, but then the format of the data has to be known in order to make sense out of it. And it has to be further encoded on write and decoded on read, slowing you down. Also, as far as I know, there is no compound storage capabilities - modify one part of your xml data and you have to rewrite the entire file back out. So you might end up with an XML file, but the data in it will essentially be no different that what is in an edge file now and you will find that very large xml files will bring along other problems - such as speed of file open, save and close.
Posted by: R.D. Holland
Post date: 8/19/2009 9:57:58 AM
Hi R.D. Holland,
you are right, but i meant using the idea of splitting a Solid Edge data file into different files under the hood of a zip container so that you could have maybe easier access to meta data like properties, physical properties, material, variables, links, references etc. Working with the binary components would not be required.
Posted by: Wolfgang Kunert
Post date: 8/19/2009 9:55:51 PM
Dear Jason, I think that there should be more examples of C++ and new C++ wizard for latest Visual Studio version.
Posted by: assassin 007
Post date: 8/25/2009 5:54:50 AM