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