Issue 59082 - autoshapes with macros not imported into sc
Summary: autoshapes with macros not imported into sc
Alias: None
Product: Calc
Classification: Application
Component: open-import (show other issues)
Version: OOO 2.0 Beta2
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: oc
QA Contact: issues@sc
Depends on:
Reported: 2005-12-08 11:56 UTC by noel.power
Modified: 2013-08-07 15:14 UTC (History)
4 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

patch (18.08 KB, patch)
2005-12-08 11:57 UTC, noel.power
no flags Details | Diff
xl doc with autoshapes with macros (22.00 KB, application/
2005-12-08 11:58 UTC, noel.power
no flags Details
moved maMacroName to be private & added GetMacroName accessor (19.07 KB, patch)
2005-12-14 11:49 UTC, noel.power
no flags Details | Diff
new patch version (22.32 KB, patch)
2006-02-28 12:50 UTC, noel.power
no flags Details | Diff
patches with comments folded in (22.24 KB, patch)
2006-06-19 14:46 UTC, noel.power
no flags Details | Diff
latest version of patch ( with ctx menu for assign/remove macro ) (31.70 KB, patch)
2006-06-27 08:37 UTC, noel.power
no flags Details | Diff
screenshot showing new macro assign context menu (243.85 KB, image/png)
2006-06-27 08:39 UTC, noel.power
no flags Details
screenshot showing new macro assign dialog (248.07 KB, image/png)
2006-06-27 08:41 UTC, noel.power
no flags Details
test document ( used for the screenshots ) (32.44 KB, application/vnd.oasis.opendocument.spreadsheet)
2006-06-27 08:43 UTC, noel.power
no flags Details
the xls version of document (41.50 KB, application/
2006-06-27 08:48 UTC, noel.power
no flags Details
TestCaseSpecification (8.09 KB, text/html)
2007-07-04 13:39 UTC, oc
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description noel.power 2005-12-08 11:56:21 UTC
Hi Daniel,

Seems that in excel autoshapes can have macro's associated with them. Currently
OOo doesn't import that for excel ( and the other apps I guess ). So here's a
little patch I put together to rectify that. You might pass your beady eye over
it. I'd like to get this upstream, any help you could give with that would be

So the patch, its pretty simple, 
a) modifies ScDrawObjData to store the macro ( sc/sc/inc/userdat.hxx )
b) adds an eventsupplier interface to ScShapeObj, the format of the properties
returned from the supplier match those used in presentation for "interaction
events", thus xmloff handles things properly on import/export so the bindings
are persisted correctly.  (sc/source/ui/unoobj/shapeuno.cxx sc/inc/shapeuno.hxx)
c) moved maMacroName & ReadMacro from XclImpTbxControlObj to XclImpDrawObjBase
so that shape object can access this.

The only piece of missing functionality is the context menu and ui. But... no
new ui needs to be created ( so no new strings, translations etc ) it should be
possible to re-use the existing presentation dialog ( sd/
source/ui/dlg/tpaction.cxx ) of course that would 
a) need to be moved to somewhere common that could be accessed by sc & sd ( I
have no clue about ui :-( )
b) need to be modified so that a mode could be passed to it so that the choices
in the list box are "RunMacro, No Action"

whatya think?
Comment 1 noel.power 2005-12-08 11:57:47 UTC
Created attachment 32201 [details]
Comment 2 noel.power 2005-12-08 11:58:52 UTC
Created attachment 32202 [details]
xl doc with autoshapes with macros
Comment 3 noel.power 2005-12-08 12:35:32 UTC
added cc:
Comment 4 daniel.rentz 2005-12-13 17:35:32 UTC
DR->FL: please have a look at this feature. It adds a macro link to all custom 
shapes (currently only possible for form control objects). This is needed for 
compatibility to Excel.
Comment 5 daniel.rentz 2005-12-13 17:39:01 UTC
@Noel: please rework the Excel filter part. I don't like this "hacky" public member 
maMacroName ;-)
Comment 6 noel.power 2005-12-14 10:17:00 UTC
added dr ( cc )

Daniel, FL
>@Noel: please rework the Excel filter part. I don't like this "hacky" public
>maMacroName ;-)

your right of course, thats a bit naff ( totally forgot to fix that up when
cleaning up the patch ), so great, thanks for spotting that :-)
I upload a new patch before end of today ( 14/12/05 ) or tomorrow latest & you
can let me know if its ok for you or not :-)

Comment 7 noel.power 2005-12-14 11:49:18 UTC
Created attachment 32377 [details]
moved maMacroName to be private & added GetMacroName accessor
Comment 8 noel.power 2006-02-28 12:49:48 UTC
Urgh, we ( at ) found a subtle problem with this patch. The patch
uses a ScDrawObjData to store the macro name in the shape, this is not ideal because
a) the ScDrawObjData ctor leaves some unintialiased data e.g. member 
bValidStart is never initialised
b) on import even if no macro is associated with the shape then the
ScDrawObjData is created.
c) in the particular instance where this was observed to be causing a problem (
for arrows ) the repositioning code depended on bValidStart been initialised
correctly which of course resulted in somewhat random badness ( depending on the
value of the unitialised variable )

