Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.orgThis page is one of several trying to help you get the most out of the splendid Open Office. They are allied with a larger set concentrating on ooBase.
Remember that Open Office, including ooBase, is free! But don't let that fool you. And it's not new. Big organizations, government and civilian, are adopting it as their standard office suite... and saving million$, and still Getting The Job Done.
There's more about ooBase in the main index to this material.
This page is "browser friendly". Make your browser window as wide as you want it. The text will flow nicely for you. It is easier to read in a narrow window. With most browsers, pressing plus, minus or zero while the control key (ctrl) is held down will change the texts size. (Enlarge, reduce, restore to default, respectively.) (This is more fully explained, and there's another tip, at my Power Browsing page.)
Page contents © TK Boyd, Sheepdog Software ®, 2/06-6/09.
What you are reading arose when I decided that an essay I was trying to write was getting out of hand. From that essay arose this and three others!
In this page, I will set out the underlying concepts you need for Open Office macro programming. Once you are clear about them, the next two pages to read are....
When you've mastered that, you will be ready for what started all of this....
"But I don't want to export CSV!", I hear you cry. Read the essay anyway. It will give you the tools to do lots and lots of fun things, via macros, with ooBase databases. It will also give you the tools to use ooWriter to create "programs", aka "applications". Maybe not the next chart busting-video game... but almost anything I wrote in computer classes at university in the 70's could be written as a macro powered ooWriter document.
By the way, for those too timid to ask: CSV is a way of storing "stuff" in a file. Guess what... I've written essays about that, too... but you don't need to understand CSV to follow all of the Good Stuff in these tutorials about macros. CSV, for our needs, is just a way of "writing" something on a disc.
Lastly, there are some scraps left over after editing process in the following document....
If you want to consolidate your learning after reading the other essays, it might be helpful. It does present a whole new macro example, too: a checkbox which changes its label.
To make your Open Office applications do all of the things you could make them do, you need to understand.....
...and you need to learn to apply the general principles of the above within the Open Office environment.
There! I said it "all" in just three lines! Be afraid, be very afraid: In order to become an apprentice in the matters I've just so succinctly outlined is not a simple task. But it can be done! If you are in a hurry, skip over the next section...
Remember learning to ride a bike? If you don't know how, it seems impossible. Try, try, and try again and suddenly you flip into the "I can do this. I will always be able to do it. Why couldn't I yesterday?" state.
Computer programming seems to be a similar learning task. Furthermore, as students approach the breakthrough point, they seem to become more and more dispirited, dejected. It is like running into the surf.... except that in learning programming, at a certain point a sudden breakthrough occurs.... if you haven't give up when you got the "this is impossible" feeling.
=====
So much for the good news. There's also a bit of bad news: Not everyone has the fundamental aptitude for programming.
In school, quite rightly, even those pupils with no knack for mathematics are required to struggle with it for quite some time. Some pupils do well, many will always be weak in mathematical topics.
But we all need some mathematical fluency, hence the flogging of near-dead horses. Sorry. I meant "encouragement", didn't I?
Not everyone needs to have programming skills. So if "your friend", has struggled and struggled, be prepared to consider that maybe "he" just doesn't have the knack.
Society today would like us to believe that we are all created equal. While I would vigorously defend the principle that children with two left feet on the ends of two stubby legs should have an equal chance to have fun (if they think it is fun) playing (at) soccer, I think we need to stop kidding ourselves, and deceiving the kids: There are those among us who aren't cut out for sports. And we are different from one another in our mental capabilities, too. Pretending otherwise is foolish. There's a name for being out of touch with reality.
So! Now that we've dealt with those issues, back to work....
I've been doing OOP for about 15 years now... and I still don't understand it, really. But I can get things done! (For proof of that claim, see my freeware and shareware website... Please!)
To do OOP, you need to have some idea of....
You also need to master one of the features of objects: they exist in hierarchies. And lastly, you also need to distinguish classes of objects and instances of objects. (The last one isn't too hard!)
So! Let's dig into those topics....
When you are trying to see something in the forest at night, with no flashlight, you will have better results if you look just to one side of the item which interests you. (This is due to the anatomy of the back of your eye.) It takes a little practice, but once you have the trick of perceiving something that is offset from where you are looking, the trick works well. But look directly at the item of interest, and it may disappear again.
The precise meaning of "object" is a bit like this. Try not to "over-think" the question of "what is an object". Be a little relaxed. Use the force. Don't "look at" it too hard.
An object is.... an "object"! A thing. An entity.
Forget programming for a moment. Just think about using any computer program you are familiar with as a mere user. Let's, for instance, take your web browser.
The browser itself is an object. The mouse pointer is an object. The following are all objects....
So much for some fairly obvious objects. There are other objects which are more abstract. Your printer is an object, not only in the physical sense but also in the abstract sense of someplace to which you can send stuff. Your disk drive and other storage devices are objects. The keyboard and your sound system are objects.
Get the idea? Those examples will suffice for the moment.
--- OBJECT HEIRACHIES
Part of the reason programmers turned to Object Oriented Programming (OOP) so enthusiastically was that OOP brings programming closer to the real world. Programming will always involve being comfortable with intangible elements, but the OOP perspective helps programmers visualize what they are dealing with.
In OOP, objects are hierarchical, just as they are in the real world.
What does that mean?
Forget about computers for a moment; think about a dog. A dog is an object. That "object" is made up of other objects: head, leg, tail, etc. Each of those are made up of objects... for instance, the hind leg has femur, tib/fib, and paw. The paw has toes and claws.
If you were "making a dog" (creating a program) you could "build" it a bit at a time. You PLAN (design the program) the overall object, the dog, first ("top down"), but then you ASSEMBLE (develop, "bottom up") it by starting with the sub-sub-sub assemblies, and working "upwards"... so:
You plan: It will have head, body, legs, tail. Then you go "down" a step, e.g. to plan the leg: It will have femur, tib/fib, and paw. Then you go "down" a step, e.g. to plan the paw. You will go down similar paths, some of them branching, from each of the other main parts.
Then you assemble, bottom up....
You make claws, and the other parts of paws. You assemble those parts into paws. You make the femur units, the tib/fib units. Now you can assemble the legs. You put the head, the trunk together in a similar "bottom up" way. And, finally, you can assemble the four leg units with the trunk unit, and the head unit... (Oh yes: and a waggy tail, of course)... and you have a "dog"!
The beauty of this approach is that it makes it easy to concentrate on one bit at a time, get that "right", in isolation, and thus you are able to manage something which, overall, can be quite huge. Divide and conquer.
You can probably come up with your own examples of everyday objects which can be broken down into component objects, which themselves can be broken down again, etc.
Now let's get back to computer programming.
The "objects" an OOP programmer works with... and you will become familiar with them along the way of doing programming examples... are similar. As I said: It is easy to "over think" this one. Just persuade yourself of the fact that objects ARE. (Like love, actually, IS.)
--- OBJECTS: CLASSES AND INSTANCES
Don't worry too much about the next few paragraphs. Read them, but until you reach the "Properties" heading, just keep going....
Go back to the dog analogy again. We all know what a dog is. The "general idea" of a dog isn't hard. We also know specific dogs... Fido, Spot, Bella.
In computer programming, we speak of object classes. This is "class" in the sense of "category", or "type", NOT in the sense of "instructional gathering of pupils."
There is a "class" called "dog". Also a "cat" class. These objects are both in the "vertebrate" class, by the way, to take us back to the issue of object hierarchies for the moment. See how simple it is?
Sometimes we want to speak of a particular dog, e.g. my good friend Fido. Fido is an object... and he is an instance of the "dog" class. (And every "dog" object is also an instance of the "vertebrate" class.)
In your programming, in working with macros, you will have "Dim" statements at the start of each macro. ("Dim" from "dimension". You are telling the computer to set some space aside. Nothing to do with "not bright", however overwhelmed you may be feeling at the moment!)
A "Dim" statement will prepare the way for working with an instance of a class of object. We might have....
Dim AFriend as Dog
... to make an analogy. In some hypothetical language, that would set up a variable called "AFriend" into which I could put an instances of a dog-type object, e.g. Fido.
It will soon seem "natural" to you to think both of classes of objects and of instances of objects. Don't worry over-much about the distinction... but try to notice when your thinking of an instance of something, and when you are thinking about a class.
Whew... that's most of the hard stuff done. Properties and methods are less arcane.
Objects have "properties". Sometimes a property can be set when you are high up in the object hierarchy. The color of my favorite Labrador is black. I can say that this instance of the "dog" object is "black", and I am done. The leg, paw and toe objects "inherit" their color properties from the higher level object. In another breed of dog, the colors of the different parts might be different, in which case I can over-ride the inherited default for the color property of one of the subordinate units, and, for instance, "create" a dog with a white head but a black tail.
Besides objects and their properties, what's left to the story of OOP is methods. Methods are things that objects can do. To stretch the analogy a bit, a "dog" object has a "jump" method, a "run" method, a "sleep" method. The dog's throat object has a "bark" method.
In my hypothetical language, you could write the following to create a dog, and get him to make a welcoming bark...
Dim oAnimal as object
Dim oPartToUse as object
oAnimal="Fido"
oPartToUse=oAnimal.getByName("Throat")
oPartToUse.Bark="Welcome"
oPartToUse.doBark
The Dim statements create the variables to hold the things we want to deal with, refer to.
We put WHICH dog we want to use in oAnimal with oAnimal="Fido". We are saying "Fill the oAnimal variable with that instance of the class "dog" which is called Fido.
The next line starts "oPartToUse=", which tells the computer that we're going to specify something to go in that variable. "getByName" is a "method" of all "dog" objects, and allows us to "get" one of the dog's parts. After "oPartToUse=oAnimal.getByName("Throat")", we can refer to Fido's throat simply by referring to oPartToUse, which is "holding" Fido's throat.
You might guess that "oPartToUse.Bark" implies that "Bark" is a method of oPartToUse, but it isn't. It is a property of the object. This is another place where you can over-think things. Just step back, "use the force".... it "makes sense".... eventually. We're setting the type of bark that Fido's throat will emit as a result of the next line.
"doBark" is a method. When the program or macro gets to "oPartToUse.doBark", the doBark method is called, and we get the bark.
It will become intuitive to you, if you bang your head against the wall long enough.
To recap a detail: oPartToUse.Bark refers to a property, oPartToUse.doBark invokes a method. This "ambiguity" isn't as hard to live with as you might think.
Take a break! You have got through the worst of it! At least your first pass through the worst of it. The topics above are things that you will revisit again and again, consciously and sub-consciously. You were taught about sharing as a toddler... but you're always deepening your understanding of the concept. So too with the ideas of objects, properties, methods, hierarchies, inheritance.... even if they aren't as important.
Just one little thing before your break...
While the....
oPartToUse.Bark="Welcome" oPartToUse.doBark
... notation looks a little strange until you get used to it, it is actually quite elegant. You sometimes find several elements strung together, too, so you might find something like....
oDocument=ThisDocument oDocument.Footer.Text.Font.Size=12
That is a made up example, but is plausible, assuming that the system can put a document in an object-type variable, and that the object has a property called "Footer", which has a subordinate property called "Text" which has a subordinate property called "Font" which has a subordinate property called "Size"... which can be set to 12! As I said, the example is hypothetical, but a line just like that could easily work in some environment.
Whether you use Windows, Linux, or a Mac, you are operating within an "event driven environment".
Windows and Linux are both event driven operating systems. Good news: This "events" thing is easier than the OOP stuff you've already struggled through.
When you have a document on the screen, the computer isn't just waiting for you to press the next key on the keyboard, as it might have been in The Good Old Days".
For instance, you may not only have the document open, your email program may also be running. You may have the email program set up to check your mailbox from time to time, and to notify you of new mail. Your computer's time-of-day clock is certainly ticking away. And the computer (more specifically, the operating system) is "watching" both the keyboard and the mouse to see if you are pressing keys or moving or clicking the mouse.
Everything hinges on "events". Pressing a key gives rise to an event. Moving the mouse generates at least one event, possibly several.
The operating system (OS) is continually watching for events. When it sees one, it checks the state of sundry relevant properties, and invokes an event handler to respond to the event. It also takes care of deciding which of the programs running in the computer should "see" the event happened.
There are scores of events which you can forget about. We'll come to them briefly in a moment. But if you produce a macro, you will probably make it be the event handler for something. In the next essay in this series we will see how to attach a little macro that puts "Hello World" on the screen to the event handler for what should be done if the mouse button was clicked when the mouse pointer was over the button we put on our page. (See what I meant a moment ago when I said the OS "checks the state of relevant properties"? The OS checked to see where the mouse was when it was clicked, and only invokes the "Hello World" code when the mouse is over the right button. The location of the mouse pointer is a property of the mouse object.)
What about those events we can forget about? They are in two categories....
** Events like the one that watches the "tick tock" deep within the OS and changes the time of day displayed on the screen once a minute
** Events which, for now, we are happy to have the OS deal with in the "ordinary" way. We may eventually tell the operating system to let the event handler in our program respond to the event, but for now "the ordinary" is sufficient.
Well.... I wish I could say I've "told you everything". I can't. My piano teacher tried to "tell me everything" when he said "You play the piano by pressing down the keys with your fingers". While that may be "everything", just knowing it doesn't mean you have the skills, or know enough of the details behind "everything". But it is important to know the overall shape of what you are trying to do.
You've had an introduction to the essential elements of making your computer do what you want it to. To make progress, keep the big ideas in mind....
Revisit this essay from time to time. You might be surprised at how something means more when you re-read it in a few weeks time, after gaining more experience with programming. Programming is an art, a craft, not a science. Successful programmers bring more to their work than a mere grasp of the language's vocabulary and syntax. The artist's competence grows through practice.
The next thing for you to read, which ironically was the third thing I wrote in this creative burst, is the little tutorial about putting a button on an ooWriter document, and making the document put a message on the screen when you click the button. Bach's B minor Mass, it isn't, but it will exercise the skills you need, and help you become familiar with certain basic terminology. If you are "an expert", it will take you 5 minutes... but will still be worth doing, to put us on "the same page". Beginners will get even more from the exercise.
When you've done the "Hello World Button" tutorial, it will be time to tackle the "Export CSV With A Macro" tutorial. To repeat what I said earlier: even if you don't want to export data as CSV, if you want to use macros with ooBase, this is a tutorial you really shouldn't skip.
A little aside, as I am feeling sorry for myself and want a shoulder to cry on: All I wanted to do when this creative burst seized me was to write the "Export..." tutorial. It proved to be a much larger undertaking than I anticipated. I wrote something huge and unsatisfactory, which led to a big re-write, resulting in what you are reading now, then the much re-written "Export..." tutorial, and finally (in the sequence of creation) the "Button..." tutorial that helps you get from "beginner" work to the intermediate level topics in the "Export..." tutorial.) (Oh yes.... and the "Misc Thoughts" essay with "the left-overs".)(And shortly thereafter three more essays arose when I had a relapse of creative fever.)
Thank you for reading. I hope you'll press on to the next two parts. Not "fun", but they will reward you in the long run.
The documentation can be extremely frustrating. I am still unable to navigate it easily. Also, searches for things which I know are present, e.g. "ConvertFromURL", fail to find the excellent relevant pages.
You can try using something like...
site:wiki.services.openoffice.org ConvertFromURL
... as a Goggle search string. It turned up the right page... along with 8 other hits.
* Guide to ooBasic.... the language of Open Office macros...
The OpenOffice.org page where the ooBasic guide starts. The flawed search engine remains a problem. You may find that digging in the "Runtime library" section turns up Good Stuff, depending on what you are looking for. (A lot of what I wanted was there.)
* Guide to OO API.... the "things" Open Office is built from, e.g. getByName. They (I'm pretty sure) underlie all of Open Office. How you get to them, directly, with ooBasic I'm not so sure about.
The "things" include what I would call objects, methods and properties. The nice people at Open Office use the term "service" for some things I think of... quite possibly ignorantly... as objects. Not everything I call an object is a service. Some of the things I call methods they call functions. We both use "property" the same way... I think! The API guide also tells you about other useful things. If you want to become a skilled OpenOffice programmer, it would probably be very wise to attempt to master "What is a thingie", where "thingie" can equal...
Don't be overwhelmed by that list. It really isn't as bad as it seems.
The Guide is at this OpenOffice.org page
* Creating, saving, loading documents... Although the following is "just" a discussion within oooForum.org, it incorporates a commendable tutorial which takes you through the basics. An excellent introduction.
oooForum.org essay on basic document operations.
I dislike 'fancy' websites with more concern for a flashy appearance than for good content. For a pretty picture, I can go to an art gallery. Of course, an attractive site WITH content deserves praise... as long as that pretty face doesn't cost download time. In any case....
I am trying to present this material in a format which makes it easy for you to USE it. There are two aspects to that: The way it is split up, and the way it is posted. See the main index to this material for more information about the way it is split up, and the way it is posted.
PLEASE >>> Click here to visit editor's Sheepdog Software (tm) freeware, shareware pages <<< PLEASE
If you liked this ooBase tutorial, see the main index for information other help from the same author.
Editor's email address. Suggestions welcomed! - - - Want a site hosted, or email? I like 1&1's services.
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
. . . . . P a g e . . . E n d s . . . . .