Microstation V8I .NET exception after undoing dropped element

Sorry for the delay in response to your issue. Is this "complex elements or feature" something that was produced in Bentley Map or is this unrelated? Did this error appear again after you followed the suggested workaround in the provided old discussion?

https://communities.bentley.com/products/microstation/f/z_-archived-microstation-v8i-forum/90632/element-information-use-causes-crash

Have you thought about upgrading to the latest version of Bentley Map | OpenCities Map?

https://www.bentley.com/en/desktop-applications

Hello! Thanks for your reaction.

The complex elements I talk about (composite of multiple elements) are being created using MDL API. All of the operations of them are working correctly (even the drop element tool used on them), so I don´t think they are the cause.

The dialog window I´ve attached is my calling too, but its ordinary Windows API MessageBox. After I click No option, I just undo last action (that is dropped element, as in my case I´m reacting to changed state of currently dropped element - thats new finding and I will update it in the question too). Thats when the exception occurs. However, I can´t really react to it as its coming from the .NET and is leading me into the MS code base.

Old thread I linked in the question helped me a little bit, as the workaround I mentioned is working correctly and this exception is no longer present, after I apply the mentioned steps. 

Hello.

Jan Šlegr said:

Because you do not use MicroStation, but Bentley Map, I strongly recommend to move this discussion to OpenCities Map forum. The issue is likely specific for Bentley Map and not common to MicroStation.

To move existing post, use More > Move tool available under your original post.

You are right, thanks. Will move it to the Bentley Map section.

Jan Šlegr said:

What tool do you use? Standard Drop element tool or something else (key-in, VBA macro...)?

Standard Drop element tool.

Jan Šlegr said:

So is it that you confirmed dialog "It is not possible to undo this operation" and when you use Undo, the exception is thrown?

I try to undo the operation in code, by result of my own dialog (shown in the first picture). So when I click 'No', I call mdlUndo_undoActions(1). Then the exception is thrown.

Jan Šlegr said:

One more question: In what "project mode" do you use Bentley Map? mslink based database, "DGN only" XFM project, XFM project based on data in spatial database, no project (just graphical edit)...?

DGN only.

Thanks for your reaction.

Hi Lubo,

honestly, I am confused a bit and I still feel I do not understand the situation right.

What is your exact workflow?

1. A complex element is created.
   btw Can you share an example?
2. You use Drop element tool (clicking icon in Toolbox)
   But how your dialog knows you use Drop element tool?
3. When No button is clicked, you call mdlUndo_undoActions()
4. Exception is thrown

More questions:

• How and when you set undo buffer?
• In what transaction context you are modifying DGN file?

Regards,

  Jan

1. Actually I didn´t pay much attention to the possibility of "bad" element creation, as everything works fine, except this one particular case. And even with that, after applying my workaround (I mention it in question), the problem disappears.

2. I setup a callback to CHANGE_TRACK_FUNC_Changed. Thats when I spawn my dialog, because it means the user might have dropped some of the elements. During that callback, I spawn my dialog. After declining this operation I undo the last action (that is drop). The exception is not thrown exactly after the mdlUndo function call, but after my callback ends and the flow goes back to the microstation code.

Jan Šlegr said:

How and when you set undo buffer?

Do you mean mdlUndo_SetActive(true)? If yes, then its before I start even the callback.

Jan Šlegr said:

In what transaction context you are modifying DGN file?

Could you explain this further please?

Lubo B said:

And even with that, after applying my workaround (I mention it in question), the problem disappears.

No, the problem not disappear in my opinion, because problem is (probably) in your code.

Of course, a possibility that something is wrong in Bentley Map itself, but because it seems nobody else has reported such issue (personally, I did not see it at any from my BM users), BM code is fine.

Lubo B said:

I setup a callback to CHANGE_TRACK_FUNC_Changed.

