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: OLE revisions
Topic Summary: different version of an image shows up
Created On: 31-Jul-2007 15:52
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.
 31-Jul-2007 15:52
User is offline View Users Profile Print this message


Brian Rohler

Posts: 26
Joined: 20-Jun-2007

There are a few images in Word documents that when I upload them to DOORS, an older image shows up. I was not the original creator of this document so I can not say how the image was created, but I was wondering if anyone has run into this issue before. Additionally, there is an image that when it is exported from DOORS into a Word document, it looks fine. However, when it is then printed, it is a different image that prints. I think these are probably more Word issues, but I was hoping someone might have some insight.
Report this to a Moderator Report this to a Moderator
 31-Jul-2007 16:22
User is offline View Users Profile Print this message


Peter Albert

Posts: 232
Joined: 30-Dec-2005

I see exactly the same behaviour when a DOORS object contains an embedded Word document as an OLE object, and this Word document contains a Word drawing. When the drawing is updated in the original Word document and copied /pasted into DOORS, the old drawing still shows up. The workaround is as follows: Open the object properties for the object in question. On the "General" tab in the "Object Text" field, double-click the embedded OLE Word file. This should launch a Word instance. Do some modification, e.g. type "space" and undo the action. Save the word file and return to DOORS. This updates the drawing in DOORS, too.

Although this is probably not exactly your problem, it might help to go via the object properties dialog box. When the OLE object is modified directly in the module window, still the old version shows up.

Regards,

Peter
Report this to a Moderator Report this to a Moderator
 1-Aug-2007 20:07
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

Aha!

So we're not the only ones. We see a problem very similar to this with Visio OLEs. Someone updates the drawing in Visio (through double-clicking on it in DOORS), saves it, everything looks fine. But then they export to RTF and print it, and the old version of the drawing is still there. I've had a hard time trying to narrow it down (or reproduce it on a test module). I wondered if it might be only a Visio problem (and have been hesitant to contact Telelogic since we're using mostly Visio 2003, which is unsupported with DOORS)---but now that I hear other people have this problem too.....

Also, I have discovered a few things:

---This is a given when working with documents imported from RTF (and perhaps Word?) that have images in them. The RTF importer puts the RTF string of the picture into object-level attributes, and the exporter grabs it from there. Unfortunately, if you change the picture in DOORS, the exporter never knows since pictures are stored some other way. The same thing happens when you just use Insert | Picture. (Pictures are not supported by the RTF exporter, as it turns out. Telelogic said they will add that to the documentation.)


---As far as OLEs are concerned: In RTF, OLEs are (usually) written with a picture of what's inside, along with the actual data for the application that created it. This is how computers without the original app can display what it looks like, even though you can't edit the object.

What we found here was that computers without Visio would print the correct version of the drawing (inside the exported RTF)---which makes sense, since the "picture" that we see in Word is correct. But computers with Visio end up putting out the old version.


---One thing I just thought of would be to see if we can get the same behavior by using a Visio drawing embedded in Word (or WordPad), since DOORS uses the standard Microsoft OLE controls. I've tried to figure out if this is a DOORS problem, an RTF problem, an OLE problem, or some combination thereof (DOORS' implementation of OLE objects in RTF????). If I get back into troubleshooting this I will try to post any further results here.


Chris

(Edit: Reformatting...)

Edited: 1-Aug-2007 at 20:09 by Chris Jones
Report this to a Moderator Report this to a Moderator
 1-Aug-2007 23:37
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Just in case: when you Paste and OLE into DOORS you can opt to paste the OLE or paste a link. If you paste a link then DOORS is updated when the OLE is updated outside of DOORS, but of course folks who don't have access to that drawing cannot see it. If you paste the OLE iteself then of course it doesn't update when you change the original.

- Louie
Report this to a Moderator Report this to a Moderator
 1-Aug-2007 23:55
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

Right...that's not it though. For us, the problem only shows up when we export a module to RTF and then print it.

I also wanted to mention that we have found a "kind-of" workaround: After exporting to RTF, open it in Word, then right-click on the OLE object and find the "Convert" option. Whatever this does seems to update the object so that it prints out OK. Of course, this doesn't help us in most cases since we have a custom Print script that dumps out to RTF, opens in Word to add headers etc., and prints it, no user intervention.

Chris
Report this to a Moderator Report this to a Moderator
 7-Jan-2008 16:11
User is offline View Users Profile Print this message


Scott Covington

Posts: 17
Joined: 29-Nov-2004

We have seen the same/similar oddities with Visio where the object looks correct in DOORS, but when you export/print, the wrong picture is printed.

We finally did a brute force workaround by simply opening the Visio object doing a copy all, deleting the original OLE and pasting a new OLE.

Not ideal since you need to know which objects need to be fixed and manually fix them, but at least it is a fairly easy fix and it is permanent (until the next time the OLE gets updated).
Report this to a Moderator Report this to a Moderator
 15-Jan-2008 19:21
