![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Trigger issues Topic Summary: Created On: 28-Jan-2009 21:19 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Hi All,
I have a short function to set Object Text to bold and this works fine in the dxl editor. Object o string s s = o."Object Text" o."Object Text" = richText "{\\b "s"}" I want to attach this to a trigger so that if the user modifies the object text it is changed to Bold. Trigger t = trigger("makeBold",attribute ->"Object Text",pre,modify,1,#include <path to my file\makeBold.dxl> ![]() However when I try to run the trigger definition it complains about the dxl in the makeBold.dxl Can anyone shed any light or am I missing the obvious? Thanks Mark ------------------------- mark_williamson@synthesys.co.uk http://www.synthesys.co.uk ---------------------------------------- |
|
![]() |
|
![]() |
|
As written you dxl has an error within it on the first line
|
|
![]() |
|
![]() |
|
Hi Ron,
I missed the " = current" in my paste Object o = current string s s = o."Object Text" o."Object Text" = richText "{\\b "s"}" Can't figure out why it works when executed within the module but the trigger ran from the same module trips over the dxl. Perhaps a fresh pair of eyes tomorrow!! Thanks Mark ------------------------- mark_williamson@synthesys.co.uk http://www.synthesys.co.uk ---------------------------------------- |
|
![]() |
|
![]() |
|
Know that 'pre' triggers run before the event, in this case updating the object text.
I see that you retrieve the raw Text, in which case existing font and paragraph formatting will be lost, and any OLE diagrams will be erased; I hate it when that happens. I think you need a more robust retrieval, but won't get into that now. Didn't try it, but I believe that a 'pre modify' trigger will get the EXISTING value of Object Text and make THAT bold and save it. After the trigger the event occurs, and the object text is updated with its user intended value, erasing the bolding. EDIT: you can verify easily enough by looking at the object history. If you make this a 'post modify' trigger it should work, but you'll get two History entries; one for the user modification and one for the bolding. You could realistically retain the 'Pre Modify' trigger, but in this case get the proposed value, change it to bold, save the attribute, and then stop the event from occuring. May look like this: Trigger trg = current() Object obj = object(trg) // Could perhaps be more reliable than obj = current string ProposedValue = value(trg) obj."Object Text" = richText "{\\b "ProposedValue "}" set(trigPreConFail) // Prevent the event from erasing your bolding. ---- I wonder if changing the Object Text in the trigger will, hey, trigger the trigger... - Louie You have some mechanism for unbolding after review, yes? Edited: 29-Jan-2009 at 03:29 by Louie Landale |
|
![]() |
|
![]() |
|
Hi Louie,
Essentially I want any new objects or any amended objects to be distinguishable by bold object text. The only way I could think of satisfying this was to use a trigger. I believe it should be a 'post' event trigger and have modified accordingly. Is there any specific formatting required within the code dxl when called for a trigger? My snippet of dxl changes the object text to bold when run within the module but when the same code is called from the trigger, there are numerous dxl errors.. Confused Mark ------------------------- mark_williamson@synthesys.co.uk http://www.synthesys.co.uk ---------------------------------------- |
|
![]() |
|
![]() |
|
Hi Mark,
it seems, that the error is not within the trigger code but within the creation of trigger: Trigger t = trigger("makeBold",attribute ->"Object Text",pre,modify,1,"#include <path to my file\makeBold.dxl>"); You've forgotten to quote the trigger code. ![]() BTW: For testing it might be OK to use include statement within trigger, but for using in procuctive database I would highly recomment to NOT use includes within trigger code. When some of the users do not have access to the referenced file, they will get annoying error messages! Greetings from Berlin Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|
![]() |
|
![]() |
|
Hi Reik,
I originally had the code "quoted" but with the quotes in place I get the following errors: -E- DXL: <Line:1> badly formed token ("#include) -E- DXL: <Line:1> incorrect argument for (<_) -E- DXL: <Line:1> syntax error -E- DXL: <Line:1> badly formed token (")) -E- DXL: <Line:1> undeclared variable (C) Regards Mark ------------------------- mark_williamson@synthesys.co.uk http://www.synthesys.co.uk ---------------------------------------- |
|
![]() |
|
![]() |
|
Mark, I think your approach is a little bit like sledge-hammering an egg.
What you are doing will create spurious changes in the object history and possibly lose information as Louie pointed out. The change bars show you if an object has changed, or if you are colour blind like me, put the following in a layout dxl column - job done. ------------------------- Tony Goodman Smart DXL limited www.smartdxl.com Edited: 29-Jan-2009 at 12:50 by Tony Goodman |
|
![]() |
|
![]() |
|
Hi Mark,
independently that Tony's statement is very helpfull. The error message is generated because of the backslash within the include path. --> Trigger t = trigger("makeBold",attribute ->"Object Text",pre,modify,1,"#include <path to my file/makeBold.dxl>"); will work ![]() Greetings Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|
![]() |
|
![]() |
|
Thanks Guys for all the helpful advice.
I seem to be digging an ever deeper hole. Tony's layout DXL idea goes some way towards what I need in that there is a tangible record of changes to the object text, however it needs to be visually obvious to the user that that while selecting requirements for a particular test, which ones have been modified (creation of or amendment of) from the delivered baseline. Additionally I have created a DB which displays the requirement in richText and allows the user to add,navigate, select/deselect requirements for a specific test. Unless the object text formatting is modified in some way it is not readily apparent to the user which ones are user added or modified. I am not aware of any way to display the contents of a layout dxl column within a DBE... Reik, I have switched the "slashes" in the full path to the dxl and the trigger is now working. I can now work on the richTextWithOle issue that Louie alluded to earlier. Best wishes Mark (greyer by the day) ------------------------- mark_williamson@synthesys.co.uk http://www.synthesys.co.uk ---------------------------------------- |
|
![]() |
|
![]() |
|
Resetting indent.
Yes, triggers are not for the feint of heart. Your approach of getting it to work on demand outside a trigger, then make it a trigger is a good one. If you do indeed have a common server file that EVERYONE who uses the database will always see, using an #include in the trigger will work. However, that's unlikely. Its generally better in the set-the-trigger code to read the contents of the trigger-code file and set the trigger to the contents: string TriggerCode = (readFile "c:/MyDoorsStuff/MyTriggerCode/ThisTrigger.dxl") The use TriggerCode when defining the trigger. But before you do that you can use checkFile(TriggerCode) to at least find out of the code has interpretation errors, before attempting to set the code. This lets you house both files on your local computer and basically stop someone else from monkeying with your trigger. Don't forget to code in the ability to delete the trigger, since there's no mechanism in DOORS for doing so. But back to your problem. You could change your trigger to instead set today's date in a new object attribute 'Date Text Changed'. Be sure the test group displays that attribute. If I infer correctly, then you could let your test group erase that attribute once they have taken note of a recent text change and updated their tests accordingly. - Louie |
|
![]() |
|
![]() |
|
Hi Louie,
This DOORS customisation is to be installed on a standalone machine with very limited users so the issue of user visibility does not really apply in this case, although I accept your point for a more widely distributed schema. I have the trigger operating now where the object text is being changed to bold and this ticks the box in all cases except were there are OLE's. As you mentioned before the conversion to rich text wipes out the OLE. In my copy objects function I have used richTextWithOle to assign the object text including any OLE to a string variable before assigning the text to the new requirement (newObject."Object Text" = richText newrqm ). This works well and the OLE is maintained in the new object. I have tried manipulating these expressions to maintain the OLE with rich text to no avail. If its technically not possible I will have to admit defeat and resort to setting a new attribute or using some layout dxl as Tony suggested. Functionally the user created/amended objects are identified for the benefit of the user. The reference module (pre amendment) will only be upissued when the parent standard is amended typically 1 to 2 years. Many thanks for your continued support and advice. Mark ------------------------- mark_williamson@synthesys.co.uk http://www.synthesys.co.uk ---------------------------------------- |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Trigger issues
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.