OK, so the base build is humming, now to value add.
I want to take my base families\parts and keep the levels for modelling, but have the levels and colours change when creating a DV. This way I can mdel in our build and output drawings to client requirements. I'll do this using rules, as I have done with DEM, and the Family\part Drawing Symbology.
My issue is that I can't get the output to use a different level to the modelled member. If I force some settings like colours in the rules they come through, but the new level isn't being used.
Iis there a way around this as I have more than 1 bild to do this way.
Thanks,
Can you elaborate on how the rule is defined?
Rules are where they are usually kept I would have thought??
Works as intended in DEM.
Steve, I haven't fully tested CE, but not looking promising. Any help on this is appreciated as it means some large changes to our build and workflows if it doesn't work. I'm prepared to go back to DEM and wait for CE to work fully if that's what it takes.
Hey Sean
Are the dgnlib files from the client pre-Aecosim? I was finding odd things like this happening when using old dgnlib files. Another thing I found was the client seed files or when users were using old seed files and wondering why the views were working.
Quick question, have you worked out how to move the widgets like you could with DEM? I submitted a SR about 3 months ago and they still don't know what I'm talking about. Not Steve obviously he's awesome.
I don't have any problems as long as I'm using the same level and the structural elements. As soon as I want to use levels different to those in the model I get chaos. At this stage I'll be going back to DEM and staying in V8i until the growing list of issues can be resolved.
Haven't found an equivalent to Manipulate Structural Graphics in DV either.
Also, in regards to the Widget - keep in mind that unlike DEM, the graphics displayed in a dynamic drawing are not "real" elements that can be controlled like that. If adjusting the position of the widget using the applicable rule isn't sufficient, I suppose you could cache the drawing and use the Copy/Hide command. You could then Fence Stretch the widget block and the attached single lines. A bit "fudge-ish" perhaps but it would work in a pinch.
Steve, I suppose you can see why many of us are disappointed with the demise of DEM. Issues like this may seem small to some, but it is a huge time waster for us. Moving text etc in a DV isn't the same as it reverts back if a change is made. I'm not saying DEM was perfect, but it is a better base to build from compared to DV. JMO.
Yes, I do understand that certain aspects of DEM are missed. DEM itself just wasn't sustainable through the 64bit port to CONNECT.
As for moving drawing annotation, I believe we have an Enhancement (or two) filed that request something along the lines of what you're describing; e.g., retaining the current coordinates after being refreshed. The best bet is probably to file an SR to link to that enhancement. If I'm mistaken and one does not exist, then we can certainly file a new Enhancement.
SR7000827770 raised.