User is offline View Users Profile Print this message


Roy Bond

Posts: 39
Joined: 25-Mar-2003

We use Excel Tables in place of DOORS Tables, and have seen the same problem when exporting to Word.

Unfortunately, it is difficult to check all tables and diagrams because there are so many, so we run a VB Script after export to avoid 'unknown' errors getting into the delivered documents (see below).

Roy Bond
MTU Aero Engines Munich





Sub Remove_Old_OLE()

'
' Open all OLE Excel OLE Objects to remove History
'

i = 0

For Each OLE_Object In ActiveDocument.InlineShapes

If OLE_Object.Type <> wdInlineShapePicture Then

i = i + 1

End If

Next OLE_Object


Count = 0


Do While Count <= i

Count = Count + 1

Selection.GoTo What:=wdGoToObject, Which:=wdGoToNext, Count:=1, Name:="Excel.Sheet.8"
Selection.Find.ClearFormatting
With Selection.Find
.Text = "^g"
.Replacement.Text = ""
.Forward = True
.Wrap = wdFindContinue
.Format = False
.MatchCase = False
.MatchWholeWord = False
.MatchWildcards = False
.MatchSoundsLike = False
.MatchAllWordForms = False
End With
Selection.Find.Execute
Selection.InlineShapes(1).OLEFormat.DoVerb VerbIndex:=wdOLEVerbPrimary

Loop

End Sub
Report this to a Moderator Report this to a Moderator
 23-Apr-2008 18:01
User is offline View Users Profile Print this message


Matthew Herald

Posts: 14
Joined: 19-Apr-2006

So I'm having a similar problem, but my Visio OLE is not displaying the current version in DOORS. If you double click on it to activate it, then it will show the current version there, but not in the DOORS object.

Is there a way to make DOORS show the current version?

I have tried cut and pasting into DOORS, but it still show the older version. I have also saved a copy of the Visio diagram to my computer and tried cut and pasting that into the object, but even that still shows the older version. Is there anythign I can do?

-------------------------
Matt Herald
Systems Engineering Tools Administrator
ITT Corporation - Communications Systems
Fort Wayne, IN
Report this to a Moderator Report this to a Moderator
 24-Apr-2008 07:51
User is offline View Users Profile Print this message


Peter Albert

Posts: 232
Joined: 30-Dec-2005

My experience with Word was that when the OLE was modified from the Module window, the old version kept showing up. However, if it was modified from the Object Properties dialog box, then the modified version was shown in the Module window. Probably worth giving it a try with Visio, too.

Regards,

Peter
Report this to a Moderator Report this to a Moderator
 24-Apr-2008 16:48
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

Matthew: That's pretty bad. Have you opened a case with Telelogic about it? They'll probably tell you it's a Microsoft problem, but maybe they can suggest a workaround or something.

This seems like a fairly major issue to me. We have this neato-handy functionality that everybody likes to use (because it's convenient), but it's broken. And, it's broken in a subtle, insidious way that makes for errors that are hard to spot (especially because it doesn't always happen). Maybe if enough of us complain to Telelogic they can improve things on their end of the OLE components (if there's anything they CAN do) or at least they can complain to Microsoft. Maybe we can complain to Microsoft too...

Chris
Report this to a Moderator Report this to a Moderator
 24-Apr-2008 17:09
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

I should qualify my previous post with the following we received from Telelogic support on the matter:

This is with reference to the case 7024716-"Visio OLE objects print incorrectly after export"

We have seen this issue before and the issue was identified to be a problem with Microsoft Word and is beyond the control of DOORS.

We have been in touch with Microsoft on this issue; and this can be reproduced without using DOORS.

Microsoft has acknowledged that this is a bug (SRQ070926600710).

If you print the module directly from DOORS, the document prints fine with the Visio diagram as displayed. However, if you export the module to Word and then try to print the document, only then this behavior is seen.

As a workaround you may try one of the below options in MSWord.

- Before printing activate the object by double-clicking on it and then click on the Word document to change the focus to the back, and then print it.
- Right click and convert the object to Excel or Visio Drawing/ Excel spreadsheet (there can be many options here).

The Above options can also be automated using a Macro.


From subsequent emails, the SRQ number given is apparently a case number with Microsoft, not a KB number or similar that you can find on their web site. Like said, maybe enough of us could pressure Telelogic and MS to find a fix to the problems. (Maybe.)

Roy, upon closer inspection I see that your macro is activating each object in the document, which is one of the workarounds suggested. I'm looking into ways to programmatically fix/avoid the issue, and that is one of the methods I was going to try. I might just end up using your code! We have a customized export script anyway, so it won't be too hard to add another step.

Here are my ideas so far:
--Activate all objects, as mentioned
--"Convert" all objects, also as mentioned
...but either of those seem like they would add more time and complexity to the script. I also thought of:
--Only export the picture, not the full OLE object

This would be fine for us in most cases since people usually only want to print or look at the document. If you need to change the OLE after an export, well.....it wouldn't work as well, but you might want to rethink that anyway (unless you re-import, it'll of course stay in the exported doc).

