![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
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 |
![]() |
![]()
|
![]() |
|
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.
|
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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). |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
I should qualify my previous post with the following we received from Telelogic support on the matter:
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
Telelogic DOORS
» General Discussion
»
OLE revisions
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.