thanks for sharing your concerns about the incomplete support of Automation in the library environment.
As mentioned in the other posting we are anticipating Library services to get Automation as well in the near future.
Please don't hesitate to share your specific use cases in the library environment, so we can validate that they are covered.
We just updated the form to be downloaded.
This form and your input will help us to make sure that we identify any additional gaps.
i also have the feeling that when we could export to ascii, it is a readable format and everybody can change this rapidly... and import it back again.
not everybody has a programming background, and automation is nice to have but not everybody can jump into automation from now on.
in order to change stuff through automation, my feeling is that people need to have some kind of programming background.
Okay so I was using the wrong data model for what I am attempting to accomplish. I need to be referencing the Part Editor data model which appears to give me access to everything I need in the library.
So heres the vbs reference:
And heres the real question since I code my automation in vb.net. What file do I need to reference to get access to this data model?
nevermind I figured it out
You are right with the observation that not everyone can program. It is a while ago for me as well.
The goal with the 7.9 release was to get our customers moving away from HKP editing and toward automation. It seems that some of the use cases that our users have, may not be adequately addressed today but that's the reason we started in June 2010 to get everyone (our customers and ourselves) on the same page and to mutually work toward a better solution. We knew that there would be some customers who would require HKP editing in 7.9 and to that end we created licenses for HKP decryption and a separate license for encryption. HKP will still be available for customers in need as we go through this migration in 7.9.
We also need to make the usage of Automation easier for guys like you and me, who do not have the proficiency in programming. Tutorials are a starting point. But the real benefit will be sample code and snippets that help you using VBScript or another language to manipulate data. And we will share these code samples in this community. We also encourage users to share what they have.
We can and will be extending both, automation and our tool's functionality itself to handle the use cases that you, our user, identify as critical.
In addition we are creating an open format for the export and import of library data. The schema and files will be encrypted but you'll get the editing tools as a user. We are still working through this effort. This means that customer input on library data manipulation outside of the editors will be helpful to ensure that this schema is comprehensive.
Our engineering team is reviewing your input and is responding to our customers input quickly.
We are committed to your success and when we finally stop supporting HKP files, you will have a superior solution.
Thanks for the input on mentors strategy.
Now lets put my commen sence to what you say.
Way make a tool and spend mentors and our money and time that in principle does the same as Library Services import ASCII.
Library Services checkes (in the past at least) the data format and the data consistancy between the imported (Cell,Symbol and PDB) before puting it into the library and the LCM index file. ask thethe old people VB in the hundsvile office. However when Mentor moved to Viewlogic DxDesigner Symbols weended up having several enteties (ASCII files) for rotations and it then become difficult to get those pins of every file checked and compare time stamps of the latest version. (4 rotations-, 4 files-, 4 time stamps-, 4 possible pin names and numbers-possible) so what whitch one should Library Services check against?
I think we should put effort in geting the Dx Symbols into one container (file) for all rotations. (leave the ASCII) then checking Pins versus PDB pinmappping becomes easy again for Library services. Put the old checking code back and your problem with corrupted Libraries is fixed. and you help Migrate DC custmers to DXDesigner. (Wouw, 2 things with one effort)
I can see some benefids in the PCB tool ASCII eleminations. But then again rememer that as an AE i fixed could fix a corrupted Database by ASCII out/In. For instance that (thing) that was moved for some reson at a far far away coordinate so when view all we ended op wit a bord of 0.1 mm. And there were more, speak to your support people.
I suggest to bring the ASCII in/out back until mentor fix ALL these problems. OK then you don't get the feadback. But you don't make us happpy custmers nor more productive as this discusion itself alredy takes a lot of time and Money. And these people ave already spend some time and effort to learn automation and figure out the data model. it's onlt 10 % of all users to may best estimate. the others dont bather and fins a new migration pass or stick wiht 2005 / 2007.8 with theASCII in/out functionalaty. Missing all the great stuff you implemented in the new release.
I suggest to bring the ASCII in/out back until mentor fix ALL these problems.
I may repeat what was said earlier. But I think it is important:
HKP is not gone yet. It is still there. It just requires a special license. And licenses are granted to users who share their valid use case with us, so we can understand the usage.
Ultimately, our goal is to make sure we have a better solution, which is sustainable in the products going forward, reliable, and usable for all customers, providing the same and better capabilities.
Our plan is to replace HKP, and HKP only. And we understand that we may be a year away from being able to do that. This is why we are starting this process now, making sure we are accounting for the use cases that have been share with us.
I needed a way to extract information on parts in our library. Prior to 7.9 we would just convert the pdb files to hkp files, decrypt the hkp, and then use a script to put the data into a useable format for us. My first issue was assuming that Automation for Library Manager was the route I needed to go to extract part information. What I really needed to be using was the PartsEditorDlg model. Once I was using the correct library everything was pretty easy to extract. The attached code can be used as a template to extract parts data from your library. My appologies for my incorrect acusations in the op, the capability was there, I was just looking in the wrong place.
PDBEditor_Example.txt.zip 1.1 KB