There is a DXL perm "exportPicture()" that may be of use here. Or perhaps I can look at the RTF and take the metafile at the beginning. This MS KB article may be of use, if I can ever get to the site: http://support.microsoft.com/kb/119395.

Apologies for the brain dump, but maybe it can help somebody else too.

Chris

Edited: 24-Apr-2008 at 17:11 by Chris Jones
Report this to a Moderator Report this to a Moderator
 24-Apr-2008 17:33
User is offline View Users Profile Print this message


Paul Tiplady

Posts: 176
Joined: 28-Oct-2003

I already use one of the methods mentioned. I export to RTF, but I only export the picture from an OLE, on the grounds that DOORS is the master and the exported document is simply a snapshot of what's in DOORS.

The code I use to export the picture from the OLE is attached. It's not brilliantly tidy, but it works...

I have another function that sizes the picture to the page too, because sometimes the pictures can be a seriously different size to what the application presents.

It selects the nth (where n= picIndex) picture in the buffer and returns the start and end positions, for subsequent processing.

Paul.

-------------------------


Paul dot Tiplady at TRW dot com
TRW Automotive

Edited: 24-Apr-2008 at 17:38 by Paul Tiplady
Report this to a Moderator Report this to a Moderator
 24-Apr-2008 22:39
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

Aha! That's great, Paul -- almost exactly what I was thinking of, except without me having to write RTF-parsing code .

How do you handle exporting the OLE's picture within other object text? I was thinking of using the output from richTextWithOle(), extracting the picture(s) with your handy function, and then just grabbing the richTextNoOle(). But then I realized that that would leave me with the picture before or after the text, instead of in the middle.

The solution would probably be to get the location of the picture, the location (start and end) of the entire object, and do some splicing somehow. Then I guess I have to write some RTF-parsing code after all. Oh well.

Stay tuned, this is one of my top priorities right now so hopefully I can finish it next time I'm here. Will post my results.

Chris
Report this to a Moderator Report this to a Moderator
 25-Apr-2008 08:07
User is offline View Users Profile Print this message


Peter Albert

Posts: 232
Joined: 30-Dec-2005

As for creating pictures of embedded OLEs at the right position in the rtf string:

You can parse a string created with 'richTextWithOle' using the built-in tools and export pictures of all embedded OLEs using the 'exportPicture' perm. If you loop through the RichTextParagraphs and then through the RichText chunks, all comes in the right order. I am using this in a script which exports modules to HTML, and it works fine. See the attached script snippet for the loops and the picture export.

There is one drawback, however: All png files come with a black border around them. While this is not too much of a problem for large pictures, it does look ugly for e.g. formula objects embedded in the text.

Cheers,

Peter
Report this to a Moderator Report this to a Moderator
 25-Apr-2008 14:04
User is offline View Users Profile Print this message


Paul Tiplady

Posts: 176
Joined: 28-Oct-2003

Peter's basically given you what you need, but just to make sure that particular nail is thoroughly hammered, here is some more of the code that I use for export. This sorts out all the formatting, and allows for captions on the pictures too (that bit is done somewhere else - this code just adds a marker showing where the caption should be).

Paul.

PS The alignment is off because a change of editor has meant tabs were sometimes replaced with 4 spaces and sometimes not. Sorry!

PPS If we could attach files life would be much simpler...

-------------------------


Paul dot Tiplady at TRW dot com
TRW Automotive
Report this to a Moderator Report this to a Moderator
 20-Jun-2008 23:05
User is offline View Users Profile Print this message


Chris Jones

Posts: 177
Joined: 1-Jul-2005

Peter and Paul (and everybody else too):
Thanks for all your help with this! All the code was basically what we needed for that option, and we did finally get it mostly working with our scripts.

But then someone else here found a much simpler way to get the end result that I wanted: Ctrl-Shift-F9 in Word. This will "unlink" the currently selected OLE object (or any form field, since OLEs are apparently stored as "embed" fields) -- resulting in a simple picture of the OLE's last contents. You can also do this on all objects at once (see code attachment for the entire DXLized version):

Document.FormFields.Unlink

All that work and pain, and then we find something like this! Oh well, I guess the best solutions are often the simplest. (I should mention that we are already opening the RTF in Word after export, and monkeying around with it, so this was a very simple addition.)

Thanks again guys!

Chris
Report this to a Moderator Report this to a Moderator
 3-Sep-2008 15:52
User is offline View Users Profile Print this message


Roy Bond

Posts: 39
Joined: 25-Mar-2003

Chris,

Playing with OLE Automation is not one of my stronger points, so could you give me an example of how to get a handle on a Word File I've just exported (through WEXP for example).

If not - how are you calling the DXL.


Roy.
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 0 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 0 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.