Author Topic: .NET application error in AC2022 but not AC2017  (Read 2601 times)

0 Members and 1 Guest are viewing this topic.

Keith™

  • Villiage Idiot
  • Seagull
  • Posts: 16899
  • Superior Stupidity at its best
.NET application error in AC2022 but not AC2017
« on: November 30, 2021, 01:18:00 AM »
Operation is not valid due to the current state of the object

My understanding is that this is caused by improperly committing the transaction too early, not at all, or improperly accessing the wrong database.

None of these are happening .. it's create transaction, modify database and commit and it works time and again, but always seems to fail after insertion of new blocks.

Any ideas?
Anyone seen this previously?
I've read the Autodesk posts concerning this error to no avail.

Also, do I need to build using the 2022 references to the following? Could that be the issue?
accoremgd.dll
acdbmgd.dll
acmgd.dll
AdWindows.dll


Proud provider of opinion and arrogance since November 22, 2003 at 09:35:31 am
CadJockey Militia Field Marshal

Find me on https://parler.com @kblackie

It's Alive!

  • Retired
  • Needs a day job
  • Posts: 8659
  • AKA Daniel
Re: .NET application error in AC2022 but not AC2017
« Reply #1 on: November 30, 2021, 03:13:02 AM »
It’s probably a good idea to make a build with the latest libraries, just to see if there’s functions that are marked depreciated or obsolete. 
these only show a compiler warnings

CADbloke

  • Bull Frog
  • Posts: 342
  • Crash Test Dummy
Re: .NET application error in AC2022 but not AC2017
« Reply #2 on: December 05, 2021, 02:02:58 PM »
Does calling / running AUDIT on the drawing help? I have seen AUDIT solve these kinds of mysteries before.

What is in the new blocks? Possible ATTSYNC issues?

It's Alive!

  • Retired
  • Needs a day job
  • Posts: 8659
  • AKA Daniel
Re: .NET application error in AC2022 but not AC2017
« Reply #3 on: December 06, 2021, 01:59:09 AM »
If I had to guess, I think this is when the switch was made from fibers to threads,
So its probably an object or transaction left open too long, something was opened on another thread, something along those lines.
Could be some bug that's just now exposed due to this change.


Keith™

  • Villiage Idiot
  • Seagull
  • Posts: 16899
  • Superior Stupidity at its best
Re: .NET application error in AC2022 but not AC2017
« Reply #4 on: December 06, 2021, 05:27:39 PM »
Well, I'm going to recompile with the 2022 libraries and see if that makes a difference, but I've got to rebuild my WM and reinstall the software.
Apparently the VM I have been using doesn't support .NET4.7 and that is the minimum requirement to build to the 2022 libraries.
Proud provider of opinion and arrogance since November 22, 2003 at 09:35:31 am
CadJockey Militia Field Marshal

Find me on https://parler.com @kblackie

CADbloke

  • Bull Frog
  • Posts: 342
  • Crash Test Dummy
Re: .NET application error in AC2022 but not AC2017
« Reply #5 on: December 06, 2021, 08:54:30 PM »
I build CAD Replace with the v2013 libraries and .NET 4.7.2 - I have never seen that error, even in the even-more-buggy-than-before ACAD 2022.

Is any of the processing done off the UI thread?

Keith™

  • Villiage Idiot
  • Seagull
  • Posts: 16899
  • Superior Stupidity at its best
Re: .NET application error in AC2022 but not AC2017
« Reply #6 on: December 06, 2021, 09:36:52 PM »
The way the application works is that the user selects data files to import into the drawing. The data is processed and then an insert jig is called to insert the block. After processing all of the data and inserting all of the blocks the application then turns off attributes visibility based on its value.

The blocks are inserted without issue and then the error is thrown.

I initially thought it was the toggle routines but then if I use the toggle functions alone, they work fine and do not throw an error.
Proud provider of opinion and arrogance since November 22, 2003 at 09:35:31 am
CadJockey Militia Field Marshal

Find me on https://parler.com @kblackie

CADbloke

  • Bull Frog
  • Posts: 342
  • Crash Test Dummy
Re: .NET application error in AC2022 but not AC2017
« Reply #7 on: December 06, 2021, 10:38:57 PM »
What type of object is throwing the error? Is the type or object consistent. Does running an AUDIT command or Database.Audit at any stage help? The AUDIT command is AutoCAD's version of the "This is fine" meme. Ho are you toggling the attribute display? ATTDISP command?

Perhaps try RecordGraphicsModified(true) on the Attributes and/or block insertions ? That's probably just for rendering so it may not be relevant. Does the Attribute visibility make a difference to the crashiness?

Keith™

  • Villiage Idiot
  • Seagull
  • Posts: 16899
  • Superior Stupidity at its best
Re: .NET application error in AC2022 but not AC2017
« Reply #8 on: December 15, 2021, 06:00:53 PM »
I wish I knew, but I don't. It's only throwing the error on 2022 so I can only presume it has something to do with some changes in the underlying libraries I am referencing.

The blocks are standard blocks with nested blocks in them. The blocks have a series of attributes associated with them.

When toggling, the function creates a selection set, opens for read each block, then iterates through each attribute. If the tag matches a filter, UpgradeOpen is called, the visible property is set to false, then DowngradeOpen is called. Once the iteration is completed, the transaction is committed.

Toggling the visibility makes no difference when using it independently of the insertion process. It only happens when the blocks are inserted.

When I get a VM I can test on, then it will be easier to isolate.
Proud provider of opinion and arrogance since November 22, 2003 at 09:35:31 am
CadJockey Militia Field Marshal

Find me on https://parler.com @kblackie

n.yuan

  • Bull Frog
  • Posts: 348
Re: .NET application error in AC2022 but not AC2017
« Reply #9 on: December 16, 2021, 09:19:51 AM »
Just a thought to narrow down the possible cause: do you change Entity.Visiable property to toggle the attributes' visibility? If so, you may want to try to toggle AttributeReference.Invisible property instead, to see what happens.

Chumplybum

  • Newt
  • Posts: 97
Re: .NET application error in AC2022 but not AC2017
« Reply #10 on: December 20, 2021, 05:28:27 PM »
is upgradeopen done on the blockreference or the attributereference? Another thought, how much nesting do you have in the blocks... you may have to upgradeopen all the way to the top


cheers

Keith™

  • Villiage Idiot
  • Seagull
  • Posts: 16899
  • Superior Stupidity at its best
Re: .NET application error in AC2022 but not AC2017
« Reply #11 on: December 21, 2021, 05:49:50 PM »
is upgradeopen done on the blockreference or the attributereference? Another thought, how much nesting do you have in the blocks... you may have to upgradeopen all the way to the top


cheers

UpgradeOpen is done on the attribute reference.

the block def is sort of like this
{BLOCK_REF {BLOCK_REF}{BLOCK_REF}{BLOCK_REF}{BLOCK_REF}{ATT_DEF}{ATT_DEF}{ATT_DEF}{ATT_DEF}{ATT_DEF}}

I just had a thought ... the block parent block may need to be upgradeopen too because I am modifying the visibility of nested blocks as well as attributes. I hadn't thought of the nested blocks previously because I was so focused on the attributes.


Just a thought to narrow down the possible cause: do you change Entity.Visiable property to toggle the attributes' visibility? If so, you may want to try to toggle AttributeReference.Invisible property instead, to see what happens.

Entity.Visible is what I change ... I'll take that change under advisement and see what happens.
Proud provider of opinion and arrogance since November 22, 2003 at 09:35:31 am
CadJockey Militia Field Marshal

Find me on https://parler.com @kblackie