Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: prevent opening standard view in batch-mode
Topic Summary:
Created On: 24-Aug-2007 13:37
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
Answer This question was answered by Reik Schroeder, on Monday, August 27, 2007 11:01 AM

Answer:
Hi Thomas,

you could override the read function to set standard view you want to have.
This override could be done in batchStartup.dxl in /lib/dxl folder so it would only be available in batch mode.

Hope that solves your problem

BTW: would suggest to use always this loop:
Object o;
for o in entire Module do {
if (!isDeleted o) {
....
}
}

Then you will be independent from views?!

Greetings
Reik
 24-Aug-2007 13:37
User is offline View Users Profile Print this message


Thomas Langholz

Posts: 40
Joined: 20-Oct-2005

hi all, we have several dxl-tools running in batch-mode. These days i had a problem that some mods were not proceeded well so that some objects were missing in the generated report. the problem was the default view. somebody saved his custom view as default for the module, so that the configured filter left some objects. However, the view-objects are not accessible in batch-mode. So i did not care about it. My workaround was to make sure that every mod has the standard-view as default. does anybody has an idea to prevent loading the default-view by using the command Module m = read("fullName", false) in batch-mode? regards thomas

Edited: 24-Aug-2007 at 13:42 by Thomas Langholz
Report this to a Moderator Report this to a Moderator
 24-Aug-2007 14:41
User is offline View Users Profile Print this message


Reik Schroeder

Posts: 361
Joined: 28-Jul-2003

Answer Answer
Hi Thomas,

you could override the read function to set standard view you want to have.
This override could be done in batchStartup.dxl in /lib/dxl folder so it would only be available in batch mode.

Hope that solves your problem

BTW: would suggest to use always this loop:
Object o;
for o in entire Module do {
if (!isDeleted o) {
....
}
}

Then you will be independent from views?!

Greetings
Reik

-------------------------
Evosoft GmbH
for Siemens Industry Sector


Berlin, Germany
Report this to a Moderator Report this to a Moderator
 24-Aug-2007 14:45
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

Our workaround is that for batch scripts we have a separate user account with the proper views set for the scripts.

There is an undocumented way to load views when the module is not visible, as in batch mode, but I lost the email that contained it. I emailed the guy who sent it to me to find out what it was again. But as it is undocumented, I wouldn't really rely on it for a while. Your better bet is to just make a separate user with the desired views set as the default view for that user.

-------------------------
David Pechacek
AAI Services Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
Report this to a Moderator Report this to a Moderator
 24-Aug-2007 16:07
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

And yet again, we have a reason why Views in DOORS need to be overhauled tremendously. Why on earth should a user with modify access get to change the default view for the entire module? Yes, it is a training issue, but the software could easily enforce things so that only users with an A privilege to a module can set default views.

Another thing you can do is "police" the database with a batch script that goes through every module and sets the default view to what your project has defined it to be.

I will be sharing a script with everyone very shortly---if you point your users to this script instead of the built-in DOORS one, view management becomes very, very easy.

As an aside--the same goes for baselining...why on earth can any user with M access baseline a module? There is no way to lock down access for baselining so it's admins/database managers are the only ones who can baseline. It's maddening, and trivial to implement, IMO.

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts
Report this to a Moderator Report this to a Moderator
 27-Aug-2007 11:02
User is offline View Users Profile Print this message


Thomas Langholz

Posts: 40
Joined: 20-Oct-2005

thanks for your help! thomas
Report this to a Moderator Report this to a Moderator
 27-Aug-2007 17:46
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

Here is the unsupported command to change views when the module is hidden:

quote:

"Added a new variant of the view load perm:

"bool load(Module, View, bool, bool)", where the added 4th parameter specifies whether to check that the module is displayed (as other variants always do), and to return false if the module is not displayed and the client is not running in batch mode. If the 4th parameter is set to true, then the behaviour is as for existing variants: the perm does not load the view, and it returns false. If the parameter is set to false, then this check is bypassed, so that a view can be loaded without the module being displayed, even when not running in batch mode.

So use the form "load(Module, View, checkSave, false)" to load a view when the module isn't displayed.

The checkSave parameter tells whether the code should prompt the user to save any unsaved changes to the current view first (if there are any). This parameter is already available, but it doesn't seem to be covered in the DXL manual..."


So load(Module m, View v, false, false) will do it. But remember its unsupported and can change.

-------------------------
David Pechacek
AAI Services Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
Report this to a Moderator Report this to a Moderator
 27-Aug-2007 17:51
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

quote:

Originally posted by: Kevin Murphy
And yet again, we have a reason why Views in DOORS need to be overhauled tremendously.


Many things need to be overhauled. Getting them to do it is another thing altogether.

- Cannot set an object to be shared (specific(o)) in DXL without Admin privileges.
- Anyone who can delete can purge (should be tied to admin access)

-------------------------
David Pechacek
AAI Services Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
Report this to a Moderator Report this to a Moderator
 27-Aug-2007 23:32
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

I've got some 200 scripts ..err.. currently active scripts and I have yet to have one that depends on a particular view to work, even though sever respect the current display set. I'm having a hard time imagining a situation where the script would need to depend on a particular view, but could not hard-code that depency in the script.

Thus your answer seems obviously true to me: Users should routinely use the 'for obj in entire mod' loop followed by object exclude statements, such as 'if (isDeleted(obj)) continue' or perhaps 'if (!Required(obj)) continue'. This makes the script happily independant of whatever filtering-leveling-sorting etc in whatever view gets that gets loaded.

- Louie
Report this to a Moderator Report this to a Moderator
 28-Aug-2007 13:36
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

Louie,

I hear where you are coming from and you have a great point...

But you know there is a "but" coming...

People set up views so things don't have to be coded. I could have a very complex filter. It is easier to change the filter tied to a view than it is to go into code every time there is a change. This keeps the DXL from changing, but the view can change whenever the project decides there is a need for the change.

Since views are a big part of DOORS and tied directly into the GUI, it certainly isn't unreasonable for every DOORS user to expect that when they write some code, they can tie it directly to a view and it will work whether the module is visible or not.

DOORS is marketed as a "database" after all. And while it may technically be one, because of limitations like this, I see it as more of a proprietary file system and not a database. It's really no more of a database than FAT32 is.

Kev

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts
Report this to a Moderator Report this to a Moderator
 17-Apr-2008 19:42
User is offline View Users Profile Print this message


Rand Methfessel

Posts: 11
Joined: 12-Jan-2006

In my application, I need to export several different views of the same module, and would like to do this in batch mode. I tried using the unsupported "load(Module, View, checkSave, false)", but DXL complains about incorrect arguments. Is this perm available in DOORS 8.0? If not, is there another workaround? The "o in entire" and setting the default view will not work in my situation.
Report this to a Moderator Report this to a Moderator
 21-Apr-2008 13:12
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

Rand,

I was given that perm for DOORS 8.1. It's possible its not supported in 8.0.

-------------------------
David Pechacek
AAI Services Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com

Edited: 21-Apr-2008 at 13:13 by David Pechacek
Report this to a Moderator Report this to a Moderator
 8-May-2008 20:22
User is offline View Users Profile Print this message


Chris Annal

Posts: 36
Joined: 14-Dec-2005

I have DOORS 8.3 and I'm having no luck using this perm, either. At the risk of appearing DXL challenged, here is the exact line I'm using:
load("/MyProjectName/MyProjectFolder/VRTM", "Export_To_HTML", false, false)

I have tried also load(Module "/MyProjectName/MyProjectFolder/VRTM", View "Export_To_HTML", false, false)

and lastly,
load((Module ("/MyProjectName/MyProjectFolder/VRTM"), View ("Export_To_HTML"), false, false))

None of the above flavors seem to work. I get the message "incorrect arguments for function (load)".

Am I interpreting load(Module m, View v, false, false) incorrectly? Do we explicitly call out "Module" and "View" as part of the argument? The DXL Help files are sparse for the "load" function.

Thanks!!
Report this to a Moderator Report this to a Moderator
 8-May-2008 22:45
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

When you see this in the DXL manual: load(Module m, View v, false, false), it means the 1st parameter must be of type 'Module' and the 2nd parameter must be of type 'View', and the last two boolean paramaters have value 'false'.

You can get a 'Module' handle these ways:
Module m = read("/MyProject/MyFolder/MyModule") // Open the specific module
Module m = current() // use the current module

You can get a 'View' handle this way:
current = m
View v = view("Export_To_HTML")

So perhaps your code would look like attached.

- Louie
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 2 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 2 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.