Linux.com

Feature

An introduction to OpenOffice.org Basic

By on October 07, 2005 (8:00:00 AM)

Share    Print    Comments   

One of the features some users overlook in OpenOffice.org is its built-in programming language, OpenOffice.org Basic. Why would you want a programming language built into your word processor? It's there to help you to automate tasks. It won't make the tea for you, but it will help you to carry out many repetitive jobs with a minimum of effort.

Placing data in tables can be a time-consuming part of creating a report, but tables make a document easier to read, so it's worth automating the process. The next macro takes a file and loads it into a table. In this case the table is populated with the username and home directory fields from the /etc/passwd file:

Sub doPasswdTable
	Dim filenumber As Integer
	Dim lineNumber As Integer
	Dim lineCount As Integer
	Dim iLine As String
	Dim file as String

	Dim doc as object
	Dim table as object
	Dim cursor as object
	Dim cellname as object
	Dim cell as object

	file = "/etc/passwd"

	'Get line count
	lineCount = 0
	filenumber = Freefile
	Open file For Input As filenumber
	While not EOF(filenumber)
		Line Input #filenumber, iLine
		If iLine <> "" then
			lineCount = lineCount + 1
		end if
	wend
	Close #filenumber

	doc = thisComponent
	cursor=doc.text.createTextCursor()
	table=doc.createInstance("com.sun.star.text.TextTable")
	table.initialize(lineCount+1,2)
	doc.Text.insertTextContent(cursor,table,False)

	cell = table.getCellByName("A1")
	cell.string="Username"
	cell = table.getCellByName("B1")
	cell.string="Home Directory"

	filenumber = Freefile
	lineNumber = 2
	Open file For Input As filenumber
	While not EOF(filenumber)
		Line Input #filenumber, iLine
		If iLine <> "" then
			Dim iArray
			iArray = split(iLine,":")
			cell = table.getCellByName("A" & lineNumber)
			cell.string=iArray(0)
			cell = table.getCellByName("B" & lineNumber)
			cell.string=iArray(5)
			lineNumber = lineNumber + 1
		end if
	wend
	Close #filenumber
End Sub

Most of the coding is fairly standard -- you can see an example of a while..wend loop, and an if...end if statement. You may also notice the statement doc=thisComponent; this allows me to refer to doc rather than the more cumbersome thisComponent.

Something that may not be as obvious is that Basic is not case-sensitive. Therefore cell = table.getCellByName("A" & lineNumber) will work as well as CELL = table.getcellbyname("A" & LINENUMBER). We use mixed upper- and lower-case letters purely for ease of reading.

The line filenumber = Freefile assigns a unique ID to the filenumber variable, without your having to remember any IDs that you've already assigned.

The split command is particularly useful. It takes an string and returns an array of substrings, broken up according to the delimiter that you supply. In the example above we've used a colon (:) to identify the field separator in the passwd file.

Finally, one line that may look strange at first is Open file For Input As filenumber. This refers to the fact that we're using it as an input to the subroutine, not that we're going to input anything to it.

In conclusion

This is just the briefest of introductions to using Basic in OpenOffice.org Writer. We haven't covered the use of forms, dealing with other documents, or how to obtain information from datatabases.

If you want to learn more about programming in OpenOffice.org Basic, the OpenOffice.org help comes with a list of all the functions and subroutines that are available. You can also try using the OpenOffice.org Record Macro facility, and then examine the code that the application builds for itself.

OpenOffice.org Basic is a useful tool for automating everyday tasks -- just one more way of working smarter instead of harder.

 

Share    Print    Comments   

Comments

on An introduction to OpenOffice.org Basic

Note: Comments are owned by the poster. We are not responsible for their content.

portability warning

Posted by: Anonymous Coward on October 08, 2005 03:26 AM
Embedding macros in your document is asking for trouble.

It adds another dependency on the original program/set of programs used to edit it.

Ask people who tried to move documents containing WordBasic/VBA to Oo.

#

Re:portability warning

Posted by: Anonymous Coward on October 08, 2005 05:36 AM
This is so true and has already happened on such a large scale that it amazes me that people constantly forget it.

WAY WAY back in 1995 when the domination of WordPerfect was waxing and everyone was trying to convert to MS Word, the biggest problem was the thousands or millions of heavily used WordPerfect macros that did not work in MS Word. It was a huge problem that required the manual conversion of the macros and millions of documents that used them. After years of conversions, most people had switched to Word and they started the mistakes all over again with the use of Visual Basic for Applications(VBA). VBA is the dominant macro/scripting language today, simply because the vast majority of people use Word or MS Office but, if they ever want to switch, they face a major problem with the lack of compatibility between VBA and whatever else.

I can't imagine any business spending the money required to convert their VBA to OpenOffice Basic. But, even if they did, it would be a big mistake. Sooner or later, they will want to switch again, even if it is to OpenOffice V25 and the macros/scripts will be a problem. The problem will be so large as to impede their decision to switch which ironically, is where we are today. Businesses today are unwilling to consider switching to OpenOffice because converting macros and VBA apps is either impossible or so labor intensive as to make the costs unbearable.

#

Re:portability warning

Posted by: Anonymous Coward on October 08, 2005 06:26 AM
---Businesses today are unwilling to consider switching to OpenOffice because converting macros and VBA apps is either impossible or so labor intensive as to make the costs unbearable.

Not necessarily true anymore. Supposedly those buying the enterprise version of Staroffice get a macro converter that does most of the heavy lifting and identifies what it can't do to simplify any further conversion.

#

Re:portability warning

Posted by: Ronald Trip on October 08, 2005 08:41 PM
Not using Office automation isn't an option either.

Doing the same damn operations by hand over and over again, to create a run of the mill report every week, would burn out even the most zealous office clerk.

