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: Exporting MS Word picture from DOORS to MS Word
Topic Summary:
Created On: 9-Dec-2003 09:08
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.
 9-Dec-2003 09:08
User is offline View Users Profile Print this message


Adam Kulas

Posts: 18
Joined: 29-Oct-2003

Hallo,

I have a Word picture in an object that was exported from DOORS 5 to Word correctly. This picture is no longer exported from DOORS 7. Does anyone of you experienced the same ?
The core of the code that manages the export of the picture is the following :

if (!oleCopy o) {
ack "Error"
return false
}
clear objArgBlock //OleAutoArgs
put(objArgBlock,"Placement",0)
errMess = oleMethod(objRange,"PasteSpecial",objArgBlock)
if (!null errMess) {
logError("Error pasting OLE object", errMess, o)
}

I solved the problem by making jpg format out of the MS Word picture and now it's exported but I would like to know why it worked in DOORS 5 with the MS Word picture and doesn't work in DOORS 7.
Did anything change with Automatation or DXL ?

Thanks,
Adam
Report this to a Moderator Report this to a Moderator
 9-Dec-2003 17:14
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Lets not confuse a "Picture", which is a crude bit-map, with an "OLE Diagram", which is a Microsoft format supported by DOORS.

In DOORS v5 "OLE" diagrams were in the "Object" itself: either the object had an OLE or it did not. The OLE, if any, is displayed in the MAIN column after the Object Text.

In DOORS v6/v7, any Text attribute could have any number of "OLE" diagrams in it, and they would appear in-line.

This means that DXL loses the notion of "the" OLE diagram in the object. Commands like "oleCopy(obj) just don't make sense anymore. Telelogic should have removed these commands (forcing DXL errors) rather than leaving them in but making them impotent. There is a new set of OLE commands in DXL; check chapter "OLE objects". Its confusing, good luck.

I don't know how this applies to Import/Export however; but I suspect you don't need to worry about OLE diagrams anymore: they'll be auto-exported when you export the Text, so long as you use commands like "richTextWithOle(obj, "Object Text") to get the value.

- Louie
Report this to a Moderator Report this to a Moderator
 10-Dec-2003 12:49
User is offline View Users Profile Print this message


Adam Kulas

Posts: 18
Joined: 29-Oct-2003

Maybe I should illustrate the whole problem.
We are exporting the whole requirement specifications to MS Word. So our DXL-script is looking
whether a heading or text or an OLE object is the next to be exported. We also have some OLE objects(bmp or jpg, I don't know which format they were) in several modules. Most of them are static OLE objects (you can't open them for editing) but the one I was talking about opens in MS Word when I click on it. Both kind of OLE objects were exported correctly in DOORS 5 by the script extract above. In DOORS 7 as in v5 they are recognized by the OleIsObject function as OLE objects, but the one that opens in MS Word does not appear in the exported document. There are just some newlines instead. The other OLE objects are still exported.

So OleCopy is still working. It copies the OLE object to the system clipboard from where you can paste it into (e.g) a Word document.
I would like to leave the script as it is because I am able to manipulate the font of the exported text. I don't know what would happen if I try to manipulate the font of "richTextWithOle" and ... I don't want to find out ;-) .

As I wrote, I solved the problem by deleting this OLE object and putting a jpg file on that place.
I'm just wondering why this is working...

- Adam

Edited: 10-Dec-2003 at 12:52 by Adam Kulas
Report this to a Moderator Report this to a Moderator
 10-Dec-2003 20:48
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

The JPG and BMP files are not OLE objects, they are pictures. OLE does not recognize them and that's why nothing happens when you double click on them. The Word exporter seems to export pictures satisfactorily in both v5 and v7.

I looked at the v7 Exporter and it seems to use "richTextWithOLE". If you are using a different exporter than you need to start using that function when exporting the Object Text.

- Louie
Report this to a Moderator Report this to a Moderator
 11-Dec-2003 09:44
User is offline View Users Profile Print this message


Adam Kulas

Posts: 18
Joined: 29-Oct-2003

I think you are right with "richTextWithOle" function. It would be better to use that function and not to differ between text and OLE.
But about the OLE objects I'm not sure. The manual tells you that there are pictures and OLE Objects but OLE objects can also be pictures. It also tells you that pictures are only bmp or wmf files. So it would make sense that my jpg is recognized as OLE by "isOleObject" function, but I'm
wondering why my MS Word picture which is OLE ( see : insert>OLE object) is not exported.

We are not using the standard Telelogic export, the structure of the document is not very setisfing.

I will try "richTextWithOle" when I have some time ...
Thanks for help.

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