The Dbase Reports Book: Creating Reports and Labels in Dbase Plus

Contents

About the Author

Introduction

Acknowledgments and Thanks

Part I The Basics

Chapter 1 Preparing to Follow Along With the Book / Tutorial

Chapter 2 Report Basics

Chapter 3 Custom Reports and Custom Controls

Chapter 4 The Report Event Model

Chapter 5 Report Layout

Chapter 6 Calculated and Lookup Fields

Chapter 7 Landscape Reports

Chapter 8 Labels

Chapter 9 Using a Report Viewer

Part II Multiple Tables, Groups and Summary Calculations

Chapter 10 Multiple Tables, and Grouped Reports

Chapter 11 Counting, Accumulating and Running Totals

Part III Modify Report Appearance

Chapter 12 Hiding Report Elements

Chapter 13 Setting Page Breaks

Chapter 14 Enhancing Reports

Part 4 Advanced Report Techniques

Chapter 15 Multiple Columns

Chapter 16 Multiple PageTemplates

Chapter 17 The reportGroup headerBand and footerBand

Chapter 18 Grouping Data on Partial or Multiple Fields

Chapter 19 Cross-Tab Reports

Chapter 20 Programmatic Control of Reports

Chapter 21 Writing Data From Reports

Chapter 22 Writing to HTML

Chapter 23 Miscellaneous Report Topics

Appendix

About the Author

Ken Mayer has used dBASE both as a hobbyist and as a professional coder for 22 years, starting with dBASE III+ and working up to dBASE PLUS.

Ken worked for Borland, Intl. for two years as a Senior Quality Assurance Engineer on the Intrabuilder and dBASE products (Intrabuilder 1.0, Visual dBASE 7.0 and 7.01), and also worked for five years for dBASE Inc. as a Senior Quality Assurance Engineer, also working on dBASE (Visual dBASE 7.5, dB2K and dBASE PLUS, as well as dQuery). Ken was a contributing editor to dBASE Advisor magazine for the one and a half years or so it was in publication.

He served on Borland’s TeamB (volunteer technical support) when Borland owned dBASE, and has helped many in the dBASE developer community. At this time he is a member of the dBVIPS for dataBased Intelligence, Inc., doing the same things he did with TeamB. He authored a good portion of the Knowledgebase articles that ship with dBASE PLUS, and authored the original dBASE PLUS tutorial. Ken is the author of The dBASE Book, the book that was released in late 2005 aimed at helping a developer learn to build applications in dBASE.

Ken has also been the librarian of a freeware library of code made available to all dBASE developers called the dBASE Users’ Function Library Project (dUFLP) for 15 years or more. He has been a speaker at Borland and other conferences on dBASE, speaking about coding techniques.

In the three years after being laid off from dBASE, Inc., Ken has been attempting to make a living as an independent developer, as well as writing this book (and his first book The dBASE Book).

