The short answer to your question is yes. All this can be done with automation scripts. None of it is particularly difficult.
To begin, I'll make the assumption that your price property is annotated onto the parts when the parts are placed on the schematic. If this is true, then don't worry about DxDatabook at all. Once the part is on the schematic with some property annotated, then DxDatabook is out of the picture as far as reading the property value and turning the visibility on or off.
Next I'll assume that you have a working script that is capable of making a connection to an open session of DxDesigner. For the VX.1 release and forward, there are some steps to take that have been a bit tricky for some of us. This has been fairly well covered in other discussions in this forum, so I won't go into it here unless we find you have specific questions about how to do it, or have no working example scripts at all to start with.
With those two assumptions out of the way, what we have left to do is the following:
0. Use a global variable of the appropriate type to store the sum of the component prices.
1. Get a collection of all design parts. This can be done without visiting each page of the schematic.
2. Loop through the collection.
3. For each part, decide whether or not it is a valid component part. I say this because the function which collects all design components picks up the power net taps, off-page-connectors, and so forth. These parts can be skipped. An effective method I've used to do this test is to see if the component has a reference designator property and if it has a value. If so, it's probably a valid installed component. Even so, I have to eliminate things like mounting holes and E-points, because they will be built into the board.
4. Now we are down to an individual component in the collection we are looping through. We can now get a reference to the specific property of interest, if we know the property name. We get the property's value, and add it to the price summing variable. Then we set the property's visibility so that the property is invisible.
Here is an example script subroutine with the basics of what you need:
Dim n As Integer
Dim scomp As ViewDraw.Component
Dim price_sum As Double
Dim attr As ViewDraw.Attribute
Dim missing_price_property As String
Dim design_name As String
scomps = Nothing
'load all components into scomps. scomps will get a reference to every component in the design
design_name = app.GetProjectData.GetiCDBDesignRootBlock(app.GetActiveDesign())
scomps = app.DesignComponents("", design_name, "-1", , False) 'gets all the components in the design
missing_price_property = ""
price_sum = 0
For Each scomp In scomps
if scomp.refdes = "" then goto next_scomp 'eliminate any component without a refdes
If instr(scomp.refdes, "E") = 1 Then GoTo next_scomp 'elimnate E-Points
If instr(scomp.refdes, "MTG") = 1 Then GoTo next_scomp 'eliminate mounting holes
attr = scomp.FindAttribute("price") 'get the price property
If Not attr Is Nothing Then
price_sum = price_sum + attr.Value 'add the price property value to the price sum
attr.Visible = False 'make the property invisible
missing_price_property = vbCrLf & scomp.Refdes 'if no price property is present, report it
MsgBox("Total price is " & price_sum)
If Not missing_price_property = "" Then
MsgBox("The following components are missing the price property:" & vbCrLf & missing_price_property)
Note: app is defined elsewhere in the script startup stuff, and as I said, I assume that you have a working script that creates app and hooks it to the DxDesigner session successfully.
If any of this leads you to more questions, please don't hesitate to make it known.
Thanks for your help but the problem is this if I annotate the property on to the part I can`t make it invisible on a PDF export ore edxd file.
That’s way I would like to get the price from dxDatabook so it is not visible on Digital doc which could be sent to Customers by accident.
Is there a other way to get to the price Information without annotating it ore then make it invisible for customers.
I have been under the impression that any property on a component can be made invisible or not, so I'm unclear on why and how this is a problem.
Perhaps there is a setting in the Property Definition Editor preventing this? I'm not certain that it would or could. Or perhaps the PDB has the property and locks it as visible?
I don't believe I've encountered this problem as you describe it.
to me, this sounds like you should try to access the Database directely,
and query the Data (=price) out of it like mentioned here:
May this help ?
I could not find a possibility to prevent this in the Property Definition Editor.
As u See in the pic if I annotate the Property from Dxdatabook it is not visible on the symbol but it is visible in the Properties Window.
The same thing happens if I create a PDF from dxdesigner the property is invisible on the sheet but if I right click on the Symbol I am able to see all attached properties including price.
We do not want our customer to know wat prices we get for our components that’s the reason way I would like to be able to get the information direct from Dxdatabook.
1 of 1 people found this helpful
I understand now. I was not clear that you did not want to annotate the property to the component when instantiating it on the schematic. So as you are probably aware, you need to set this property to not annotate in your DxDatabook configuration. You can also prevent the properties from being attached in the PDF export, but there's a decent chance that someone will do this wrong and the properties will be available in the PDF as you have indicated.
So, the answer is to access your database directly, as indicated by fuba. Check out that thread he linked. We went over this recently. So you will need to write a script that gets all your design components, but then also goes out to the database to collect price info for each part.
It seems the general concept many people have is that DxDatabook is a data source. It is not. It's just a window to the real data source. And a fairly dynamic one at that, which is constantly displaying different information that it gets from the data source.
You will find as you begin to work directly with your database that it's not very hard to do. SQL is a very straightforward syntax and it's very powerful. Also accessing the database directly is very fast. At least in my case it is, with a database of around 6000 - 7000 components, and stored on a network server in our building. Other, more distant data sources may be slower.
Hi Thanks Patrick and Fuba
i will try to access the database