Diagrams relocating issue - "Diagram frame(s) are currently being displayed"

[SystemsTinkerer]

Hello EA users,

I have been searching for a good solution online to the problem of moving SysML diagrams. Every time I attempt it, I get the following annoying message:
"Diagram frame(s) are currently being displayed. Please disable them and save the diagram(s) before continuing."

I need to move 100s of diagrams so any help would be appreciated.
I need a solution where I can retain the diagram headers/frames which are required by the SysML language.

Thanks,
Oz

[SystemsTinkerer]

The only solution, which is not the best, I have come across thus far is:

Turn off the frame via diagram context menu then move it and turn the frames back on

[Geert Bellekens]

The question you should be asking is: Why is this a problem for me?

The reason EA is not allowing you to move the diagram, is because the frame is actually a representation of the owner of the diagram.
This owner should be the subject of the diagram.

Now in most cases these diagrams should be owned by an element. The diagram then becomes a description of that element.

If your diagrams are owned by an element, you can freely move the subject element (an with it, it's diagram) where you want without EA complaining about frames.

If your diagrams are not a description of a subject, but merely showing a collection element, then maybe it's not that useful to display the frame anyway.

Geert

[SystemsTinkerer]

Hi Geert,

Thank you for your input! The diagrams are not owned by an element, like being a child diagram of a block or an activity belonging to a usecase. So what is the fix for:

frame is actually a representation of the owner of the diagram. This owner should be the subject of the diagram.

?


Thanks,
Oz

[Geert Bellekens]

Thank you for your input! The diagrams are not owned by an element, like being a child diagram of a block or an activity belonging to a usecase.

Why not? Are you sure you are not missing an element that is kept implicit here?

If not, why do you keep the diagram frame? You might as well remove the diagram frame if it doesn't represent anything.

Geert

[SystemsTinkerer]

Hi Geert,

SysML modelling approach from a purist angle requires headers to be utilised for each diagram, providing info such as diagram kind,  name, and package name, so I am trying to stick to convention.

Is there a way to disable the diagram frame for multiple diagrams in one swoop of one has to laboriously go into each diagram & do it?

Thanks,

[Geert Bellekens]

Is there a way to disable the diagram frame for multiple diagrams in one swoop of one has to laboriously go into each diagram & do it?

Probably not from the GUI, but everything is stored in the database, so a little script that modifies the database should work.
It's simply a matter of finding out where exactly EA stores that info.

It's probably in one of the fields in t_diagram. I would guess either PDATA or StyleEx

Geert

[SystemsTinkerer]

Thanks for the tip Geert! The scripting route is via add-ins, right? You have a tutorial on your site to get started. If there are any other good references, let me know!

Cheers!

[Eve]

The diagrams are not owned by an element, like being a child diagram of a block or an activity belonging to a usecase. So what is the fix for:

frame is actually a representation of the owner of the diagram. This owner should be the subject of the diagram.

?

Then they are owned by the package, and are a representation of that element.

[Geert Bellekens]

Thanks for the tip Geert! The scripting route is via add-ins, right? You have a tutorial on your site to get started. If there are any other good references, let me know!

Cheers!

No, I wouldn't write an add-in for that. There is a built-in scripting module you can use.

Geert

[SystemsTinkerer]

Cheers Geert! I will look into this module & get started. I have heard that using it for search or DB interactions is slower than the SQL directly via ctrl-F but huge gains are to be made from it. The SQL route is only for querying whereas the scripting one would allow me to even make changes to the DB tables & automate model creation...etc

BR,
Oz

[SystemsTinkerer]

The diagrams are not owned by an element, like being a child diagram of a block or an activity belonging to a usecase. So what is the fix for:

frame is actually a representation of the owner of the diagram. This owner should be the subject of the diagram.

?

Then they are owned by the package, and are a representation of that element.

Hi Eve,

Could you please elaborate on this and are there other routes to being able to move frame-based diagrams more easily? Is there a Global disable, then can be turned on once I have moved everything I need to?

Thanks!

[Eve]

Could you please elaborate on this and are there other routes to being able to move frame-based diagrams more easily? Is there a Global disable, then can be turned on once I have moved everything I need to?

The reason EA is not allowing you to move the diagram, is because the frame is actually a representation of the owner of the diagram.
This owner should be the subject of the diagram.

Now in most cases these diagrams should be owned by an element. The diagram then becomes a description of that element.

The owner being a package doesn't change this point. The diagram is describing the package. That's why there's the restriction. If you move it, you're now describing something else.

[KP]

Could you please elaborate on this and are there other routes to being able to move frame-based diagrams more easily? Is there a Global disable, then can be turned on once I have moved everything I need to?

Thanks!

It seems to me that what you are trying to do could be achieved simply by Select All (Ctrl+A), Copy (Ctrl+C), Paste (Ctrl+V). This won't select and copy the diagram frames.

[SystemsTinkerer]

Hi KP,

This would be a long-winded route! I will need to open make another diagram to paste all the contents to and then delete the previous diagram I have moved the contents from....

Thanks for trying to help but it's not what I need.

Cheers!