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 issues
Topic Summary:
Created On: 28-Jan-2009 21:19
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.
 28-Jan-2009 21:19
User is offline View Users Profile Print this message


Mark Williamson

Posts: 79
Joined: 12-Sep-2005

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
----------------------------------------
Report this to a Moderator Report this to a Moderator
 28-Jan-2009 23:56
User is offline View Users Profile Print this message


ron lewis

Posts: 650
Joined: 20-Sep-2004

As written you dxl has an error within it on the first line
Report this to a Moderator Report this to a Moderator
 29-Jan-2009 00:42
User is offline View Users Profile Print this message


Mark Williamson

Posts: 79
Joined: 12-Sep-2005

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
----------------------------------------
Report this to a Moderator Report this to a Moderator
 29-Jan-2009 03:28
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 29-Jan-2009 10:32
User is offline View Users Profile Print this message


Mark Williamson

Posts: 79
Joined: 12-Sep-2005

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
----------------------------------------
Report this to a Moderator Report this to a Moderator
 29-Jan-2009 12:07
User is offline View Users Profile Print this message


Reik Schroeder

Posts: 361
Joined: 28-Jul-2003

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
Report this to a Moderator Report this to a Moderator
 29-Jan-2009 12:33
User is offline View Users Profile Print this message


Mark Williamson

Posts: 79
Joined: 12-Sep-2005

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
----------------------------------------
Report this to a Moderator Report this to a Moderator
 29-Jan-2009 12:48
User is offline View Users Profile Print this message


Tony Goodman

Posts: 97
Joined: 6-May-2008

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
Report this to a Moderator Report this to a Moderator
 29-Jan-2009 13:09
User is offline View Users Profile Print this message


Reik Schroeder

Posts: 361
Joined: 28-Jul-2003

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
Report this to a Moderator Report this to a Moderator
 29-Jan-2009 13:55
User is offline View Users Profile Print this message


Mark Williamson

Posts: 79
Joined: 12-Sep-2005

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
----------------------------------------
Report this to a Moderator Report this to a Moderator
 29-Jan-2009 17:30
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 29-Jan-2009 19:08
User is offline View Users Profile Print this message


Mark Williamson

Posts: 79
Joined: 12-Sep-2005

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
----------------------------------------
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.