Topic: BricsCAD: Inserting BlockReferences via .NET - winform (unstable ?)

[Bert]

Hello guys !

We are having some unpredictable behavior in BricsCAD after inserting BlockReferences via .NET .

We've got a function that inserts a collection of BlockReferences (+ fills out Attributes) in modelspace.

When this function is called via the command-line in BricsCAD all goes well.
Meaning: all Blocks got inserted in modelspace as desired, all attributes recieved the correct values & the blocks are free to manipulate & erase when needed.

Problem occurs when the exact same function is called via a windows-form.
We've got a *.dll that holds a form allowing the user to make a 'selection' of what he wishes to insert.
It basically boils down to a button-click on the form calling the same 'insert-function' discussed above.

Inserting all Blocks in modelspace *seems* to go well. But as soon as we select & erase them via the GUI the Blocks remain drawn in modelspace, only to disappear by entering the 'Regen' command. In this state one is unable to select these Blocks in any way.

Any ideas why this could be ?
Cheers,

Bert

[TMoses]

This sounds as when an extra reference to the BlockInserts and/or Attributes is kept open ...
this usually results exactly in those effects as you described.

Please check your code if there is an unintended reference active ...
(besides we are already working on your support request).

Many greetings !

[MickD]

Also, make sure you are 'commit'-ting your transactions and 'locking' your document when asking for user input from your dialog

[Bert]

Both very valid remarks, but ..

The function handling the inserting & setting of the blockreferences is one and the same.

When the function is called via the command-line in BricsCAD (we added an <CommandMethod("runInsert")> to it so we can call it) all goes well.

When we call the exact same function from a form, the newly inserted blocks behave oddly. When we select & delete them, they remain drawn on screen untill a 'regen' is triggered.

Would this have to do with threading ? Depending from wich thread ('winform GUI' or 'BricsCAD application') this function got called from ? 


The 'temp' fix we got in place is instead of calling the insert-function from the button-click event on the form, we do a  'acDoc.SendStringToExecute' to call the function via the command-line 

[TMoses]

Maybe, you need document-locking ? At least, when you call your function from a modeless dialog ... ?
I hope this helps a bit ...

[Bert]

Thanks TMoses for the support.
The VS-Solution you guys provided confirmed what we knew; our code works in a very similar way.
But it made us look closer to the function that handles all the insertions of every BlockReference we use in our code and we found the error :

In that function, for some reason the TransActionManager.StartTransAction was called based on the acDoc, and not on the acDoc.Database !
(hiding in a small corner ..)

So this fixed all unwanted behavior.. thanks for the aid !
Regards,

Bert