When not working or trying to find work, Ken is very active in the Society for Creative Anachronism, Inc. (http://www.sca.org), and enjoys movies, games, and reading.

Ken lives in Walnut Creek, CA with his wife Carolyn Eaton and their two cats Rebo and Zootie (named after a pair of comedians from the science fiction TV show Babylon 5).

(Photograph by Tim Converse, 2001)

Introduction

dBASE Plus has a fairly complex and robust Reporting Engine, and with that a Report Designer. Between the two of these tools, a developer can create a lot of really good looking reports and labels.

However, in order to get the data into a report, the developer needs to understand how the engine works, and how the tools work, and try to find the best way of using their time. As many developers have found, the Report Designer can be a bit daunting and sometimes confusing tool to use.

This book is an attempt at helping a developer come up with some good habits when designing reports (using custom reports and classes). More than The dBASE Book, this book is a tutorial-it is meant to be used as a tutorial, meaning that many of the exercises in later chapters rely on the reader having completed the exercises in earlier chapters. To that end, it behooves you to take the time to start at the beginning, even if some of the early exercises seem awfully basic, so that when you do get to material you would like to learn more about, you won’t get frustrated because you don’t have some file or report to build on.

Ultimately the goal is for the reader to be more comfortable with designing and creating reports that present the data in an application in a clear and meaningful way.

Acknowledgments and Thanks

I, Ken Mayer, would like to thank the people who have helped make this book possible. While I cannot thank by name every single person who may have contributed indirectly to the writing of this book, I would like to thank the following specifically.

The dBASE Community

Thanks to the dBASE community for the encouragement which helped me to decide that writing this book was a good idea. I cannot possibly name everyone who sent me Please do this! messages, either in private email or in the newsgroups, but my thanks to you all.

In addition, when I posted messages asking for ideas or specific information in the dBASE newsgroups many people came forward with their thoughts, advice, and assistance, sometimes providing code samples. Some of these folk are mentioned by name in the book, where I have referenced posts by them in the dBASE newsgroups, code I am using of theirs, etc. Again, thanks to you all.

Quite helpful were the attempts to explain Cross-Tab reports. Between the many messages I printed, and the looking I did on the internet, I found some good explanations that helped me understand this concept, and write a chapter that I hope will help you understand it.

Contributors

Unlike my previous book (The dBASE Book), I really had one major contributor to this one: Michael Nuwer, who gave me permission to use examples and materials, and even text describing how and why to do things from his dBASE Reports Tutorial available from his website. Michael’s approach was very different from mine in the overall scheme of things, but his tutorial helped me find ways of explaining concepts, and his examples were often used as a starting point for my own.

In addition, Jean-Pierre Martel and Michael Nuwer helped me with the initial layout of the book, where to place chapters in a logical sequence, and general design.

Editors

I wish to thank Frank J. Polan and Jean-Pierre Martel for helping make sure everything in this book made sense and that the code examples actually worked. Frank stepped up to the plate when Michael realized that his current job just wasn’t going to give him time to edit the book as well as all of his other contributions, and has been extremely helpful, walking through each exercise and testing each step, pointing out possible pitfalls, and more. J.P. is always a helpful person as well, any who have ever worked with him know what a gentleman he is, and how helpful he can be.

In addition to the above, Jean-Pierre created the cover for this book! While this book uses the layout that J.P. did for my first book, when I mentioned some concerns that readers of the first book had, he updated the template for me without blinking an eye. Once again, he’s come through with all the grace and style we have come to expect of him.

My Wife

Last, but far from the least, I need to thank my wife of thirteen years, Carolyn Eaton, for being supportive of my insanity during this time. It was a tough time financially. However, she supported this effort despite the difficulties with nary a complaint. All the time I worked on this (and my previous) book, I was also trying to earn a living as an independent developer and not making a lot of money in the process. With nary a complaint, she was always supportive-how can you ask for more? There are simply not enough words to thank her ... except to say I love you!

Part I

The Basics

The first part of this book is aimed at getting you set up to follow along with the exercises; and then to get you familiar with the Report Designer, Report Engine, and tools for working with Reports in dBASE. This includes several chapters where you are creating custom reports and classes and then reports that use those, to work with the software. Later parts of the book get into more advanced techniques, but Part I is aimed at the basic aspects of designing, creating and working with reports in dBASE Plus.

Chapter 1

Preparing to Follow Along

With the Book / Tutorial

Setting Up For the Exercises In This Book

The purpose of this book is to make report development easier. At the beginning we’ll take time to create the resources needed to fully take advantage of the power of dBASE’s Report Engine.

Custom Reports and Controls

Throughout this book we are going to use custom reports and custom report controls some of which are included in the dBASE Users’ Function Library Project (dUFLP). If you have not downloaded this free library of code, you should take advantage of it. In addition, we will take a look at Preview.wfm in the dUFLP in a later chapter of the book.

The dBASE Users’ Function Library Project

To that end, there are a few things you will need to do. The first is to download the dBASE Users’ Function Library Project (dUFLP), which can be gotten at (note that the URL is case-sensitive and dUFLP needs to be typed as shown):

http://www.goldenstag.net/dbase#dUFLP

This is a freeware library of code that is probably the largest open-source project for dBASE currently out there. Details on this can be found both on the website, and also in the library. You should download the current version.

Using Winzip™ or some other unzip software, unzip to a folder such as C:\dUFLP.

Start dBASE, and once you are in dBASE, use the file folder button at the top of the Navigator window to navigate to the folder you unzipped the dUFLP library into. Once you have done that, run the following two programs:

SetupSourceAlias.prg

This will, when done, exit dBASE and restart it (depending on which version of the dUFLP, the message that displays may be misleading, in that it may tell you to exit and restart dBASE, when you don’t need to-the one issue here is that dBASE will not restart in the dUFLP folder, and you’ll need to change folders back to C:\dUFLP or whatever path you used...) When it restarts, run:

ComponentPalleteUpdate.prg

This program will set up information in a special table to help us organize the visual components in the dUFLP more easily, making it possible to find things easier when we get to that point.

If you already have the dUFLP installed, you may want to check and see if you have the most current version, as this code is updated fairly often (depending on factors such as time available to the librarian, and the amount of updates/changes/new code donated to the library, and in some cases the dBASE R&D Team finishing a new release of the software).

Folders to Place Your Work In

I will also suggest that you set up a folder to place your exercises in, such as:

C:\dBASEReports

In that folder, you should create another, called:

C:\dBASEReports\Tables

This is where the tables for the sample reports should be placed. We will discuss the tables shortly.

Tables

Next we will need to create some tables. Actually, we won’t create them but simply use the ones that Michael Nuwer has built in his excellent tutorials. There are some tables that will be used that are not from Michael’s tutorial, which should be included in the files described here. These can be downloaded from my website at:

http://www.goldenstag.net/dbase/dBASEReportsBook.htm

Use Winzip™ or some other software to unzip the tables to the folder C:\dBASEReports\Tables.

Some of the data was provided to Michael Nuwer by Paul White, and I have to thank both of them for making them available. There are three tables:

•   Dogs-contains data for something like 7,000 animals, including their registration numbers, names and sex, and more.

•   Litters-contains about 2,700 litters

•   Dams-contains data for about 350 female dogs.

Other data will be provided for specific projects, and will be contained in the same .zip file.

Database Alias

Next you need to create a database alias that points to the folder that the tables are in.

To do this you will need to start the Borland Database Engine (BDE) Administrator. This was installed when you installed dBASE Plus, and an icon for it should be in the dBASE Plus folder. Follow along:

Step 1: Create a new alias

This can be done by making sure first that you have the BDE Administrator pointing at the right part of the application, specifically by clicking on the tab Databases if it does not currently have focus. Once this tab has focus:

Ctrl+N or

Object menu, New ...

You will see a dialog that looks like:

Figure 1.1: New Database Alias

Click OK.

Step 2: Change the name of the alias

The default name for an alias is STANDARD1. Click on this so that it has focus and change the name to dBASE Reports. Press the enter key.

Figure 1.2: New Database Alias

Step 3: Set the path

The alias now exists, with the name we gave it, but we have to tell the Administrator the path to where the tables are. Click on the entry field for Path and then on the button ... that appears. This will bring up a standard dialog for finding a folder. Find the folder you created called C:\dBASEReports, double-click on that, and you should see the folder under it named Tables. Double click on that so it is open, and click OK.

Figure 1.3: New Database Alias, Setting the Path

This will place that path into the BDE Administrator where you need it to be.

Figure 1.4: New Database Alias Completed

You may also want to set the default driver to dBASE, but I have found this doesn’t seem to make much difference.

Save your new alias with Ctrl+A (or use the Object menu, and Apply), and close the BDE Administrator.

Data Module

We are going to create a basic datamodule for the reports used in this book for starters. Note that you are not required to create a datamodule to create reports-the report designer allows you to use tables without the use of a datamodule. The primary advantage to using a datamodule is that once you have your data structure designed (parent/child table relationships and so on), you have code that you do not have to recreate each time you need to do something new, whether it be a new form or a new report-if the datamodule has the data design you need, why do it again?

Start dBASE up if you haven’t. Look at the Navigator window. It will tell you in the top part where you are pointing on your computer (this is important-it tells you where any new files will be saved, and more). If you are not currently pointing to the folder you created earlier for this book (C:\dBASEReports), please do so now. This can be done by clicking on the Folder button to the far right of the Look in: part of the Navigator. This will bring up a dialog box that allows you to select a folder:

Figure 1.5: Choose Directory Dialog

Now that we know we are pointing to the correct folder, let’s create our first datamodule.

To do this, you will need to start dQuery, which is the datamodule designer in dBASE. To do this, start dBASE, and with the Navigator Window open, click on the Datamodules tab. You should see:

Figure 1.6: dBASE Plus Navigator, with Data Modules Tab Selected

The first Untitled icon is what we will select. Double-click on this, and dQuery will start up. If you are not familiar with it, dQuery is a complex tool that can be used for many purposes-the primary purpose is to create a datamodule. This is a nice drag and drop interface, and we will rely heavily on that ability.

Figure 1.7: dQuery Desktop

On the left of the dQuery screen is a list of database aliases, like the one created earlier. To use it, simply double-click on it-find dBASEReports in the list on the left, and double-click it. This will place a database object on the design surface of dQuery. In addition you should now see the three tables that we placed in that folder earlier.

Figure 1.8: dQuery with Database Selected

Find the table Dams and drag it to the design surface. Next do the same for the Dogs table. We will leave Litters where it is for now, but we will need to use it for some later reports.

Figure 1.9: With Both Tables Selected

Next we want to set a link between the two tables. The linking fields may not be really apparent, but to create a link from the DAMS1 table as the parent table, to the DOGS1 table as the child table, click on the DAMS1 table and then click on the field DAM, and drag (hold the mouse down and move the cursor) to the DOGS1 table, and then let the mouse button up. The Parent-Child Wizard for dQuery will appear. Click the Indexed Link tab, and select the index Dam-this will ensure that the data is sorted properly for this link.

Figure 1.10: dQuery Parent-Child Wizard

Click OK on the Wizard, and it will close. You should see the link is now set-this is apparent by the arrow on the dQuery screen. The link should allow us to view all of the offspring of a single dam.

Figure 1.11: dQuery Tables Linked

One last thing-to get the Dams table to sort by name, we should set the index for that. Click on the DAMS1 table to give it focus if it doesn’t already have focus, right click with the mouse, and select Set Order. Make sure NAME is selected, and click the Set Order button. If you look at the grid, you should see names starting with the letter A ...

Save this by pressing Ctrl+S and give a name: DamsParentChild.dmd.

NOTE: If pressing Ctrl+S saves this as Untitled1.dmd, we can fix it-exit dQuery as mentioned below, and in the Command Window type:

rename Untitledi.dmd to DamsParentChild.dmd

and if you see Untitled1.dmo appear in the Navigator, click on it once and right click, select Delete, etc. Once done, open the file in the Source Code Editor, and change this line:

class UntitledlDATAMODULE of DATAMODULE

so that it reads:

class DamsParentChildDATAMODULE of DATAMODULE

and save the file (Ctrl+W), then exit the Source Code Editor

We will use this in many places to create reports for this book.

You can now exit dQuery.

As noted earlier it is not really required to use a datamodule for your reports, and some of the examples in this book will not be using one, but it is a good practice to get into, as you can save yourself a lot of work with datamodules.

NOTE:

dQuery automatically sets a property of the _app object in dBASE, which works great for dQuery, but can cause problems. When you exit dQuery, it does not reset this property.

If you find your reports not working properly after you have opened a datamodule, or used dQuery for any reason, you should try typing the following in the Command Window:

_app.detailNavigationOverride := 0

This will force this setting to the default (dQuery sets it to 2, which is what causes problems for many reports, especially grouped and multi-table reports).

A Few Caveats

The Report Designer has some issues, or bugs, some of which the dataBased Intelligence R&D team know about, as they’ve been submitted as bugs. These are some you should be aware of:

Crash While Saving A Report

The Report Designer in dBASE sometimes crashes for no apparent reason when you have been working in it for awhile. I have found that this generally occurs when I save a report, sometimes with save and exit (Ctrl+W). What is good is that while dBASE will shut down, the changes that were made appear to be saved. I have yet to have a situation where I had to start over. The best thing to do when this happens is just to start dBASE up again, and pick up where you left off.

While this sounds like it is frustrating, and it is, what it means is that you can continue working, and seldom lose your work. Of course, you should back up your work periodically anyway, and some developers take the time to back up a file each time they make any changes. This may seem excessive, but it is entirely your call.

Long Report Filenames

When saving reports in the Report Designer, keep in mind the length of the filename, because dBASE will attempt to create a similar object reference name for the report. For example, if you save a report as MyReport.rep, dBASE should create the object as MYREPORTREPORT (the second report is added by the designer). The problem that occurs is that object names are limited to 32 characters. If you save a report with a long name, the designer will attempt to add the word REPORT to the end of it, and this may end up longer than the maximum 32 character limit for object names. The designer will simply truncate the name of the object! It’s a good idea to not use extremely long filenames.

Cannot Select a Text Control

Sometimes when you place a text control onto the detailBand, for some reason you cannot select it to move it, all you can do is change the text of the control itself. This seems to happen with custom controls, and is hard to reproduce. However, in the process of writing this book I have come across it several times. While I do not know what the cause of the problem is or how to avoid it, I can tell you how to set things right without exiting the Report Designer and reopening the report back in the designer (which is another way to do solve this issue).

When you have a text control that you cannot select, what I have found seems to solve the problem is to find the control in the Inspector (using the combobox)-it will be named Text1 or something like that by default (if a custom control it will be something like DataText1 or whatever the name of the class is), and select it. Once it’s selected in the Inspector’s combobox, click on the detailBand or some other object. The control in question may shift once you do that, but you should now be able to click on the control and move it, and work with it as normal.

Coding Reports

While you can create a report using code like:

r = new report()

r.p = new pageTemplate( r )

and so on, this is hard to work with, hard to read, and hard to determine exactly where your text controls (and any other objects on the report) will display. It is easier to work with the Report Designer, unless you are doing something fairly simple.

Folders for The Tutorial Parts of the Book

You may want to consider creating individual folders for the different chapters of the book. This would mean creating folders inside the C:\dBASE Reports folder for each chapter, such as:

C:\dBASE Reports\Chapter 1

C:\dBASE Reports\Chapter 2

And so on. This way we can keep the different exercises separate, and if necessary we can copy files to be modified or used for different projects. This would be done the same way you created the C:\dBASE Reports folder in the first place, using Windows Explorer.

Summary

If you have followed along so far, you should be set up and ready to do the exercises in this book. The whole point of the exercises to this point have been to get everything set up so that you are ready to work through the walk-through parts of this book.

Chapter 2

Report Basics

If you have read The dBASE Book, this chapter will be very familiar to you, as it is taken from that book (Chapter 18), modified to use the sample tables provided by Michael Nuwer for later reports and shortened as some of this is covered in later chapters. This chapter is provided as an overview of the Report Designer, to get you familiar with the Design surface.

In order to work with the Report Designer and the dBASE report engine, you need to understand the report object and the objects that work specifically with reports.

Report Objects

Some of the following is based loosely on information in the Language Reference, and is here to help understand what is going on in this powerful but sometimes confusing tool.

Like a form, a report is really a container for a bunch of objects, with some code of its own, since the report is an object with properties and methods (also just like a form). The report object hierarchy works something like the following:

• Report Object-which can contain:

Data Objects-these give access to data in tables:

□ Query objects

□ Database objects

□ Session objects

□ Data Modules

□ SQL Files

Data Objects work much like they do on forms, except that a report does not have a primary rowset like a form does (you cannot refer to form.rowset).

■ Report Layout Objects-these determine the appearance of the page and where data is output (or streamed):

□ PageTemplate

□ StreamFrame

A report contains at least one pageTemplate, and each pageTemplate contains at least one streamFrame.

■ Data stream objects-these read and organize the data from a rowset and stream it out to the report’s streamFrame object(s):

□ StreamSource

□ Band (detailBand, group headerBand, group footerBand)

□ Group

Each streamSource may have a detailBand, a group headerBand and/or a group footerBand. Each of these are subclassed from the Band object, and have all the properties of the band object. The Report Object itself has a group called the report Group, which has a headerBand and a footer Band-this will be discussed later in this chapter.

□ Visual Components-these are used to display the report’s data:

□ Text

□ Line

□ Image

□ Rectangle

□ Shape

□ ActiveX

□ Report Viewer

□ Container (not really visual, but used to contain other objects-note, however that containers do not work for band objects. The reason is that a container is a window object, and you cannot repeat window objects one for each detailBand (or other band object) like you can a text control-this information is straight from the original Borland development team.)

The primary method of displaying information in a report is through text objects.

How a Report is Rendered

A report gets rendered (or generated) by calling the report’s render() method. The sequence of this generation is along these lines:

•   The report’s first Page Template property is looked at to determine which pageTemplate (if there are multiple) is the first to be rendered (or generated).

•   In the process of rendering the pageTemplate, all controls that are defined for that pageTemplate are rendered, in the order they are defined in the source code (this is also called the z-order). The important thing to note in this process is that it doesn’t matter what order these controls appear on the report surface, but the order in which these controls appear in the source code.

•   The streamSource is controlled by the data-your query (or queries), or more specifically, the rowset generated by the query. Most reports have only one streamSource, and the rowset for that streamSource controls the report.

•   The streamSource controls how a streamFrame is rendered, and for every row in the rowset referred to by the streamSource a detailBand is rendered inside the streamFrame.

•   When a streamFrame is filled up, if there are still more rows to be rendered, these will be rendered in other stream Frames on the same pageTemplate-if any exist. (What this means is that you can have multiple stream Frames on a page-which is how labels are generated, as well as columnar reports. This is a complex topic and will be covered in depth in later chapters of this book.)

•   If the current streamFrame is the last one on the pageTemplate (or the only one), and there are still more rows in the rowset to be rendered, then the pageTemplate looks at its next Page Template property to determine where to go next. At that point a new pageTemplate gets scheduled, and the report’s on Page event fires.

•   The report will continue rendering until all rows in the rowset have been rendered.

Figure 2.1: The render sequence for a report in flow-chart form.

Based on a Chart by Charles Overbeck.

The Report Designer

When you are using the Report Designer, you will see a very busy screen, and this can be a bit confusing at first-although if you’ve used the Form Designer you may be used to it, to an extent.

There are the palettes you’ve used in the Form Designer:

•   The Inspector-used to inspect and change properties and events;

•   The Component Palette-used to place specific controls onto your report;

•   The Field Palette-one method of placing fields (columns from the rowset(s)) onto the report;

•   The Format Toolbar-used to insert HTML formatting into your text controls.

In addition, there is the Report Designer itself-this actually has two parts, although the default is to show just the report. These are called panes (it’s a window)-the pane on the left is called the Group Pane, and the pane on the right is the Report Pane. When you first open the report designer, there is a vertical bar on the left of the Report pane-if you drag this bar to the right, you will see the Group Pane.

The Group Pane shows the hierarchy of objects in the report down to the bands (it does not show controls). The Report Pane shows the report appearance with the corresponding structures shown in the Group Pane-this uses live data. The Report Pane is where you will be working. The Group Pane has some use to show you what groups and bands you are working with, but it is not interactive, and is not where you will do most of your work.

Figure 2.2: The Report Designer as it appears in dBASE PLUS, release 2.61, with the Group pane showing

Metrics

The default metrics for the report designer are twips, there are 1440 twips to the inch (a twip is a twentieth of a point; there are 72 points per inch). This, for people used to thinking in inches, (or centimeters, or ...) can be a bit mind-boggling, and trying to determine how wide a page is, or how far from the left margin you wish to set an object, can be difficult at best. However, like the Form Designer, you can change the metrics for your reports.

If you think in inches, then by all means, change the metrics for your reports to inches. The metric property is found in the Inspector for the form-if you are designing a report, the form is the report-and if you click on it, you will see a combobox with several options: Chars; Twips (default); Points; Inches; Centimeters; Millimeters; Pixels. Most people don’t think too clearly in anything but Inches, Centimeters or perhaps Millimeters-so you may want to get used to setting the metric property as soon as you start designing a report (just as with the Form Designer and forms, you could use a custom report that set this and any other properties you commonly change from the defaults for you-we will discuss this in the next chapter). Throughout this chapter, the examples use inches as the metric setting.

Setting Up or Customizing The Report Designer

The Report Designer can be customized and modified to allow for a lot of different options. In Figure 2, for example, you see shown the Component Palette, the Field Palette and the Inspector, as well as the design surface itself.

We need to take a look at all of this, and how to modify it for use. In later chapters of the book we may come back and modify some of the settings we are looking at here, but for now let us take a look, and try to ensure that your environment matches the one being used for the book.

One of the first things is to see if all three of the tool windows shown in Figure 2 are appearing on the screen. If they are not, try the following:

•   Right click on the Design Surface

•   Look to see if there is a checkmark by each of these (Inspector, Component Palette, Field Palette).

■ If the checkmark is not by the tool window title, click on the option. This should open the specific tool window.

■ If the checkmark is by the tool window title in the popup, then it is open, but it is most likely hidden behind another window. In that case click on the Windows menu at the top of the screen, and you