You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
The last regular post was on Sorting and Grouping in Reports, and that followed a post about Sort & Filter in Forms. This time, we'll go into the new Report View, which provides interactive reports at view time and so improves on the old Print Preview view, which was static. The goal of this feature is to make the report an interactive part of the application in a way you never could before.
Report view is simply a new view on reports and a sample report from our Issues tracking app looks like this:
(Click image to enlarge)
By example, the same report looks like this in Print Preview:
You can see that the links on Cliff Jones and the Title field are gone in print preview, as they were formatted to show as links only on the screen through a new property. More on that later.
You've seen Layout View for Reports and Forms before.
And finally the same report in Design View:
The hyperlinks in the report above are actually not real links but are macro actions formatted to look like hyperlinks. To create the macro, you need to go to the Design View, and select the control, then set the Embedded Macro property. Embedded Macros are simply Access macros that are attached to the control, which makes it easier to move them around or update the document. In this example (and in the tracking apps) the macro is attached to the On Click event. You enter the macro editor by clicking on the builder at the right side of the edit next to the On Click event.
The macro is quite simple, just pulling up the relevant form and passing in the record ID. Here's the macro editor for the first line of the macro:
The second step ("Not IsNull") is the interesting one with the properties that determine which report to show for which record:
There is a new property called "Display as Hyperlink" that allows you to format the columns you put macros behind to look like links, so users know they can drill through them. Again, this is set through a property on the control from the Design View.
You can select to display only actual hyperlinks as a link (this is the legacy behavior and the default for the property). Alternately you can force non-hyperlinks to show as hyperlinks either all the time (both screen and print) or for the screen only. Formatting for the screen only allows you to show users what can be drilled through without having the hyperlink formatting appear on the printed reports.
In addition to the drill-through functionality illustrated above, users can filter and use Find functions on reports in Report View as well. Filters work just like they did in the Layout View. As we saw before, the quickest way to apply a filter is right-click on the column. Like in Layout View, we support a rich set of date filters:
Users can also apply filters from the Filter button on the ribbon:
And again, the filter is applied to whichever column is selected in the report. In this case, the user has selected a the status column and gets standard text filter functionality, with the ability to choose from the existing values or to click on "Text Filters" and create filters with clauses like Contains, Not Contains, and so on.
Find simply launches the standard Find dialog, and allows the user to search for text in the report.
The next post will be on AutoFormats in Access 2007, which have been updated in a big way. There is a range of much more subtle and more contemporary formats to choose from to quickly give your applications a polished look and feel. In addition, now's the time to start running through all the SharePoint functionality, so I'm working up a post on that as well. One of the Access PM's is back at TechEd showing Access 2007 features and covering working with SharePoint in detail. If you're at TechEd, I'd recommend Suraj's session. If not, I'll try to post a link to the video if I can find one.
Comments: (15) Collapse
Have you guys explored with the UI people any alternatives to the current report designer design view? It seems kind of dated in terms of look and feel. When is the last time it got a UI update? I wonder if maybe Visual Studio's Designer view might be a better fit. Or something completely new and cool.
>> Have you guys explored with the UI people any alternatives to the current report designer design view? We did some thinking about it but decided to really invest in layout view and enabling users to design objects while they see the data. Our usability tests indicate users are far more successful if they can see the impact of the change while they are designing the report. We would like to soften some of the lines and remove the 3-d stuff but that was prioritized lower against all the other visual improvements we have made through out the product.
I've never given big though about report - except when producing plain reports obvioulsy... To me it always was a pain to program them but it had two features I liked: one is you can control the look of a single rows, the other is the use of grouping. For the most part, to avoid coding stuff twice (1 report and 1 form to fill out) , I would design my form to be printable, essentially. This also means that I adopted the "net look" quite a while ago. It fits both printing and monitor mendium very well. I went so far as to put hyperlinks for buttons, catching the onClick event to set the hyperlinkaddress property to "" (to avoid the warning), start whatever I need to start and enable a 1ms timer that restores the hyperlink(s) on the form... Thankfully the display as hyperlink option we replace all that messy code. Back to reports, having more control of the data contained within - while in it - will be quite welcome. I don't specifically remember what stalled me when last trying to do such stuff in the previous versions though.
Very cool stuff! Does all this work in ADPs also? I am particularly curious about how you handle text filters when there may be thousands of possible checkboxes to choose from.
Drill through will be potentially a very useful and powerful feature. I say potential because I am curious to know: Q1A: Does it work with .mdb and ADP (as per AL's question) or just .accdb files? Q1B: SQL Server/ODBC linked tables (or just SharePoint tables)? Also, I am curious about the 'embedded macro' used in the drill-through example above. In particular: Q2A: Can we also use an Event Procedure (i.e. VBA code) to implement this as well? Q2B: What is the difference between an embedded macro and a normal macro? Thanks in advance,
Cyrus
>> how you handle text filters when there may be thousands of possible checkboxes to choose from? The individual values section is filled with a select distinct query which limits the list. Also, if you have other filters in the table we filter out values that wouldn't make sense given the current set of filters (if state = UT, we only show cities in UT). We don't display the individual values section if it is more than 1000 items. The control is far less useful with that many values... Q1A: Everything works in ADPs except the filtering stuff. It turns out reports calculate totals on the server and turning on filtering on the client in reports shows invalid aggregates. Q1B: All of this works in mdbs going against any ODBC data source including SQL Server. Q2A: You can use an event procedure. Q2B: Embedded macros are properties stored on the control where the entire macro is self contained. This opens up cool scenarios where you can copy and paste buttons that have embedded macros that are entirely self contained. Normal macros are objects external to the control. So, if you delete a control the embedded macro gets deleted where in a normal macro only the control gets deleted. Also, we perform name fixup on embedded macros.
I do like this hyperlink functionality and I'm certainly going to use it in my forms. But what I'd really like is a list control that doesn't show an arrow button to the right until the field gets focus. That's how the list functions in table view, but you can't place buttons/hyperlinks in this mode, so I had to stack a dozen of drop-down lists in a vertical row.... looks a bit weird.
Thanks for your clear and helpful answers Clint. The work being done with report layouts should remove a lot of drudgery from report writing and the drill-down aspect will open a lot of new possibilities. Thanks also for the clarification on embedded macros. I must admit to being curious why development time has been spent on this new macro feature. The reason is that most developers soon learn to avoid macros in event procedures (and elsewhere as much as possible) because of the maintenance issues. Can you shed some light on this for us? -Cyrus.
>> The work being done with report layouts should remove a lot of drudgery from report writing and the drill-down aspect will open a lot of new possibilities. I certianly have found this to be true. I can't stand creating reports in Acc 2003 now that I have used the 2007. >> I must admit to being curious why development time has been spent on this new macro feature. Good question. Back in the early days of Access VBA and macros were introduced at the same time. We found that there are many scenarios where users could be very successful "programming" using macros without having to understand code syntax. Macros target a broader audience of Access users that don't have the skills to drop into VBA and write code. Yet, these folks are very successful picking an action and setting a couple parameters. We have found that there are many cases where the user simply needs to run a couple import operations, export some data, or run an action query. Macros work really well for those scenarios as users can see in a linear model the process of execution. Another key goal for Access 2007 is building really great templates that run without code. You will notice our templates are great mini-applications that run in untrusted scenarios. Additionally, it is far easier for MS to localize macro parameters rather than code. When you think about templates and renaming objects--name fixup becomes really important for users that want to start with one of our templates and modify it to more closely reflect their business. In this case, it is far easier for us to perform name fixup operations on macros than try to fixup code. Think of the scenario of renaming the Contacts table to Employees in the Issues template. Many customers will want to do that--it would be really hard for us to do all the right things if all the logic was expressed in code. Finally, long term we believe in the declarative model for building applications. Access apps are quick to build because you can set a few properties and all the right things just happen without expressing a ton of data binding and valiation rules in code. We aren't there yet but we think there yet but we think there is great opportunity to build declariative programming tools where the application can run on the client and the server. If the logic is expressed in declaratively we have a far better chance of having it execute in both the client and server. There are lots of opportunities in this area moving forward.
Ooooh! Live reports!!! This is a great improvement. I went through a LOT of frustration before realizing that, for some bizarre reason, one could only see reports in Print Preview mode (without color and with page breaks in the worst possible spots!)
Why continuous Forms doesn't support SubForms (the DataSheet view supports them from the A '2k version)? Bye: Alexander P.S: The new Report Engine is amazing!
>> Finally, long term we believe in the declarative model for building applications. Should we take this to mean that VBA is to be replaced completely by macros in the long term? Are you able to give us some indication on the future of VBA? Thanks,
Cyrus.
>> Should we take this to mean that VBA is to be replaced completely by macros in the long term? No--macros don't do many of the things that can be done via VBA. When I say we believe in the declarative model for building apps, I'm more referring to setting properties that control the behavior of an application (properties like control source, edit list item form, validation rule, new split view stuff, etc). We will continue to focus on building a platform that allows a developer to build applications without writing code but we acknowledge that there are many scenarios where code is required to property model the business scenario. The new Northwind is a great example of a more complicated application that mixes property settings, macros, and code for the heavy lifting scenarios. In a couple months there will be a white paper that will talk about how you can use managed code insider your Access applications. There are some changes to the PIA model that made managed code more interesting than it has been in the past. I don't have any new information or comments on the future of VBA.
Clint, you mention the new Northwind databse Please tell me that it will finally have use decent naming comventions! PLEASE!!!! as in, something that resembles the Leszynski/Reddick Guidelines that pretty much all Access developer use except whoever built Northwind
Does access 2007 support data access with ado.net ?
Comments: (loading) Collapse