TheSwamp
Code Red => .NET => Topic started by: rugaroo on September 02, 2017, 04:49:20 PM
-
Ok, I have been toying around with setting up the majority of our blocks to use multiline attributes in blocks where it makes sense. The issue I am running into is that when I insert the block via .Net, the multiline attributes come in on top of ALL linework. This does not really work for me at all. So I started digging around and found that this is a quite common issue. Kean Walmsley has a decent post in C, and I was able to convert it all over and get it working for the most part, but the mulitline attributes will not change the draworder regardless. Below I have my current iteration of the function I am using where I bring my linework to the top as opposed to sending the attributes to the back. At first I figured that there was something I was missing considering it is a Dynamic Block I am trying to "fix" but, it works just fine except when trying to bring the line to the top of the multiline attributes. I have verified that the block is setup correctly. Are any of you doing this with any of your blocks? Or is there a method to where I can create an ever changing wipeout that adjusts height and width to the multiline attribute? I am trying to refrain from heading the hatch background route, and I don't think I'd like to start putting borders around all of attributes. Open to suggestions and ideas though.
Private Shared Function _MoveLineTop(_Trans As Transaction, _IDColl As ObjectIdCollection) As ObjectIdCollection
Dim _BlkRecIDColl = New ObjectIdCollection()
Dim _SpecClass = RXClass.GetClass(GetType(Line))
Dim _BTRIDs = New ObjectId(_IDColl.Count - 1) {}
_IDColl.CopyTo(_BTRIDs, 0)
For Each _BlkTblRecID As ObjectId In _BTRIDs
Dim _BlkTblRec = DirectCast(_Trans.GetObject(_BlkTblRecID, OpenMode.ForWrite), BlockTableRecord)
Dim _Line = New ObjectIdCollection()
For Each _ID As ObjectId In _BlkTblRec
Dim _AttEnt = DirectCast(_Trans.GetObject(_ID, OpenMode.ForRead), Autodesk.AutoCAD.DatabaseServices.Entity)
If _AttEnt.GetRXClass().IsDerivedFrom(_SpecClass) Then
_Line.Add(_ID)
End If
Next
If _Line.Count > 0 Then
Dim _DOTbl = DirectCast(_Trans.GetObject(_BlkTblRec.DrawOrderTableId, OpenMode.ForWrite), DrawOrderTable)
_DOTbl.MoveToTop(_Line)
Dim _BlkRefIDs = _BlkTblRec.GetBlockReferenceIds(False, False)
For Each btrBrId As ObjectId In _BlkRefIDs
_BlkRecIDColl.Add(btrBrId)
Next
Else
_IDColl.Remove(_BlkTblRecID)
End If
Next
Return _BlkRecIDColl
End Function
-
If your block in interest is a dynamic block, you might run into the same issue as I had, about which I wrote here:
http://drive-cad-with-code.blogspot.ca/2013/11/draw-order-problem-with-dynamic-block.html (http://drive-cad-with-code.blogspot.ca/2013/11/draw-order-problem-with-dynamic-block.html)
As I guessed in my article, when dynamic property change results in a new anonymous block definition being created by AutoCAD, it is possible the block creating logic follows AutoCAD's owner recommendation for manually block creating: selecting non-attributes entities first, and selecting attributes in backward order of them being listed in attribute editing dialog. So, it is likely, when creating the the new anonymous block definition, the attribute, be it MText or not, is the last one (or last ones, if there is multiple attributes) being added into the block definition, thus, the attribute would be on top of the block definition's DrawOrder table.
That is, even you set a correct DrawOrder in your dynamic block definition, the attribute draworder could be reset to "Top" by AutoCAD, because of dynamic property change. Again, I claimed in my article, this is purely my speculation, but it seems making sense.
-
I see what you are saying, and I actually ran across your article in my search of how to handle this issue... The part that puzzles me is that say I choose to bring all lines to the front, this works, provided they are not "behind" my multiline attribute which has masking built into the coding that inserts the desired block. I am curious if this is due to the block becoming anonymous after changing the visibility state upon insertion. If that is the case, then do I need to "edit" the anonymous block instead of the originating block? The part that frustrates me is the fact that if I insert the dynamic block the "old fashioned" way, then everything, including the Draw Order works just fine, even after inserting and then changing the visibility state. Maybe, I need to rework my blocks to start with the display state that is having the issue considering there are currently only two states defined. I will mess around a bit more later and see what else I can break. :tickedoff:
-
Ok, well I gave up for now at least in regards to Multiline Attributes with a background mask... As a result, I decided to use standard wipeouts and then use linear stretch parameter sets which I can then change accordingly as I insert the block via .Net. Now, granted I still need to send the wipeouts to the back, at least this really works.
As a result of the way I have it set up, I am curious of something else. Currently I am hiding the properties and grips of the linear stretch parameters for the wipeouts in the blocks I am using, but I am wondering, for items like this, what is the general consensus in regards to hiding stuff like this? I do under stand that users "may" need to adjust this if they override what is put in programatically, but in the time it takes to edit it manually, the can be done with my custom command with a wipeout that is automatically sized... Thanks!