improved vba support
If you can't read please download the document
TRANSCRIPT
Improved VBA Support
Noel Power
Introduction
About Me
Working/hacking Openoffice.org ~ 4 years
working on VBA interoperability
A Bit of History
Started in response to customer demand
Various people have stuck there hand in here and there
Releases
SUSE 10.1 ( first appearance )
SUSE SLED 10 ( first supported version )
Started VBA Interoperability incubator project
http://vba.openoffice.org or
http://wiki.services.openoffice.org/wiki/VBA
Project Update
Novell & Sun work together
http://blogs.sun.com/GullFOSS/entry/sun_and_novell_work_together
Sun opensources the Microsoft Office Macro Runtime Library ( MORL )
thanks to Michael Meeks, Kai Ramme, Juergen Schmidt, Andreas Bregas
http://bonsai.go-oo.org/rview.cgi?cvsroot=/home/ooweb/cvsup&dir=api/helperapi&module=OpenOffice
Andreas Bregas joins the project as co-lead
What does this cooperation mean for VBA interoperability
Eventually we can have a single solution.
Pluggability
MORL provides a Java uno implementation code that can be ported to C++.
MORL has some test documents and associated infrastructure ( logging support ) that we can reuse.
The promise of addressing Word macros in the future.
Where are we
Architecture changes
vba interoperability delivered either as
a standalone extension
built into openoffice itself
key objects are services ( new style )
internal namespace changes to allow extension for word support
Porting
To aid porting from the helperapi ( MORL ) C++ code now provides a XHelperInterface ( we should perhaps provide an XUnoAccess interface... takers? )
Constants are now generated from meta-data ( thanks to Jan Holesovsky (kendy) for perlification )
A good few classes have been fully or partially ported from MORL
UpStreaming
many vba compatibility issues have been addressed in various abxxx and npowerxxx cws(s) like..
Planned for OOo 2.4
npower7 stack of vba compatibility issues resolved
npower8 object module changes, sync with ooo-build, some MORL porting
What's Next
Object modules ( Sheet, Workbook, perhaps even support for 'simple' Form modules )
Change how compatibility is handled
aim for no more 'option VBASupport 1' type nonsense
compatibility from the 'document' basic manager down rather than the module level
Application specific Dialog/UserForm controls ( longer term goal )
Event handling, faking compatible events for controls and controls on Userforms
support for Error Object, e.g.
Error.raise some descriptive text
What can you do to help
Get involved
irc, #go-oo { me = noelp }, mail [email protected]
http://wiki.services.openoffice.org/wiki/VBA
Identify missing api & test existing api
some basic tests at ooo-build/tests/macros
cws npower8 will include some test documents
Help port MORL to c++
http://wiki.services.openoffice.org/wiki/Porting_notes#Calc_Objects_to_port
http://wiki.services.openoffice.org/wiki/Porting_notes#Hints_for_porting_idl
How have we done.... ( lets see how far we have got in relation to the issues identified in last years presentation at OOCon )
http://marketing.openoffice.org/ooocon2006/presentations/tuesday_g1.odp
Upstreaming
Not enough hacks upstreamed yet
Option VBASupport
provides a basic indicator that interoperability is 'on'
used a hook internally in the basic engine
css::com::ArrayWrapper
multi-dimensional array support for Objects
influence the base of the Array regardless of the Module 'Option Base' setting
Array(...) function & Option Base
Support a 'default method' concept
What needs to be upstreamed
Dim r1 as Range
Set and assignment for vba objects
Most vba constants are available ( maho )
Default properties { LHS & RHS }
Global objects
Application, Sheets...
Compatibility API
Range, Workbook, Worksheet...
Better event support
Excel toolbox controls, shapes, images, workbook, worksheet
Larger basic module support
VBA exotics
set r1 = Range(a1)
r1 = foo ' value of cell A1 is set to foo
dim aVar as String ' or variant
'aVar wil contain foo
aVar = r1
'Collections
dSheets = Worksheets ' global
wrb = dSheets(1)
wrb = dSheets.Item(1)
wrb = dSheets.("Sheet1")
wrb = dSheets.Item("Sheet1")
Whats Next
Basic Support for Userforms & Controls
tie Userform module to Dialog
allow contols to be accessed from Worksheet
Sheet(1).CommandButton1
Sheet(1).MyComboxBox.AddItem( ListItem )
Compatibile Array handling
array of array syntax myarray(2)(3)
copy by value
Import internal Collection class
handle string key in Item & add methods
Generally Improve API coverage
More document analysis
Andreas Bregas
Software Engineer
Sun Microsystems, Inc.
Improved VBA support
OOoCon 2007 Barcelona
Introduction
About me
Working for Sun Microsystems (Star Division)
for 12 years
Responsible for
OOo Basic core (compiler, runtime system)
OOo Basic IDE, Dialog Editor, Scripting Framework, ...
Joined VBA Interoperability incubator project
as co-lead in February 2007, focussing on
Extending OOo Basic core to support missing VBA functionality
Fixing VBA compatibility related problems
Reviewing patches containing Basic core changes
Extending OOo Basic functionality
Original reference for OOo Basic was VB 4.0
VB(A) >4.0 features are missing
Compatibility to VBA is not 100%, many small issues
Examples for Basic core related issues
Done: Class support feature, Modules > 64K
Done: Many new Runtime Functions
Done: Many fixes of Runtime Function behavior
Todo: Class support / event handling for Userforms
Todo: Support array of array syntax
Todo: Basic core support for VBA exotics
Microsoft Office Macro
Runtime Library (MORL)
Emerged from Sun internal Macro Migration project
Developed for some years with much effort
With the start of the VBA interoperability project there were two parallel approaches
To support a single open solution Sun decided to join the VBA interoperability project
MORL was made open source
Microsoft Office Macro
Runtime Library (MORL)
VBA API is described as UNO API
VBA API is implemented in Java, ~3,5 MB of code
Covers about a big part of the Word and Excel API
~1100/1500 Word symbols
~1000/1100 Excel symbols
Needs Macro Migration Tool to adapt VBA sources
MORL versus VBA Interoperability
Using MORL for VBA interoperability
Use Java code as template to extend C++
Already started for Excel
Use both, taking some symbols from MORL,
other symbols VBA interoperability solution
Technically very difficult
Unfavorable mixture of different approaches
Use MORL for Word only
Could be reasonable as a temporary solution
Would require some changes,
both in MORL as in VBA interoperability library
Todos for using MORL for Word
MORL: Get rid of source code migration step
General Application object instead of Application.Writer
Support all other global objects like ActiveDocument, ActiveWindow, Documents without using a Basic library
Direct support for VBA constants, e.g. wdYellow instead
of com.sun.star.helper.wdYellow
Get rid of Option Compatible, CompatibilityMode()
VBA interoperability library
Support intelligent Application object to distinguish between Word and Excel API according to the current document type
Improved VBA support
Andreas Bregas
17 September 2007
Click to enter the title (44pt)
Second line or subtitle (22pt)
Presenter Name (16pt)
Presenter Title (14pt)
Company/email (14pt)
Click to edit the title (32pt)
Click to edit the outline first line (28pt-no bullet)
Second Outline Level (20pt)
Third Outline Level (16pt)
Fourth Outline Level (14pt)
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
Ninth Outline Level
Novell Inc, Confidential & Proprietary
Click to edit the title text format
Click to edit the outline text format
Second Outline Level
Sun Confidential: Internal Only
Click to edit the notes format
Page
Click to edit the title text format
Presenters Name
Presenters Title
Presenters Company
Click to edit the notes format
Page
MORLVBA Interoperability Based onJava / UNOC++ / UNO Basic CodeMigrated with toolVBA code used directly API entryVia Basic LibraryHard coded in Basic CoverageWord + ExcelExcel only so farConclusionAdvantage of MORL's API coverage should be used
???Page ??? (???)17.09.2007, 15:41:45Page /