I am very much into FOSS in my personal life, but at work my employer has standardised on MS Office (that's the reality of day to day life).

I for one am glad that there is VBA and Pivottables. It enables me to do more interesting work than cut-and-paste data and lay-outing.

It may pose a form of lockin, but not using these poweful tools means you become a brainless, number-shifting monkey.

My Macro's are pretty simple (have only been actively involved with VBA for 6 month now). I guess I could recreate them in StarBasic, if the need should arise.

No matter how you turn it, when you standardise on an application, you become dependant on it. This is true wether you use MS Office, OpenOffice.org/StarOffice, KOffice or AbiWord.

#

Re:portability warning

Posted by: Anonymous Coward on October 08, 2005 09:02 PM
Perhaps standardized scripting languages used with formats built around open standards could be an answer.

I saw your<nobr> <wbr></nobr>.sig - I don't want to be too personal, but "./universe"? How's that possible? Did you solve an enigma and find where it is mounted?

#

Re:portability warning

Posted by: Anonymous Coward on October 09, 2005 09:22 PM
Standardzing the scripting language is fine, but not really that helpful. Writing an automatic converter for that is excedingly trivial. The hard part is writing a converter that deals with an entirely different object structure -- an API in programmer terms. Even if for some reason Open Office could run Microsofts VBA, this would be a major problem. Sort of like running a VBA script written for word in powerpoint. The language is the same, but the aplication is not.

#

What about other languages

Posted by: Anonymous Coward on October 08, 2005 04:34 AM
Is it possible to write these macros also in other languages (perl, python, etc.)?

#

Yes its is support extra 3 forms

Posted by: Anonymous Coward on October 08, 2005 07:13 AM
Ok is the development version
Python beanshell and javascript.

In the version I have its can edit beanshell and javascript. Python has to be edited external.

Development in future will have more langs.

Someone really need to add<nobr> <wbr></nobr>.Net script link to OpenOffice as well. Version 2 is going to be great.

#

Re:Yes its is support extra 3 forms

Posted by: Anonymous Coward on October 08, 2005 10:54 PM
AFAIK Mono guys already working on<nobr> <wbr></nobr>.NET 2.0 support in OO.o

#

Re:What about other languages

Posted by: Anonymous Coward on October 09, 2005 09:07 PM
For perl you might want to have a look at cpan and search for "openoffice" and "ooo", there's some valuable modules. (<a href="http://search.cpan.org/" title="cpan.org">http://search.cpan.org/</a cpan.org>)

And if you have a look at <a href="http://www.openoffice.org/" title="openoffice.org">http://www.openoffice.org/</a openoffice.org> you'll see that ooo documents are just a zip file with xml files in it, so it's really easy to create your own templates with perl.

#

Re:What about other languages

Posted by: eocasio on October 10, 2005 04:03 AM
I agree with this approach. This is the way to go for report generation,document merging and database linking. However, if what is needed is an interactive document, I think we need the embedded macros.

#

Innovation!

Posted by: Anonymous Coward on October 09, 2005 03:34 AM
What a joke.

#

Re:Innovation!

Posted by: Anonymous Coward on October 09, 2005 05:42 AM
I couldn't agree more. It's not innovation. It's better.

It's open for anyone to use, implement, improve, or whatever, free of royalty requirements, patent constraints, or any other so-called "intellectual property" restraints other than the copyright on the specific implementation of OOBasic found in OpenOffice.org, which is Freely licensed under the GNU LGPL.

That is the beauty of Free Software. Let's see Microsoft top *that*!

#

Re:Innovation!

Posted by: Anonymous Coward on October 10, 2005 04:12 AM
Hundreds of millions of users and billions of dollars says Microsoft wins.

OO.o is cloneware with a stupid name and the "Freedom" to be shit.

#

Re:Innovation!

Posted by: Anonymous Coward on October 11, 2005 06:04 PM
Yeah - and I bet you 'paid' for your copy of Office didn't you...

Freedom to choose to pay $500 for Office or nothing for OOo is no bad thing.

You have the freedom of speech and opinion and the freedom to be a wanker too...

#

viruses?

Posted by: hanelyp on October 10, 2005 04:29 AM
I can't help but think of the spat of trouble microsoft word had with macro viruses. I hope this was considered in designing the OOo scripting system.

#

hmmm basic?

Posted by: Anonymous Coward on October 10, 2005 06:52 AM
While I appreciate this introduction to Macro programming with Basic, as a Linux user I tend to prefer scripting languages with superior syntax and greater versatility. I am a lot more interested in learning how to make Python macros. Basic is really an anachronistic language, and support for Basic is really only included to appease the people coming from Windows and Microsoft Office.

I use vim rather than OpenOffice for many tasks because support for Python and Ruby are absolutely essential to me. I would love to learn how to use those languages to script and extend OOo.

#

Re:hmmm basic?

Posted by: Teilo on October 11, 2005 03:36 AM
Actually, OOo already supports Python as a scripting languange natively. AFAIK, there is no Ruby support yet.

#

An introduction to OpenOffice.org Basic

Posted by: Anonymous [ip: 80.177.79.194] on December 07, 2007 12:06 PM
Well... two years on and it seems to me that the only people praising Openoffice can only be those who haven't had the pleasure of trying to do anything advanced with it. Experience soon teaches you that the api must be one of the biggest piles of dung heaped upon the computing fraternity ever, although perhaps beaten into second place by its documentation. Trying to do what would be simple operations accomplished in minutes in MS Office can take days or even weeks in OO - entirely due to an appallingly bad design and an architecture which must have been designed by cretins, documented by two men and a donkey. The result is that you can get it for free, but for many its going to cost you far more than you budgeted for in the longer term. What a pity, it didn't have to be this way.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya