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: 7.1 and 8.0 Difference: Object Text Trigger Execution
Topic Summary: Object text triggers in 8.0 execute under different circumstances.
Created On: 4-May-2006 01:59
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.
 4-May-2006 01:59
User is offline View Users Profile Print this message


Kent Power

Posts: 18
Joined: 28-Apr-2005

I've looked in the archives for about the past year and not seen anything about this topic.  Nor have I found any documentation on this in the DXL reference manual (surprise!).  If it has been covered elsewhere, I apologize for replowing old ground.

We maintain a requirements document in DOORS 7.1 in which a number of triggers are set up to execute after attribute modification.  One of the triggers is set for object text modification.  Also, among our DXL tools is one which resolves logical references to figures, tables, and section numbers (analogous to Word cross references).  This tool updates the figure and table numbers in the object text of captions.

We've also been investigating migration to version 8.0.

In DOORS 7.1, if the caption updating tool is run immediately after entering the document's formal module, the caption texts are updated with the same numbers that previously existed (the object text is written to, but with the same string as it had before the tool's execution).  This writing does not cause the trigger script for object text modification to execute, which we know to be true by virtue of inserting a bread crumb in the trigger script.  Nor does manual alteration of the object text  that doesn't result in overall change cause the trigger script to execute.  For example, in object text, one can change "the" to "th" and then back again to "the", and leave the object text without the trigger script running.

In DOORS 8.0, such manual alteration also does not cause the trigger script to execute.  However, executing the caption updating tool does cause the trigger scripts to execute.  This exposed a bug in our trigger scripts (failure to update the current object).

I thought others might want to know about this difference in behavior between the DOORS versions.

Report this to a Moderator Report this to a Moderator
 4-May-2006 22:34
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Your object modification trigger is no doubt a post-attribute-save trigger. Such triggers only fire when an actual change was made to the attribute. Generally the trigger fires under the same conditions that would cause a typiccal attribute's change bar to change from yellow (or green) to red. Its thus no surprise that changing "the" to "th", then back to "the" and THEN clicking out of the object, that no change occured, the bar stayed yellow, and the trigger didn't fire.

Anyway, that's the way it works for non rich text attributes. For rich-text attributes you need to consider that the underlying rich text may change even if the displayed text does not. In v6 I discovered this:
Text1 = richText(obj1.NameTextAttr)
obj1.NameTextAttr = richText(Text1)
Text2 = richText(obj2.NameTextAttr)
if (Text1 != Text2) then I'm a monkey's uncle.

Well, generally I'm a monkeys uncle.

I don't know why v8 would modify the rich text even though there was no actual change to the raw-text; caption references in this case. But no doubt it does. When you open these modules, the bars change to red yes?

Your Caption Updating tool could perhaps detect that there was no change in the underlining raw text (i.e. no actual change to the caption) and then decide to NOT write the changes back out to the text; and thus disallow the modification trigger from even having a chance to fire.

- Louie

If I'm still a monkey's uncle and the caption update trigger does NOT cause the bars to turn Red yet the modification trigger fires, then I'd like the chance to find out where I went wrong ..err.. to debug your triggers.
Report this to a Moderator Report this to a Moderator
 4-May-2006 23:49
User is offline View Users Profile Print this message


Kent Power

Posts: 18
Joined: 28-Apr-2005

Thanks for your response.  A couple of points or clarifications.

"Your object modification trigger is no doubt a post-attribute-save trigger."  Yes.

"Its thus no surprise that changing "the" to "th", then back to "the" and THEN clicking out of the object, that no change occured, the bar stayed yellow, and the trigger didn't fire."  I mentioned that only to note that both 7.1 and 8.0 didn't fire the trigger with manual changes.

"When you open these modules, the bars change to red yes? "  No change bars go red upon opening the module, since no scripts execute upon module open in our environment.  Only when the module is opened, and then a tools pull-down is used to select the tool to display a dereferenced version of an object's object text is the caption number updating routine called.  That routine mimics the type of modification I described in the original note (e.g., "3-4" => "-" => "3-4").  There are no changes in bolding, italics, etc., between the number and the rest of the caption.  When the object text is written back by the routine is when the object text attribute change trigger fires.

I will look at the rich text of a caption object and see if there is some sort of rt tagging going on that I'm not aware of.

" ... I'd like the chance to find out where I went wrong ..err.. to debug your triggers."  Unfortunately, my company considers this type of tool to be proprietary.  However, if I can, I'll put together a sanitized test case that illustrates the problem.

Thanks again for your time.

Kent
Report this to a Moderator Report this to a Moderator
 5-May-2006 12:49
User is offline View Users Profile Print this message


Paul Worrall

Posts: 87
Joined: 30-Sep-2003

We're still stuck in the dark ages of DOORS 5.2, but if I remember correctly the big difference introduced at DOORS 8 was Unicode. Is it possible that your script changes a character to one that looks the same but has a different encoding? I'm guessing that this might be an issue only with characters outside the basic ASCII set. This might be a complete red-herring.
Report this to a Moderator Report this to a Moderator
 5-May-2006 18:32
User is offline View Users Profile Print this message


Kent Power

Posts: 18
Joined: 28-Apr-2005

Thanks for your reply, Paul.  I know what you mean about dark ages re tool versions that you have to use.

The avoidance of Unicode is mostly on the Word side.  I've not played with it much at all, but it looks like we only have a Unicode Arial font in Word that doesn't match our documentation stds.

The DOORS 8.0 support for Unicode seems to be in working with files.  I've tried copying and pasting the Unicode non-breaking hyphen representation (2011, if memory serves me right) from Word into DOORS without success.  It neither displays, nor is exported. I suspect, though I don't know for certain, that rich text utilities don't talk Unicode.

Thanks again.

Kent Power
Report this to a Moderator Report this to a Moderator
 5-May-2006 18:39
User is offline View Users Profile Print this message


Kent Power

Posts: 18
Joined: 28-Apr-2005

Paul:

I just realized I answered your msg as if you were talking about the soft hyphen issue, not the trigger issue.  Let me try again.

The figure/table numbers in question have been previously built by the same tool that is being discussed, and only the Telelogic rich text utilities are used to manipulate the object text.  Though I've not dumped the full rt of these caption objects, I'd be really surprised if this were the case.

Though 8.0 works with Unicode to some degree, I don't think that Unicode is the default representation for text.  My impression is that only in certain circumstances one can use Unicode.

Thanks.

Kent

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.