Author Topic: UndoCtl group bit set, new database  (Read 6209 times)

0 Members and 1 Guest are viewing this topic.

nekitip

  • Guest
Re: UndoCtl group bit set, new database
« Reply #15 on: December 18, 2014, 05:46:29 AM »
meanwhile, if you are concerned just to make sure user don't undo all, you can try to add undo mark. This will not solve mystery, but at least users can undo all.
(again, without knowing your code, it's hard to tell)

Code - vb.net: [Select]
  1. Private Shared Sub makeUndoMark()
  2.             Dim db As Database = HostApplicationServices.WorkingDatabase()
  3.             Dim doc As Document = Autodesk.AutoCAD.ApplicationServices.Application.DocumentManager.GetDocument(db)
  4.             Using l As DocumentLock = doc.LockDocument()
  5.                 Using trans As Transaction = db.TransactionManager.StartTransaction()
  6.                     trans.Commit()
  7.                 End Using
  8.             End Using
  9.         End Sub

T.Willey

  • Needs a day job
  • Posts: 5251
Re: UndoCtl group bit set, new database
« Reply #16 on: December 18, 2014, 11:14:39 PM »
I do have a transaction taking place on the newly opened drawing, but that does not seem to matter.


I have narrowed it down even further now.  The issues seems to only be related to dimension objects, but not all dimension objects.  I created a test drawing and added a dimension to it, and it works fine, but the drawing my customer supplied has dimensions that do not work.  For some reason I am getting an error of 'eWasOpenForWrite' each time I use the command.  I selected over 30,000 objects, and only ~1000 objects do not want to be copied, and they are all some form of dimension, AcDb*Dimension.  I make sure not to explode any dimension's BlockTableRecord.  I am at a lose as to why this is happening.  At least I got it down to one type of object, where I can repeat the error.  Now to figure why this is happen with dimensions.  I did try and Downgrade dimension objects, but that had no effect.
Tim

I don't want to ' end-up ', I want to ' become '. - Me

Please think about donating if this post helped you.

nekitip

  • Guest
Re: UndoCtl group bit set, new database
« Reply #17 on: December 19, 2014, 01:35:11 AM »
interesting. never heard of dimensions acting this way
please keep informing us!

P.S.
can it be some of the failed dimensions have text override?
and maybe fields in it?
(shot in the dark)

It's Alive!

  • Retired
  • Needs a day job
  • Posts: 8695
  • AKA Daniel
Re: UndoCtl group bit set, new database
« Reply #18 on: December 19, 2014, 01:57:04 AM »
did you notice any fields? possibly being updated?

T.Willey

  • Needs a day job
  • Posts: 5251
Re: UndoCtl group bit set, new database
« Reply #19 on: December 19, 2014, 10:26:14 AM »
It is not working on any dimensions.  I just looked at one, and it does not have any text overrides.  I also check for fields, obj.HasFields, and if the object is DbText of MText then I convert the field to static text.  When I noticed that dimensions where the problem, I checked to see if they have anything like DbText or MText to convert a field, but saw none.  And, the file does not have any dimensions with fields.

Thanks for the ideas.

Maybe it is the flow of my code that is causing the issue.  The dimensions cause no issue if I do not explode any blocks and the UndoCtl issue does not exist either.  But, when I explode the blocks and call trans.AddNewlyCreatedDBObject( obj, true ); after I call aOwnRec.AppendEntity( ent );, where ent = obj - just the entity version of the dbobject, then the new file will have the UndoCtl issue but the dimensions will be copied over.  If I explode the blocks and only call aOwnRec.AppendEntity( ent ) then the UndoCtl issue is not there but no dimensions will be copied over.

I'm still searching for a way to have my cake and eat it to.
Tim

I don't want to ' end-up ', I want to ' become '. - Me

Please think about donating if this post helped you.

T.Willey

  • Needs a day job
  • Posts: 5251
Re: UndoCtl group bit set, new database
« Reply #20 on: December 19, 2014, 11:35:05 AM »
I just created a dimension object with a field attached in my test drawing.  No matter what I do, I cannot convert, and keep the field converted, in the new database.  I am wondering if it is because I copy it over before the trans.Commit() call?  I would think not, because the objects that get exploded copy over just fine, and they all happen for the Commit() call.

This passage from the Arx docs is a little scary for my current situation.
Quote
Modifying a dimension in a noncurrent database will cause its DimBlockId to be set to NULL. This ensures that the next time the database is loaded as the current drawing, a new dimension block will be created, and the old one will be purged. This is necessary because dimension blocks in noncurrent databases cannot be created or modified. A dimension opened for write in a noncurrent database will have its DimBlockId set to NULL during close. This may generate problems for applications.

Even though I am not changing the dimension block in the non-current database, as I am changing it before I copy it over to the non-current database.

Edit:  Maybe I should clarify a little.  I can change the field to a static value.  I then apply it to the dimension, dim.DimensionText, which is supposed to allow for text overrides, but when I open the new drawing the field is still there showing all 'x' since the link is gone.
From Arx docs
Quote
Setting the text using the Dimension.DimensionText property will override the default value.
« Last Edit: December 19, 2014, 11:38:38 AM by T.Willey »
Tim

I don't want to ' end-up ', I want to ' become '. - Me

Please think about donating if this post helped you.

T.Willey

  • Needs a day job
  • Posts: 5251
Re: UndoCtl group bit set, new database
« Reply #21 on: December 19, 2014, 11:54:20 AM »
Okay, the issue with dimensions and fields is solved, partially.  The issue from the help file still shows ( where the dimension does not show the correct information until it is edited in such a way to cause the dimension to be redrawn, and a regen will not do it ), but hopefully that is a small issue.  How I did it:
step through the dimension block's definition
when an mtext object is found, use dim.FieldToMText( mtext ), using the mtext object found
Edit:[ on the mtext object, use the method ConvertFieldToText.  The above caused errors. ]
remove the field from the dimension, dim.RemoveTextField()
copy the text string from the mtext object to dim.DimensionText

The main issue with dimensions still is there.  Off to conquer that issue.
« Last Edit: January 19, 2015, 10:01:02 PM by T.Willey »
Tim

I don't want to ' end-up ', I want to ' become '. - Me

Please think about donating if this post helped you.

T.Willey

  • Needs a day job
  • Posts: 5251
Re: UndoCtl group bit set, new database
« Reply #22 on: January 08, 2015, 10:40:27 AM »
The main issue seems to have something to do with the 'explode' method supplied by Autodesk's API.  When I build my own 'explode' function, the UndoCtl variable is set correctly, but I run into an error.  I forget the exact error now, but it stated something like 'max reader' reached.  When looking on the net I saw mention of this and opening an object too many times, which makes sense since when I start a drawing could I have 800 items in it, but when I'm done it will have 38,000 items.  I also read what when using 'DeepObjectClone' you have to call it once per owning object, so that my be where my issue of 'max reader' is arising.

I will continue to post in this thread until I am done with the project, just in case anyone might find it useful in the future.  Thanks again.
Tim

I don't want to ' end-up ', I want to ' become '. - Me

Please think about donating if this post helped you.