![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
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 |
![]() |
![]()
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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? |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Trigger on attribute save
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.