Currently when I need to access item within list I'm using nth function. It works ok but I think that standard VB style access would be even easier especially for developers who have experience with other programming languages.
in addition to:
When creating new ETO model in Inventor it would be usefull to have command which directly opens corresponding factory part either for selected part in ETO Model Browser or selected component in the assembly.
Currently I need to locate file manually which can be tedious for complex designs with lot of components.
Inventor Project Window is too small, cannot be resized larger.
Folder names and file names that are more descriptive and helps searching.
These long paths are not fully displayed in the Project Window.
In the current Project Window it is necessary to select a project then select the
browse button to see the full path.
see screen shot of Project Window
This one might be hard to explain. And a bit picky, but oh well.
I have a part that is 136.1875 inches long.
I want to scale the part down to be exactally 10 inches on my drawing. So I apply the formula 1/(136.1875/10) to get the scale to apply to the view.
My viewscale that I see in the intent model properties is 0.07342817806333 which is close to the number I get with my windows calculator(0.07342817806333180357962368058743).
However, when I look at the intent model width property I see a value of 10.0000000005782. When I use 0.07342817806333 * 136.1875, my windows calculator shows 9.999999999999754375. When I use 0.07342817806333180357962368058743 * 136.1875, my windows calculator shows 10.000000000000000000000000000001. Where did 10.0000000005782 come from?
Anyway, I'm wondering if this has anything to do with the intersection of inventor accuracy and ETO accuracy? Inventor's 100 millionth vs ETO's 10 trillionth = inconsistancy
point(1,0,0) + (unitZ * 3) = point(1,0,3)
0 * 3 does not equal 3. This is really confusing and really irritiating when you're trying to learn this software.
Point(1,0,0) + (unitZ + 3) = Point(1,0,3) makes more sense. My opinion anyway.
As it stands, the ETO documentation has improved greatly from a year ago. What's lacking is documentation describing when to use specific features. I suggest to make a best practices knowledgebase which answers questions for anyone looking to start a new project.
Some example answers might include:
This may look like a lot of suggestions at once. All I'm asking is for someone who has built a number of ETO projects to put a bunch of advice somewhere ETO developers can read it. The more topics covered the better.
I'd be happy to clarify since each of these are problems I've run into over the last year. I'd be happy to clarify or give a longer list if anyone wants.
It would be extremely useful to have Level of Detail support in assemblies. It's very common for customers to use levels of detail in their drawings and without this built in one either has to code their own mechanism to create the levels of detail or set the hidden parts rule on the drawing views to hide the components that they don't want. The hiddenParts approach is slow and leaves the customer with a drawing different than what they would create manually.
It would be very useful if we had a couple of dropdowns that included Children, Methods, and Rules as it is with .net. In .net, it lists all of the methods in the active class. This would be useful in the Design Editor as well as in Visual Studio when you are working with design files.
This would be especially useful on large designs where you may have lots of rules and/or children. You should be able to click on an item (ex. "Length") and the window will jump to that rule.
It would be very useful to have a #Region directive in the Intent language as there is in .net.
For those unfamiliar: http://msdn.microsoft.com/en-us/library/sd032a17%2
Basically regions allow you to expand/collapse sections of code. This makes organization much easier.
#Region "Child Rules" Child testCenters As :IvSphere, Quantity = Length(testParts)
origin = GetTestPartPoint(child.index)
ignorePosition? = False
Radius = 5
color = "Green"
End Child #End Region
Method GetTestPartPoint(mIndex As Integer) As Point
Dim xyz As List = nth(mIndex, testParts).CenterOfMass
Return Point(first(xyz), second(xyz), third(xyz))
Sorting by the values in the properties grid will give us the ability to more easily find rules based on the expected values. This is especially helpful when working on datasets by others who have not properly documented the rules in a way that it is easy to find the rules in question. In the case below, I know that the tank is 72 inches tall from my measurement of the Inventor model. If I could sort by the Values then I would be able to very quickly find that the associated rule is very likely TankHeight. My understanding is that the grid below is a DevExpress grid and column sorting is a property setting. That simple and quick change would be quite helpful for debugging.