Hi Noel,
> appeared on my radar again ;-), so I decided to try and fix it myself.
great, I'm looking forward to have this feature.
> I do have some
> questions/queries etc. when looking at the patch you will see my silly
> comments about those
The only question I found is the patch is the one about the SfxMedium ...
actually, I think the usage of SfxMedium there is historically only,
dating back to times when images where loaded asynchronously. Not sure
if this is still the case today, but given that in a lot of cases, the
"real" loading happens internally beforehand, then the bits are copied
to a memory stream, and then the SfxMedium loads from the memory stream,
this probably is completely obsolete.
> any I hope you aren't too unhappy with my approach and hopefully I can
> fix up anything you aren't happy about, look forward to hearing some
> comments
the approach looks great - re-using the graphic cache's IDs as URL is a
brilliant idea :)
(though /me wonders whether this will stop working as soon as the
GraphicsCache can be globally disabled)
detailed comments:
- setting a non-linked URL at multiple controls at once doesn't work.
This is why the PropertyHandler API distinguishes between
ObtainedValue and Success in the onInteractivePropertySelection
method. The former is used to just return the value, which is then
forwarded to all components which are being inspected.
You should simply spare setting the ImageURL in
impl_browseForImage_nothrow, and instead put the ObjectID into
_out_rNewValue.
+ the documentation of css.graphic.GraphicObjectAccess/XGraphicObject is
*very* sparse
- GraphicObjectAccess sounds like it should be a GraphicsCache(Access)
- if I see this right, then its sole purpose is to convert between an
XGraphic and the ID this graphic has in the cache - right?
- the support of the vnd.sun.star.GraphicObject URL should be documented
in MediaProperties service, for the URL property (which also documents
(some of) the other supported URL schemes)
+ GObjectAccessImpl is not thread-safe at all, it should have an own
mutex
+ GObjectAccessImpl ctor should also check for sId being empty
- /me thinks the form component handler should perhaps just use
m_eComponentClass, instead of the SupportNonLinkedImage setting in the
component context
- using ::svt::ImageResourceAccess::getImageXStream for a graphics URL
sounds a little bit ... weird. At least it makes (should make) the
casual code reader wonder if there's something wrong.
+ in toolkit: the handling of a Graphic-URL would belong into
lcl_getGraphicFromURL_nothrow
+ in goodies: IMO, the handling of the Graphic-URL would belong into a
dedicated method. Reasoning: a) "implLoadMemory" suggests the method
handles memory URLs, and b) all other URL schemes have dedicated
methods, too (implLoadResource, implLoadRepositoryImage,
implLoadStandardImage), so this really should also hold for some
implLoadGraphics
+ goodies/source/unographic/graphicunoaccess.cxx does not compile with
warnings=errors. Ts.
+ when an "embedded" graphics is used, then the respective item in the
property browser shows the vnd.sun.sttar.GraphicObject URL - which is
of no use at all (and confusing) to the user. In such a case, leaving
the property display empty, or showing something like "<embedded
graphics>" might be better
+ bug:
- open a new text document
- insert an image control
- in the property browser, add an image to the control, not linked
=> the image is displayed in the control
- in the property browser, focus and control other than the "Graphics"
control
- put the focus back to the "Graphics" control
- put the focus to some other control, again
=> the image vanishes from the control, though the vnd.sun.*-URL is
still displayed as current "Graphics" URL
- close the document, discarding any changes
=> crash
+ bug:
- open a new text document
- insert an image control
- do not assign any graphics to the image control
- save the document
=> assertion saying something about forbidden acccess to an empty
bitmap
(non-product builds only)
- close the document
- open the document, again
=> three assertions about problems with the graphics
(non-product builds only)
Thanks & Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
