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: Trigger on attribute save
Topic Summary: Is this possible?
Created On: 10-Aug-2005 00:56
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.
 10-Aug-2005 00:56
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

I'm building a script to make/update a list of modules (requirements specs and the like) linking into a given module (a system spec)--this list being stored in yet a third module (the config spec). Now, for each object--the name of another module--in the config spec we have an outlink to that module. What I'm trying to do is to have a column where the user can enter a baseline number to 'lock' to, that automatically changes the link to that baseline of the module.

So I'm looking at creating a trigger of some sort. I see two options so far (and this is the first time I've played with triggers): I could do an attribute-level trigger for whenever the "Locked Baseline" attribute is saved, that does the relinking; or, a module-wide trigger for when it's saved.

Would I want a persistent or dynamic trigger for this? I gather a persistent one, but I've just realized while typing this that I understand even less about triggers than I thought. Also, how would it work to do a attribute-based one, where I'm creating the attribute (and the column, and the view) in DXL, the first time the script is run (later runs will update it)?

Can anybody explain triggers a bit more? Or think of a better way to do this?

Thanks in advance,
Chris Jones
Report this to a Moderator Report this to a Moderator
 15-Aug-2005 23:09
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Triggers are not for the feint of heart. They are poorly documents, touchy, and dangerous; all the attributes of a "disaster waiting to happen".

If the trigger can override an action (e.g. prevent the user from typing in an illegal module) then you want a "pre" event trigger; one that sets either "trigPreConPass" or "trigPreConFail". If the trigger isn't going to check then you probably want a "post" trigger (usually). The "attrDef(Trigger)" command will return the AttrDef handle of the attribute being saved for Attr Save triggers. That's pretty handy. Go from there.

The module-close trigger will need to be a "pre", otherwise you won't have access to the module. If the current open module isRead(mod) then it doesn't need to do any linking. This DOES cover the case where the user started in Edit, made some changes, and then used the Edit menu to downgrade to R mode; since the module IS temporarily closed when switching from E or S to R.

Good luck.

- Louie
Report this to a Moderator Report this to a Moderator
 16-Aug-2005 17:20
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

Triggers are fun!

I can certainly see what you're talking about with the danger. But what I'm doing doesn't seem TOO hard. I finally got back to this this morning, and here's what I've come up with in about 45 minutes.

This line gives us our trigger:


Trigger lock_Trig = trigger("lock_trig", module->attribute->"Locked baseline", pre, save, 1, "#include <lockedbltrigtest.dxl>")


And then, in that included file I have a simple test...the baseline checking stuff is pretty straightforward, but for now we can play a little game:


Trigger t = current // gets a handle on the Trigger that is running this code

if (value(t) == "42") { // value that we're attempting to save into the attribute
ack "Congratulations!"
set trigPreConPass
}

else {
ack "Wrong! Guess again!"
set trigPreConFail
}


This essentially makes it impossible to put any value other than 42 into that attribute. I can think of some possibly useful ways to do something like this...or we could randomize the number that we want to save and make a REAL game out of it. But then, now that I think about it, it would be a different random number every time...

Also, since my script will be creating this module, the Trigger is persistent in the module and will never need to be deleted. There's definitely some messes one could get oneself into with creating lots and lots of triggers indiscriminately.

So thanks for the advice, Louie. I'd say that triggers maybe aren't quite as scary as you make them out to be, but that's probably because I haven't used them much .

Chris

Edited: 16-Aug-2005 at 17:59 by Chris Jones
Report this to a Moderator Report this to a Moderator
 16-Aug-2005 18:09
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

Some quick info on Triggers you've already got:


Trigger t = null
Module m = current

for t in m do {
print name t "\n"
print dxl t "\n"
print kind t "\n"
}

//if (!null t) then delete t

There's apparently two triggers declared when you make a persistent one like I have: there's your trigger, and it makes a builtin type as well (the above code gives
B:specific close for lock_trig 36
lock_trig
when I run it). The builtin one gets deleted when you delete the user-defined one too.

Also, the triggered code seems to be attached to the trigger when it's declared: if you change the #include file without remaking the trigger, the old code is still run.

-Chris
Report this to a Moderator Report this to a Moderator
 18-Aug-2005 21:01
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

So I've got my trigger set up as in the previous post, although the code that it runs when it's triggered does some actual work. I was working on something mostly unrelated and started getting message boxes from my triggered code--when it shouldn't have been triggering.

It's set up to run whenever the "Locked baseline" attribute is modified...but I ran a different script that "approves outlinks"---it opens the link module for each link and sets an attribute there. For some reason this is triggering my "locked baseline" code, but it's not even editing the "locked baseline" attribute! I've also done this manually: I go into the link module and edit any ol' attribute for a link, and it sets off the trigger. It's setting the value passed to the trigger as what I try to set the link attribute to, and when it sets trigPreConFail, the (link) attribute isn't saved.

So, basically, my trigger is getting triggered on more attributes than I told it to. Has anyone else run into this?
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 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 1 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.