Franky, I have become dissappointed by this discussion and I tend to leave it. This discussion is several days old, it contains several answers and comments already, and for the first time such crucial information is shared? When you are not willing to provide complete detail information and any piece of your code (so it's absolutely not clear what your code does), how can you expect anybody can help you? Sorry, but from my perspective it looks like wasted time.

To use these types of callback is quite sensitive. And to try to change anything requires to know all implications and consequences, because it can easily happen to be intrusive.

Lubo B said:

After declining this operation I undo the last action (that is drop).

Are you sure? Without knowing code, context (data structure) and testing, I can guess only (because unfortunately my knowledge is probably not good enough).

What I would think about: You mentioned you used "DGN only" project, so I expect every element is treated as feature, native or through DFS mechanism. In this context, what is "last action"? From a user perspective, it's "to drop an element", when icon is clicked and confirmed. In terms of visible elements, it's represented by more steps, because new elements are created and the complex element is deleted. Internally, it's even more complicated, because when  the element is feature, XAttributes are attached to it. And because XAttributes are "on element", stored somewhere else in DGN file (I guess it's in dedicated stream, but it's technical detail), Drop tool has to schedule XAttributes removal to not corrupt data integrity. I even think some operations are done in asynchronous way.

I do not know when, in this complex process, your callback is called (when graphical element is changed, after complete operation...?) and what is treated as undo action. To call undo can be both perfectly fine, but also invalidating something, that causes the exception alter.

Lubo B said:

Do you mean mdlUndo_SetActive(true)?

Probably this my question was not important, because when we discuss Drop element tool, this tool is responsible to set how undo buffer is set.

Lubo B said:

Could you explain this further please?

I recommend (because it's mandatory knowledge today) to study Transaction Manager (TxnMonitor class) documenation in MicroStationAPI help.

File changes are processed as transactions, controlled by Transaction Manager, to ensure data is created and modified in a correct way. Plus, it helps to manage Undo steps in users friendly way, because complex operation, internally represented by e.g. tens of even hundreds of operations, is written at once. Also consequent individual operations can be grouped into one transaction group.

In fact, any interaction with DGN file goes through and is processed by Transaction Manager.

Lubo B said:

because it means the user might have dropped some of the elements.

In my opinion it's too late, because the callback is called when element is (I guess) dropped already and the new data is in DgnCache already. So when XFM element is dropped, many operations were finished.

I am not sure what is the best way how to solve such situation. At first, because you are in Bentley Map (which is not MicroStation, but more complex environment), you can check BM SDK documentation whether some from callback provided by BM API does not suits your needs better. Also, I recommend to change the code to use modern Transaction Manager. I think many operations are equal (ending at the same code), but Transaction Manager API always work in the transaction context. A third way can be to block to use Drop element tool before (not after) elements are dropped. It can be achieved by monitoring input queue. Disadvantage is that command ids are not strictly fixed, so they can change in future (but it's not as big issue as it can looks like).

With regards,

  Jan

Jan Šlegr said:

A third way can be to block to use Drop element tool before (not after) elements are dropped. It can be achieved by monitoring input queue. Disadvantage is that command ids are not strictly fixed, so they can change in future (but it's not as big issue as it can looks like).

Do you mean that there is a specific command generated when user tries to drop an element? 

I´ve tried that method using the mdlInput_setMonitorFunction(MONITOR_ALL).

The problem is that I´m able to react only when user starts using Drop element tool (keyin "DROP" is passed to the queue). There is no specific command generated when user confirms selected element and is dropping it.

I can then only listen to mouse click, but it includes all clicks (left button), no matter if there is selected element or not.

Jan Šlegr said:

A third way can be to block to use Drop element tool before (not after) elements are dropped. It can be achieved by monitoring input queue. Disadvantage is that command ids are not strictly fixed, so they can change in future (but it's not as big issue as it can looks like).

Do you mean that there is a specific command generated when user tries to drop an element? 

I´ve tried that method using the mdlInput_setMonitorFunction(MONITOR_ALL).

The problem is that I´m able to react only when user starts using Drop element tool (keyin "DROP" is passed to the queue). There is no specific command generated when user confirms selected element and is dropping it.

I can then only listen to mouse click, but it includes all clicks (left button), no matter if there is selected element or not.