[Solved] [Writer] Picto img not displayed at runtime

[BenDev]

Hi!

I'm A bit confused about certain things in LibreOffice that seem to be simple and finally throw me into an issue, while others more complex things (like coding macros functions) can be done without not much issues...

The issue I'm facing is about the diplay of a picto control on a dialogbox at runtime.
When I load the image (wheter it's in .png, .jpg or .bmp format, etc...) into the picto control, on the moment, the image is displayed. It's also displayed on the preview of the dialog.
But When I execute the DialogBox, at runtime, the image is not displayed (see the attached picture).

A few searchs pointed out what could be a sort of "bug" perhaps ?
In the files structure of the .odt file, in the .xml file of the dialog box, I can see :

Code: Select all

<dlg:bulletinboard>
  <dlg:img dlg:style-id="0" dlg:id="PictoControl_Test" dlg:tab-index="0" dlg:left="84" dlg:top="40" dlg:width="32" dlg:height="32" dlg:src="Pictures/100002010000004000000040E6C80BB6A446520C.png"/>
 </dlg:bulletinboard>

So in the xml structure, the image seems to be embedded (and not linked to the original file which is great thing in my case).
But when I check the "Pictures" folder, then I can see that the file doesn't not exists...
I don't know if this is a problem already known (as I haven't found much on this specific case on few forums...)

By the way, if I add manually the file with the expected name "100002010000004000000040E6C80BB6A446520C.png" in the Pictures folder, and then rebuild the .odt file, LibreOffice considers the file as "corrupted" when opening it...

Thanks in advance for any help or advice here!

[RoryOF]

This may or may not offer a cure:
in /Tools /Options /OpenOffice Writer : View "Graphics and objects" should be checked in the Display section. The location may be slightly different in LibreOffice.

[BenDev]

Sorry, I forgot to mention that I had already checked this point, and the option is already Active...
it's the same location and name in LibreOffice (see attached image).

[UnklDonald418]

When an image is embedded in a document, the URL link to an external image file is changed to an internal link, something like vnd.sun.star.GraphicObject:10000201000002BC00000161C31FB983.
The reason for embedding an image is to allow the document to be used on a different machine without having to also bring along all the image file(s) and their location(s). On a different machine the URL link to an image file would probably not be valid, so there is no point in saving it.

There is a discussion of embedding images in section 5.9 of the document "Useful Macro Information For OpenOffice.org" by Andrew Pitonyak
http://www.pitonyak.org/oo.php
On the web page it is referred to as "English Macro Document" and is available as an .odt file or a .pdf file.
There is another discussion of the topic in section 14.3 of "OpenOffice.org Macros Explained" also available on the same web page.

[BenDev]

@UnklDonald418 : thanks for your answer.

But all the sections you mentionned are talking about the insertion and management of images in the document.
I'm already managing images into the document by code for the purpose of the macro I'm developping without any problem.

By the way, it's strange because I found no reference to the picto control in the document you mentionned...is this control a recent control in the OpenOffice Library?

My question here is about the Picto Control added on a dialog box.
I mean that the primary functionnality available with the user interface just doesn't work in my case...

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

So, I tried to do the same on OpenOffice, and I've created a simply DialogBox with only a picto control.
If I load the image, it's forced to a linked URL (not an embedded file like LibreOffice does).
In this case, when I execute the Dialogbox in runtime, on OpenOffice, the image is well displayed.
If I open the same .odt with LibreOffice, and check the Dialogbox, the url path is still there in the xml file, but it's not displayed on the user interface (see the attached image).
And then, if I execute the DialogBox from LibreOffice, at runtime, the image is still not displayed...

[JeJe]

I have no idea about this Picto control or how you have that in LibreOffice... there should be an Image Control which is used to display pictures.

[UnklDonald418]

I got similar results, so it appears there is a bug in the LO dialog design screen.
The only way I could display an image on a dialog using LO was to insert the image during dialog setup in the macro.

Code: Select all

oImgCont = oDialog.Model.getByName("ImageControl1")
oImgCont.ImageURL = ConvertToURL("D:\Img\Img_Test.png")
oImgCont.ScaleImage = TRUE

[BenDev]

@UnklDonald418 :
Thanks for having checked out and confirmed that the issue can occur on LibreOffice.

Well, inserting the image at runtime during initialization effectively works...
But the image URL here needs to be based on a path out of the .odt file structure...
In my case, I need the elements to be completly embedded...

I don't know if there is a workaround to insert an image file into the structure without getting the odt file "corrupted" at its opening.
Because if I insert it in the storing folder "Pictures" and updating the xml manifest file too, I still get the file corrupted...

If I was able to do it, then I could set the ImageURL to an embedded path like: "Pictures/MyCustomPicture.png"

[JeJe]

You could create a hidden and protected section at the start of your document to keep the picture. Then set the image control to it

dlg.getcontrol("ImageControl1").model.imageurl = thiscomponent.drawpage.getbyname(whatever).graphicURL

EDIT:
oops only supports getbyindex
dlg.getcontrol("ImageControl1").model.imageurl = thiscomponent.drawpage.getbyindex(0).graphicURL

[BenDev]

@JeJe:

Thanks, it's a solution I planned to check, even if I wish I could do it with a way that would not impact the content part of the document...
Because this content will be already a lot restricted and really sensible so I wish not to take to much risk with the content integrity.

[BenDev]

@JeJe:

So I've tried the trick with the image put in a hidden section (tried in a not hidden section too in case).
The problem here is that the GraphicURL property appeared to be empty...(see the attached Image to see it on the spy console of the Basic debugger).
and then the code

Code: Select all

oGraph = thiscomponent.GraphicObjects.getByName("Img_Custom")
Ctl_Picto_Image.ImageURL = oGraph.graphicURL

leads to an error.

In the .odt decompressed files structure, I can see that the image exists, and is well referenced in the manifest.xml file :

Code: Select all

<manifest:file-entry manifest:full-path="Pictures/100002010000004000000040E6C80BB6A446520C.png" manifest:media-type="image/png"/>

So I've tried to directly set the ImageURL of the Picto control with many syntaxes as I don't really know the good one to refere to an embedded file :

Code: Select all

Ctl_Picto_Image.ImageURL = ConvertToURL("Pictures/100002010000004000000040E6C80BB6A446520C.png")
Ctl_Picto_Image.ImageURL = "Pictures/100002010000004000000040E6C80BB6A446520C.png"

But none lead to the image to be loaded in the picto control...

[BenDev]

Pushing further, I've tried to go with a higher commun parent element, and then this worked:

Code: Select all

oGraph = thiscomponent.GraphicObjects.getByName("Img_Custom")
Ctl_Picto_Image.Graphic = oGraph.Graphic

I've not figured out if the path to the embedded image was stored in any property, as it would I've been logical to me that the right way would have been this one:

Code: Select all

oGraph = thiscomponent.GraphicObjects.getByName("Img_Custom")
Ctl_Picto_Image.ImageURL = oGraph.graphicURL

So if someone has a clue of what's behind this behaviour of the LibreOffice Basic engine here, I will be greatfull to learn more about this...

[JeJe]

Oops, sorry... yeah I got that line from testing in OO which is the one I use.

Code: Select all

thiscomponent.drawpage.getbyindex(0).graphicURL

is fine in OO but generates an error in LibreOffice. Your solution is fine in both though. Clearly there's quite a lot of divergence between the two programs now. I don't worry about the underlying reasons for that - finding something that works is enough...

Code: Select all

 dlg.getcontrol("ImageControl1").model.Graphic = thiscomponent.drawpage.getbyindex(0).graphic

edit:

I was doubly wrong as thiscomponent.drawpage only supports getbyindex not getbyname

[BenDev]

@JeJe:

I was doubly wrong as thiscomponent.drawpage only supports getbyindex not getbyname

Yeah, that's why I changed to

Code: Select all

thiscomponent.GraphicObjects.getByName("Img_Custom")

It's clear now that there are a lot of background differences between LO and AOo (and in a way that's a shame when you have to create macro for both compatibility ).

I don't worry about the underlying reasons for that - finding something that works is enough...

I understand this point of view, but I also know that when you are developping, you often get benefits by understanding the language syntax an logic, and the framework structure and classes...
So as often as possible, I try to get a real understanding of what's behind the resolution of an issue

[UnklDonald418]

when you are developping, you often get benefits by understanding the language syntax an logic, and the framework structure and classes...

To help with that you should install the MRI object inspection tool. It is an extension that is far more powerful than the watch pane on the IDE.
http://extensions.services.openoffice.o ... ction-tool
There documentation at
MRI documentation

Once installed it can be accessed from Tools>Add-Ons>MRI (or MRI selection).
The MRI dialog has 4 tabs, but the ones of most interest will be Properties and Methods.
The tool allows you to display property values, drill down to other objects and execute methods, and in some cases you can change properties.
It can be used to help generate macro code, and display SDK documentation pages.

If you include this code near the beginning of a macro

Code: Select all

If Not Globalscope.BasicLibraries.isLibraryLoaded("MRILib") Then
      Globalscope.BasicLibraries.LoadLibrary( "MRILib" )
End If
oMRI = CreateUnoService( "mytools.Mri" ) 

then you can use the tool to inspect objects at run time by inserting something like this in the macro code.

Code: Select all

MRI.inspect oGraph

or

Code: Select all

oMRI.inspect oDialog

would allow you to inspect the dialog object once it has been defined, but before it is executed.

[BenDev]

@UnklDonald418:

Thanks for this information.
I've heard about this, but I haven't taken the time yet to check this out.

Sure I will have a look, as I know I'm gonna face onathers new issues, as I've just seen that there is also a problem with the UnoControlButton BackgroundColor property, as it's stands well as a background color in the preview of the DialogBox but the color is only applied on the border of the button when the dialog is executed at runtime...

So strange that basic functionnalities like those seem to have malfunction in LibreOffice...

[JeJe]

You need to switch off the NativeWidgetLook to set the button background. See this thread:

viewtopic.php?f=6&t=6133

[BenDev]

@Jeje:

Thanks for your reactivity, I certainly would have found it by myself in the forum, but you were faster
Effectively, this code line solves the issue:

Code: Select all

DialogBoxObject.getPeer().setProperty( "NativeWidgetLook", False )

Once again, so confusing that the default parameters set by the default installer of the application leads to such basic dysfunctions...

[JeJe]

The native look of buttons on Windows is prettier. They have to do one or the other as default... if you've used VB6 then its the other way round and you have to do something to get the prettier native buttons. OO isn't as polished as it might be - you sometimes have to do more work than you'd expect - but usually someone's had the same problem and there's a thread already.

(PS: MRI seconded as a must.)

[BenDev]

So much thanks to all of you for those exchanges, solutions and informations

I put this trhead as closed as the main issue of the subject has been solved to my point of vue.