Control of layer sets in EDA objects

Question

We are using AutoVue in a process to review design library objects, as they are being created. We have a large number (10,000+) of these items to review and would like to make the user experience as simple as possible. One of the more cumbersome pieces of the review process is changing the visibility of layers. All of these objects have a common set of layers (same names and order). We are trying to determine if there is a way to simplify the layer visibility process. Here are a couple of thoughts we have and are looking for suggestions/alternatives.
Option 1
We know that a number of layer sets could be created where each set controls the visibility of a select set of layers. The layers sets could then be stored in a markup file. We know that the markup.map file controls the relationship between the object being viewed and the mark file. We could alter/programmatically update this file to have each of the objects point to the same markup file. This seems to be kind of a kludge and has a number of holes that make it not very desirable.
Option 2
We know that the UI can be altered depending on the user. We are thinking that if we could create menu items or icons that set the visibility for the various views the users need, it would make the process much more elegant and less time consuming. Several questions come to mind in this option. Can the UI be modified to add additional menu selection or icons? Can a menu item or icon be used to set the layer visibility? Can the method by which AutoVue is launched be used to control the ultimate appearance and options available to the user? If we were to pursue this option, is there a recipe already in place that could guide us through the process?
Any and all responses are greatly appreciated.

Answer 1

Hi Charlie,
Thanks for clarifying that each of your EDA files have the same set of layers with the same names in the same order - this is a crucial factor if you want to try to approach this in a programmatic or batch manner.
As we discussed earlier today in a separate thread, Option #1 (creating a single markup file with the saved views and linking that markup to multiple base files) might lead to problems. As you know, when AutoVue is not integrated to a DMS/PLM, the markups are managed on the AutoVue server in the markups.map file... and while that file is ASCII and could be modified (not recommended), remember that the mapping depends on exactly where the base file was opened from and what protocol was used to open that file. As a result, if the same file might be opened in 2 different ways (e.g. one time locally from the user's machine, and one time from a web URL), the markup won't automatically be linked to both. Option #1 might be too unpredictable.
Therefore I'd recommend Option #2. I'll ask the experts to chime in if they disagree, but I think that what you'd like to achieve is possible through the AutoVue API and can be broken down into 3 parts:
1. Writing the core code to enable/disable specific layers
2. Packaging this code as a custom "VueAction" so that it can be called as a custom menu or toolbar item
3. Customizing the GUI to expose this menu or toolbar item
Part 1 (code to enable/disable specific layers) should be relatively easy. The AutoVue API includes a class called "com.cimmetry.core.PAN_LAYER" which represents a layer in a file (including EDA files). With the API you can:
- Get the list of layers from the current file (VueBean.getLayersState)
- Enable/disable the layers as required (PAN_LAYER.setState(PAN_LAYER.STATE_ON) or PAN_LAYER.setState(PAN_LAYER.STATE_OFF))
- Re-apply the updated layer set (VueBean.setLayersState)
Part 2 (building a custom VueAction) is a bit more complex, but is explained quite well in the new API Programmer's Guide (http://download.oracle.com/docs/cd/E22156_02/otn/pdf/E22092_01.pdf) that shipped with AutoVue 20.1.0. I'd recommend to read pages 20-22 and 30-35. You would want to take the code from Part 1 and package it into your custom VueAction's "perform" method.
Part 3 (customizing the GUI) should also be relatively easy, and is discussed on pages 62-68 of the Installation and Configuration Guide (http://download.oracle.com/docs/cd/E22156_02/otn/pdf/E22093_01.pdf).
But rather than just saying "read the docs", we also now provide a pre-written example of a custom VueAction with AutoVue 20.1.0 Client/Server Deployment (I think it's an optional component during install). If you've included it during the install, you'll have the folder \examples\VueActionSample in your server installation. You should be able to use that as a reference for adding your own custom VueAction to the applet.
There's one other part I hadn't included. In our separate thread earlier today, I think you mentioned you wanted to only provide this GUI customization for certain users. If you want to control the GUI based on user/group/role/etc, this is possible but will be up to you to determine the user/group/role/etc and script the JVue applet accordingly (i.e. either dynamically script the applet to set the GUIFILE parameter, or use the JVue.setGUI method).
Hope this helps as a start.
Thanks,
Graham
EDIT: If you prefer to automate the layer config as soon as the file is loaded - rather than have it as a custom menu or toolbar item - you can do that as well and in fact it's much easier. In that case you still go through Part 1 and write the code to set the desired layers, and you implement it as a 2nd applet as described in Oracle KM Note 754612.1 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=754612.1).
Edited by: user638792 on Apr 5, 2011 8:23 PM