I have a design I am looking to iterate on. I would look to delete some components and add some new ones. How can I configure Altium Designer so that when the new components are annotated they do not acquire a reference designator that formerly belonged to a now-deleted component?
You could copy, paste and quickly annotate new component. You can delete the older one in a second moment.
Related
I am trying to create a Reports diagram with a model document and report specification in Enterprise Architect. The embarrassing part of this is that I've done this before, but can't work out how I did it. And I didn't take notes which I probably should do since this is something like a once every 2 years task for me.
In an older EA project, I have model document w/ custom templates in a reports diagram that will generate a data dictionary. Works great and I want that same thing for an EA project for a different, unrelated project.
But I can seem to figure out the first step, which is that Reports Diagram.
I am using version EA 13.0.1307.
Make sure you have the required MDG technology active.
You need the Core Extentions MDG to be able to create documentation diagrams
Create a Documentation Diagram
When creating a new diagram select Extented from the left pane, and Documentation from the right pane
Now the toolbox should show the elements you need to create your virtual document.
I am trying to take a copy of the XMI files for an Enterprise Architect model and then import them into a new EA project. The "Bulk Import" option doesn't seem to do what is says on the tin.
By figuring out now the package hierarchy is mapped into the EA xml files I could do this by importing the one file at at time starting from the root package, but this is implausibly time-consuming given the number of files involved. I have tried using the "ImportPackageXMI" method on the API to automate the manual approach, but this requires the parent package GUID to be known. For the root package(s) the parent is a "Model", which is created in the new EAP (maybe it has a GUID - but not that I can figure out) and there seems no simple way of recreating the package hierarchy in any case. (I was hoping that if I imported the xmi files - using a specially created root package - then EA would work out the package structure somehow, but this was not the case!)
This seems like it should be a trivial task that should be directly supported from the tool: export model, then import model. Maybe I'm missing something or there is a simple solution for this?
For clarity, I'm using the Desktop Edition (so no scripting available).
My actual goal was to create a copy of project (EAP) that was not associated with any source control settings : my attempts via export/import of the xml it seems was not the best way to achieve this!
A simple way I have found to is to create a new (project) EAP and then open the original EAP in another window (by clicking on the EAP file in Windows explorer). Once this is done the top level packages from a model in the original can simply be copied and then pasted - using the standard shortcuts - into a model in the new EAP, which is not associated with the original source settings. Hence new source control settings can be applied and the model controlled by a new source control technology.
You could simplify this task by using Project/Data Management/Project Transfer. This way a complete copy is done, which also includes the so-called reference data. XMI does only ex-/import elements and connectors (not for example image data, glossary, etc.).
The right way to do that is firstly create a Controlled Model Branch
Then you can Import this Model Branch and it will reconstruct your complete model (branch) from all the xmi files involved.
I am wondering if there are definitions for when to develop different plugins for eclipse. For instance, I am wanting to create something that can either be a wizard in eclipse or a property in eclipse. Both the property and wizard would be associated with a project. Is there a common practice for when to do one over the other? Or is this just by preference?
There are no hard rules for which approach to choose, but here are a few things to consider:
User experience: Think about how the user would want to make the change, what would be easiest/most intuitive for them.
Applying the change: With a wizard you'd be collecting data up front, possibly over multiple pages, and only applying the change on clicking Finish. With properties the changes will generally be to single fields and applied immediately.
Undo: Do you want the change to be undo-able? If so a property sheet may be a better fit. Changes through a wizard could still go on the undo stack, but it would be more unusual.
Complexity: If there are multiple fields to change or the user needs guidance in making the change a wizard might be more appropriate.
When the change is made: If it's data that you want to configure on a new project, but also want to change later, it might be better to include it both in the New Project wizard and a property sheet.
Is there a way to combine multiple packages into one (html) report? I don't want to generate a report from the parent package because it contains a lot of information not related to the desired report. I'm looking for an answer that does not require copy/pasting the separate packages into a new parent package, mainly because that forces me to update the links between the various diagrams and is quite time consuming.
Thanks to #Uffe, there actually is an elegant solution in EA. You can create a documentation diagram and add model document or master document elements to it. To these elements you can then add packages from anywhere in the model, and then publish this combination in any of the supported formats. More details here.
You can't combine the output of several HTML (or document) reports into one. You can do the opposite: you can exclude certain packages from generation.
Simply select each (child) package you wish to exclude, right-click and select Documentation -- Generated Report Options... This allows you to choose whether the package is included in the report. This option is recursive, so the package and all its child packages are excluded.
The other option is to write a script which traverses a package structure and selectively generates documentation for it using the DocumentGenerator class.
You don't want to create a report from the parent package, and you don't want to copy/paste, so try this: create a new package, drag the packages that you wish to report on into the new package, create the report on the new package, drag the packages back where they came from, and delete the new package.
Just stumbled upon this question today:
"Is there a way to know that MPP published to the project server is not created using a template available on the server?"
Basically this comes from the point that how to find out compliance of the project plans to the standard templates.
I am not aware how it can be done?
Actually there is no way to identify by one field that this project was created using that template.
You may assume that by Enterprise Project Type, but again there is a way to change EPT for existing project.
The only way I know is to compare a template and a project by tasks, by structure, etc. it works like finger print recognition: you select several points which the most probably tell that the project was created from the template.
The worst case I can imagine: a user creates a project by a template and after that removes everything from the project. Formally the project was created by the template but in real there is nothing from the template left in the project.