Michele - I agree that the topic needs more explanation than is provided in the existing chapter. We may not have to cover everything you mention, but much of it would certainly help. I'll send you the existing chapter and we can discuss what is needed in more detail. There is no need to start editing the chapter. Let's lay out a plan first. I won't be able to dedicate a lot of time to this for the next few days, but you can read the chapter and see how much needs to be done. Francis
On Tue, Mar 17, 2026 at 8:22 PM Michele Petrovsky < [email protected]> wrote: > Folks, I've always been of the opinion that topics like macros, and the > programming needed to create them, should be handled in a way that takes > into account the skill and interest levels of the average user. For > instance, I tend to doubt that most of our users know what Star Basic or > its avatar QBasic are. > > As a result, I'd like to see either this part of a Getting Started Guide, > or standalone coverage of the topic of programming in some form of Basic, > be put together. Here's, an example of the topics I'd include: > > > Application > > Binary > > Bit > > .bmp > > Browser > > Bus > > Byte > > Chip > > Command Line > > CPU > > Database > > Default > > .doc > > Drive Letters > > Executable > > .gif > > Giga > > GUI > > Hardware > > Hexadecimal > > HTML > > HTTP > > .htm[l] > > .jpg > > Kilo > > Mega > > Network > > Operating System > > Pixel > > .png > > .ppt > > Protocol > > RAM > > ROM > > Server > > SMTP > > Software > > TCP/IP > > Tera > > .xls > > In other words, introduce users to basic computer-speak, and to the fact > that > - OpenOffice Basic is a domain-specific language designed specifically to > interact with and automate the features of the OpenOffice application > suite. Like other third-generation BASIC dialects such as Visual Basic, it > supports both object-oriented and event-driven programming paradigms. > > Which brings us to the point of clarifying what object-oriented and > event-driven mean. Object-oriented organizes software design around data, > or objects; , rather than functions and logic. Event-driven coding, on the > other hand, designs software in which the flow of a program is determined > by external events, such as user actions (mouse clicks, key presses) or > system-generated signals (network messages, sensor outputs). So, an > event-driven program waits for events and reacts to them dynamically. > > It might seem like I'm getting far too deep into the weeds. But I feel > we'd be doing better by our users if we give them at least this much of a > frame of reference. Simply presenting them with things like this: > > LET BOTTLES = 99: LET BOTTLES$ = "99": LET BOTTLE$ = " bottles"FOR A = > 1 TO 99PRINT BOTTLES$; BOTTLE$; " of beer on the wall, "; BOTTLES$; > BOTTLE$; " of beer."LET BOTTLES = BOTTLES - 1IF BOTTLES > 0 THEN LET > BOTTLES$ = LTRIM$(STR$(BOTTLES)): LET PRONOUN$ = "one"IF BOTTLES = 0 > THEN LET BOTTLES$ = "no more": LET PRONOUN$ = "it"IF BOTTLES <> 1 THEN > LET BOTTLE$ = " bottles"IF BOTTLES = 1 THEN LET BOTTLE$ = " > bottle"PRINT "Take "; PRONOUN$; " down and pass it around, "; > BOTTLES$; BOTTLE$; " of beer on the wall."PRINT: NEXT APRINT "No more > bottles of beer on the wall, no more bottles of beer."PRINT "Go to the > store and buy some more, 99 bottles of beer on the wall." > > or this, which would have intimidated the living daylights out of me early > in my working life: > > SCREEN 13DIM a(3976) AS INTEGER, b(3976) AS INTEGER, c(3976) AS > INTEGERDIM d(3976) AS INTEGER, e(3976) AS INTEGERcol% = 16: col1% = > 16: col2% = 16: col3% = 16: col4% = 16col5% = 16: col6% = 16: col7% = > 16: flag = 1: flag1 = 1flag2 = 1: flag3 = 1:flag4 = 1: flag5 = 1: > flag6 = 1: flag7 = 1DO GET (1, 38)-(318, 62), a PUT (2, 38), a, > PSET LINE (1, 38)-(1, 62), col% IF flag = 1 THEN col% = col% + > 1: IF col% = 32 THEN flag = 2 IF flag = 2 THEN col% = col% - 1: IF > col% = 16 THEN flag = 1 GET (2, 63)-(319, 87), b PUT (1, 63), b, > PSET LINE (319, 63)-(319, 87), col1% IF flag1 = 1 THEN col1% = > col1% + 1: IF col1% = 32 THEN flag1 = 2 IF flag1 = 2 THEN col1% = > col1% - 1: IF col1% = 16 THEN flag1 = 1 GET (1, 88)-(318, 112), c > PUT (2, 88), c, PSET LINE (1, 88)-(1, 112), col2% IF flag2 = 1 > THEN col2% = col2% + 1: IF col2% = 32 THEN flag2 = 2 IF flag2 = 2 > THEN col2% = col2% - 1: IF col2% = 16 THEN flag2 = 1 GET (2, > 113)-(319, 137), d PUT (1, 113), d, PSET LINE (319, 113)-(319, > 137), col3% IF flag3 = 1 THEN col3% = col3% + 1: IF col3% = 32 THEN > flag3 = 2 IF flag3 = 2 THEN col3% = col3% - 1: IF col3% = 16 THEN > flag3 = 1 GET (1, 138)-(318, 162), e PUT (2, 138), e, PSET > LINE (1, 138)-(1, 162), col4% IF flag4 = 1 THEN col4% = col4% + 1: > IF col4% = 32 THEN flag4 = 2 IF flag4 = 2 THEN col4% = col4% - 1: > IF col4% = 16 THEN flag4 = 1LOOP UNTIL LEN(INKEY$) > > Our users are more than capable of mastering this and more, but I think it > has to be presented incrementally. >
