![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
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 |
![]() |
![]()
|
![]() 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 | |
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
thanks for your help!
thomas
|
|
![]() |
|
![]() |
|
Here is the unsupported command to change views when the module is hidden:
quote: 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 |
|
![]() |
|
![]() |
|
quote: 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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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.
|
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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!! |
|
![]() |
|
![]() |
|
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 |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
prevent opening standard view in batch-mode
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.