So, I've reworked the patch ( not radically ) instead of using a ScDrawObjData
shape object to store the binding, shapes with associated macro now use a new
type ( ScMacroInfo ) to store the binding. This ensures that we don't affect
existing code that may use/depend on the state of ScDrawObjData data. 

Comment 9 noel.power 2006-02-28 12:50:52 UTC
Created attachment 34512 [details]
new patch version
Comment 10 frank.loehmann 2006-03-06 13:44:10 UTC
FL->DR: I support this change for OOo 2.0.3.
Comment 11 frank.loehmann 2006-03-14 14:10:42 UTC
FL: I support the patch for OOo 2.0.3 too.
Comment 12 daniel.rentz 2006-03-14 17:35:01 UTC
Comment 13 noel.power 2006-06-19 14:46:01 UTC
I had occasion to revisit this issue again because I came across the same
situation for import of hyperlinks. So when I was creating the patch for
hyperlinks ( see issue 66550 ) I folded in those comments ( from a private mail
) you had previously. Also issue 66550 has a patch that depends on the latest
version of the patch ( with those modifications folded in ) for this issue

So, what's the story with this issue, is it currently being worked on? ( I guess
I'm really talking about the ui part ) if not, I think I may be able to get some
time to look into the ui bits ( but if thats already being taken care of then
there is no point in me looking at it )

imo 66550 should be fixed at the same time ( due to overlap ), can I do anything
here to help? ( with either issue )
Comment 14 noel.power 2006-06-19 14:46:56 UTC
Created attachment 37232 [details]
patches with comments folded in
Comment 15 noel.power 2006-06-27 08:37:30 UTC
Created attachment 37343 [details]
latest version of patch ( with ctx menu for assign/remove macro )
Comment 16 noel.power 2006-06-27 08:39:33 UTC
Created attachment 37344 [details]
screenshot showing new macro assign context menu
Comment 17 noel.power 2006-06-27 08:41:19 UTC
Created attachment 37345 [details]
screenshot showing new macro assign dialog
Comment 18 noel.power 2006-06-27 08:43:00 UTC
Created attachment 37346 [details]
test document ( used for the screenshots )
Comment 19 noel.power 2006-06-27 08:48:06 UTC
Created attachment 37348 [details]
the xls version of document
Comment 20 daniel.rentz 2006-07-03 15:55:02 UTC
There was no time for me to look into the UI parts, so please take care of this. 
Also, we need a specification for this, should not be that difficult with the 
specification template. For now, I have to retarget this issue to 2.x, but we can still 
integrate it into 2.0.4, if the patch and spec are ready in time.
Comment 21 noel.power 2006-07-06 09:48:27 UTC
spec is available from here
the patches already contain the ui bits
Comment 22 noel.power 2006-07-06 09:58:20 UTC
npower->dr so, the spec is basic, please feel free to help, contribute, push,
take ownership even ( I really don't care, I'm not possessive ) etc. from your
side. I have put prelim i-team members in there etc.  some names are missing,
you could help fill those in also. 
If this is to have any chance of make 2.0.4 it will need a good shove, 
You could help if you can get agreement from re or whoever from your side to
allow the resources to be done seperately ( to meet the ui freeze deadline) that
would give us some space. But all of this hangs on getting the spec approved asap
Comment 23 daniel.rentz 2006-10-23 16:16:17 UTC
specification has been updated by the User Experience team.
Comment 24 noel.power 2006-10-26 16:22:29 UTC
its great the spec, has been updated, but, I guess I'm a little fuzzy as to what
happens next. Is the spec approved? (seems not) are the issues mentioned in the
  specification noted as future work? ( it's not clear to me ) or is this an
initial review with more *stuff* to come?
imo none of the comments in the specification should block the implementation of
the feature, I'd like to comment on the 2 ( I could only see 2 anyway ) issues

a) visual feedback that user has clicked the item, I completely agree with the
comment. But, currently I have no clue how to do this, maybe someone in the
framework team could  help here. In anycase this is imo a minor cosmetic change
that we could do later

b) this should be something available across all apps. Sure, that's a valid
point. Unfortunately this seems like it may be a little bit easier to say than
to do. Currently each application seems to do their own filter bits and also
offer specializations of the drawing objects ( why, I have no idea, presumably
necessary for some valid reasons ) look at presentation for instance it seems to
have even its own specialised custom interaction handling that is different again. 
So, although a good idea I would think this is something that should be handled
in a broader rework effort. That effort however is outside the scope of this
particular enhancement 

Comment 25 daniel.rentz 2007-06-13 14:19:57 UTC
target, started
Comment 26 daniel.rentz 2007-06-13 15:38:04 UTC
patch (finally) integrated in SRC680/dr55 (OOo 2.3)
Comment 27 daniel.rentz 2007-07-02 12:47:11 UTC
back to QA
Comment 28 oc 2007-07-04 13:39:56 UTC
Created attachment 46513 [details]
Comment 29 oc 2007-07-04 13:42:03 UTC
verified in internal build cws_dr55
Comment 30 oc 2007-08-07 13:43:56 UTC
closed because fix available in src680_m225 (OOo 2.3)