WYSIWYG Form Authoring

Published 14 April 06 01:34 PM

Last week we looked at the WYSIWYG report authoring tools, this week we'll take a look at the similar forms designer.  Since forms generally don't repeat like reports do this designer looks more like the old form authoring tools than the report designer did, but it is still noticeably quicker and easier to use. 

WYSIWYG Form Authoring

Like the report designer, the core of the new forms authoring tools is the ability to see live data at design time.  This makes it easier to tell what the user's experience of the form will be.  In addition, there are some new concepts, also shared with reports, that make control layout easier.  We'll go into this below.  To get started with the new forms tools, though, the easiest way is to use Quick Create, just like for reports.  The user simply selects the data source in the nav pane, then goes to the Create tab and selects "Form":

This creates a basic form and displays it in the design using "Layout View" or the new WYSIWYG design view.  Like reports, the new form shows all of the fields in the underlying data.

(Click image to enlarge)

Again, just like with reports, it is simple for the user to select and delete unwanted fields from the form.  In this case the user deletes the control showing the ID column, since this is created by Access's AutoNumber functionality.

(Click image to enlarge)

Again, much like in reports, fields can be easily moved by drag and drop.  Here the user selects a field and drags it up in the form.  She sees an I-bar showing where it will land when she drops it.

(Click image to enlarge)

After she drops the field, the other controls are moved down and it is inserted into the new space.

Quick created forms have a header area at the top, and it is easy for the user to customize this.  She can simply edit the title by clicking and typing, may replace the image, or can easily add a date / time stamp.  In this case, she adds the date by clicking on the ribbon.

Access displays a dialog allowing the user to select a format for the date.

And the date is inserted in the form's header (note that I shrunk the header horizontally so it would display - it will be right aligned on the form).

Working with Layouts

Access 12 has introduced a new control-grouping concept called "layouts" that provide the control flow shown above.  When you move controls around then can snap into position and the other controls can reflow because the controls are all aware of their relationship to one another, and that is done through Layouts.  In the image above, you can see the selector widget to the upper left of the word Title - this allows you to select the layout and to see which controls are included in that layout.  Layouts make common functionality like more and resize much easier, but since they govern where controls may be moved, they may prevent you from creating certain forms.  To make sure that you get the benefits of layout but don't lose flexibility, we've made it easy to edit or remove layouts as needed.  To take a specific control and make it float, all that you need to do is select it and choose "Remove" from the "Layouts" chunk on the "Layout" ribbon.

(Click image to enlarge)

This leaves the control on the form, but simply removes it from the layout.  It can then be dragged around and formatted as desired.  In this case, the user drags it next to the current column of controls:

(Click image to enlarge)

Then grows it so that it fills the whole length of the form.

(Click image to enlarge)

Groups of controls can be moved to a new layout in one step as well.  This makes it easy to take a long one-column form for example and make it into a wider two-column form.  To do this, all that you needs to do is select the controls from the first layout and select "Stacked" from the Layouts ribbon. 

(Click image to enlarge)

This creates a new layout and moves the controls into it:

That layout can be easily dragged around by clicking on the selector in the upper left corner.  In this case, it is being moved from the bottom of the long form to the empty space on the right-hand side.

(Click image to enlarge)

Once the controls are in the new layout, they behave just like they did in the old one, and can easily be moved, resized, and so on.  In the example below, the user is resizing the comments field to even up the column lengths. 

And the final form looks like this:

(Click image to enlarge)

Split Forms

Access 12 has added split forms as a new form type.  Split forms combine a datasheet, for bulk data viewing & entry with a single-item form for ease data manipulation.  Split forms can be created from the Create ribbon in a single click, and look like this:

(Click image to enlarge)

Editing a split form is just like editing a regular form or datasheet, and it is simple to drag & drop controls around inside either the mail layout:

(Click image to enlarge)

Or between the two layouts (in this case a second layout was automatically created to provide a two-column form and to prevent scrolling in the single-item form.

(Click image to enlarge)

Here is the Comments field after being dropped into the righ-hand column.

(Click image to enlarge)

Multiple Item Forms

Multi-item forms can be created in one click as well, and also use Layouts for control positioning.  Building a multi-item form creates a datasheet that can be edited, and with a "new item" row at the bottom that can be used to add new records.

(Click image to enlarge)

Of course it is simple to resize the columns in a multi-item form by dragging:

And is easy to move columns around, again simply by selecting them and dragging:

The I-bar at the left shows where the column will be dropped:

And of course all the other columns are moved to the right to make space after the column is dropped in.

Datasheet Forms

The "More" button in the "Forms" chunk on the Create ribbon provides the ability to create datasheets, modal dialogs, and to launch the Form Wizard that is familiar from earlier versions of Access. 

Selecting "Datasheet" creates a simple grid form, similar in concept to the Multi Item form above, but closer in appearance to Excel.  Again, there is a "new item" row at the bottom for adding data.

(Click image to enlarge)

Rich Text In Access Forms

Access 12 now provides a rich text control, and allows users to both display and edit rich text at runtime.  Rich text support can be turned on through the property sheet or rich text fields can be added to a form through the Add Field task pane. 

At runtime, the user can format text, either using the "floaty" (I'm sure this has another name, but I don't know what it is!) or by using the font formatting controls in the Access ribbons.

(Click image to enlarge)

Next Week

Next, we'll start a pass through the Sorting, Filtering, and Grouping functionality in Access 12. 

Comments

# Doug Hills said on April 14, 2006 5:34 PM:
The 'floatie' is really called a 'mini-bar'. Cool, eh?
# clintc said on April 14, 2006 9:49 PM:
Just to add to Erik's great description--we will be updating the form visuals (icons and colors) to the forms and reports that Erik showed. It won't happen in Beta 2 but definitely before the RTM. I expect they will look much fresher than the current visuals. The product is feeling pretty good these days.
# Ryan McMinn said on April 15, 2006 11:55 AM:
I got a sneak peek of many new Access 12 features in Las Vegas at Advisor Summit.

Since I spend a lot of my time making Access interfaces look great, the new feature set is amazing. Things like stacking and fluid layout completely reinvent the Access interface tool. These tools also make datasheet view a viable user interface option which is great because users love the functionality that views offers.

BIG NOTE: I heard a rumor that MS might be capping the Office 12 BETA 2 at 1 million users so read the last post and go sign up now.

Ryan McMinn
M7 Database Services
http://www.m7database.com
# kiwibruce said on April 15, 2006 3:55 PM:
Erik, Great work so far, as a developer I can't wait to get my hands on this next version. At last a a new version of Access with some worthwhile new features!  I know some developers have commented on how so many of these new features are user specific, and I agree in some respects, But I do think there will be enough to keep me the developer happy.
Now on to Forms, I am glad there is a easy to use built in RTF control. I have had to use 3rd party ones until now. BUT... my question is, Is there a bound Tree-view control in Access 12? As a developer, This is the one control I really want to add to my apps to improve navigation and functionality but the current RTF (MSComctlLib)  is next to useless! as it requires way too much coding to be useful. I can't be bothered writing pages and pages of code every time just to get this one control to work! so has this item been addressed in Access 12?
Oh one more question, can you address in one of your posts how Run-time will work and what tools will be used and how developers will ship Access 12 run-times?

Keep up the good work.  Thanks again for this Blog.

Bruce Jonson
# Erik Rucker said on April 17, 2006 6:04 PM:
Mini-bar, eh?  That's fantastic!

Glad to hear the RTF control will be handy.  I'm sorry but we don't have a new tree-view control this time.  It is definitely something that would be nice to have and we'll consider it (again) for the future.  Just couldn't get it in this time.

I promise another post on the run-time coming up.

Thanks, all.
# AL said on April 17, 2006 8:34 PM:
The new features you have presented look really nice, but I have some questions about the details.  (My frame of reference is Ac2002, so perhaps some of these things have already been addressed in Ac2003.)

Will it be possible (even using VBA) to resize a single column (from end-user input) in the form layout, and have all the other columns resize while in form (not design) view?  For example, will I be able to call into the form object/API and request that the layout be refreshed to accomodate a new column width?  Or will I still need to do the resizing manually (in VBA) when in form view?

Have there been any changes to the (client/server) FilterByForm views?

Will alternate row colors apply to continuous forms?  

Is it still impossible to programmatically change the formatting of a single field inside a single row of a continuous form?  

Has there been any improvement in the speed at which cond. formatting is applied to a datasheet or form.  (Currently, it's quite slow.)

Will it be possible to apply cond. formatting to the background of a detail section? Or to every control in a row at once?  Or to highlight jsut the active row in a cont. form?

Many of us have been asking for more than 3 conditional statements, or to make the formatting more generalized.  For example, applying a color saturation that is proportional to a percent value in a control.  Will there be any way to accomplish these feats, even if we have to resort to API calls?  I know you have shown us that Excel has added these features in a really fantastic way, but haven't there been any improvements at all in Access?  Even if you just exposed the Window handles (hWnd property for a detail row or control) so we could manually paint these areas without excessive API acrobatics...that would be a huge help.

Will we be able to alter (e.g. size and color) the appearance of checkboxes and option boxes? - the current ones are a bit too small for some users with disabilities.  I would love to have a few checkbox images/sizes/colors to choose from.

Will hyperlinks work and format correctly (i.e. will they look and behave like clickable hotspots) in datasheet view?

Will we be able to display rtf in datasheet view?  Will images and other standard rtf fields display correctly in the new rtf control?

Will the rtf control support the latest revision of the rtf standard - i.e. give us COM access to the underlying control so we can use the TOM (text object model), API calls, etc for advanced rtf features?  IOW please, please find some way to expose the underlying COM control for advanced users needing hidden or protected text, embedded images/objects, mouse-over-word coordinates, etc!  I am using all of these features in the current MS RTF control, so I sure hope the new control is fully backwards-compatable with standard Microsoft RTF control that was previously recommended by the Access group.

# Erik Rucker said on April 18, 2006 6:53 PM:
Wow, that was a long question!  I've copied parts of your questions below and interspersed answers between the paragraphs after the ">>> " characters.
__________________
Will it be possible (even using VBA) to resize a single column (from end-user input) in the form layout, and have all the other columns resize while in form (not design) view?  For example, will I be able to call into the form object/API and request that the layout be refreshed to accomodate a new column width?  Or will I still need to do the resizing manually (in VBA) when in form view?

>>> Yes, you can certainly programmatically resize columns in a layout and have other columns adjust appropriately.  When controls which are a part of a layout are sized through code in layout view or design view, the Access layout engine will kick in and fix up the other controls in the layout.  

Have there been any changes to the (client/server) FilterByForm views?

>>> The filter by form interface is still the same as in Access 2003, with the inclusion of the ability to filter complex data fields.

Will alternate row colors apply to continuous forms?  
>>> Yes, alternate row color works in datasheets, continuous forms, and reports.  It actually works on all repeated sections as well, meaning you can have group header/footer sections alternate differently from the detail section in reports.

Is it still impossible to programmatically change the formatting of a single field inside a single row of a continuous form?  
>>> Conditional formatting continues to enable this scenario as it does for Access 2003.  Making property changes to controls in a form programmatically will still affect all instances of that control which are rendered on screen, as it does in Access 2003.  In reports you can make changes in the Format event which are specific to the single instance of that control.  Now that report browse is available, this may be a good alternative for your interactive multi-record user interfaces.

Has there been any improvement in the speed at which cond. formatting is applied to a datasheet or form.  (Currently, it's quite slow.)
>>> We haven’t done anything in Access 2007 specifically targeted at improving conditional formatting.  There are several reasons why conditional formatting might appear slow.  Conditional formatting happens when the application is idle, as do other values calculated inside a form, report, or form in datasheet.  If you have a lot of this type of calculation, where a textbox on a form in datasheet view is calculating values from other fields, one way to improve the performance is to move these calculations down into the query.  This can also be done for conditional formatting.  If your conditional expressions require calculation or external lookup (if they use a domain function, like DMax, for example), you may be able to increase the performance by pushing those calculations down into the underlying query, then referencing the field values in your conditional expression instead.

Will it be possible to apply cond. formatting to the background of a detail section? Or to every control in a row at once?  Or to highlight jsut the active row in a cont. form?

>>> This is a great feature request.  We haven’t done anything in Access 2007 which makes this easier, but it is definitely an issue on our radar for future versions.

Many of us have been asking for more than 3 conditional statements, or to make the formatting more generalized.  For example, applying a color saturation that is proportional to a percent value in a control.  Will there be any way to accomplish these feats, even if we have to resort to API calls?  I know you have shown us that Excel has added these features in a really fantastic way, but haven't there been any improvements at all in Access?  Even if you just exposed the Window handles (hWnd property for a detail row or control) so we could manually paint these areas without excessive API acrobatics...that would be a huge help.

>>> These are also great features to add, but not ones we could get to this time.  They’re absolutely something we’d consider for the future.

Will we be able to alter (e.g. size and color) the appearance of checkboxes and option boxes? - the current ones are a bit too small for some users with disabilities.  I would love to have a few checkbox images/sizes/colors to choose from.

>>> Checkbox and option button controls are themed by Windows, so they should theme with the rest of your Windows setup.  If you can get Windows to grow the controls (e.g. high DPI mode), then the controls should also grow in Access.  This should also work in Access 2003.

Will hyperlinks work and format correctly (i.e. will they look and behave like clickable hotspots) in datasheet view?

>>> Hyperlink fields continue to behave in Access 2007 as they did in Access 2003, allowing both navigation and editing from within the Datasheet view.  Clicking on the cell continues to launch the hyperlink in the browser, while tabbing in to the cell will allow users to edit the values.  Was there a specific change you were looking for in the behavior here?  

>>> We also have a new feature which allows developers to build buttons and textboxes which behave like hyperlinks from the hover/click standpoint.  This enables developers to have a piece of UI which looks and feels like a hyperlink to their users,  but which fires a click event to custom code instead of opening a browser window and navigating to the URL value stored in the control.

Will we be able to display rtf in datasheet view?  Will images and other standard rtf fields display correctly in the new rtf control?

>>> Absolutely, RTF works in datasheet view for tables, queries, and forms as well as in textboxes on forms and reports.

Will the rtf control support the latest revision of the rtf standard - i.e. give us COM access to the underlying control so we can use the TOM (text object model), API calls, etc for advanced rtf features?  IOW please, please find some way to expose the underlying COM control for advanced users needing hidden or protected text, embedded images/objects, mouse-over-word coordinates, etc!  I am using all of these features in the current MS RTF control, so I sure hope the new control is fully backwards-compatable with standard Microsoft RTF control that was previously recommended by the Access group.

>>> The new rich text feature in Access reads and stores data as HTML.  The model for getting/setting formatting on runs of text in this control is to work directly with the HTML format data stored in the field.  For example, if you change the .Value of the textbox to be “<b> stuff </b>”, then the text will get bolded.  Whether or not to render any data as rich text is a textbox property, which means that you do not need a special field type to have rich text.  Any text data can be rendered as rich, and simple HTML formatting will be applied when it is shown, if the TextFormat property of the control is set to Rich Text.  

>>> The reason we do this is so that our RTF is compatible with the Rich Text in SharePoint lists.    To ensure compatibility, HTML tags found in the data which are not part of the HTML subset we support will be discarded when the data is saved.  This includes imbedded images and other advanced features.  SharePoint has a new type of enhanced rich text support which can include hyperlinks and images as well as formatted text.  Data of this type will appear to Access as read only, and images imbedded in this data will not be viewable in Access.  
# AL said on April 18, 2006 7:47 PM:
Those are some great answers!

Regarding the hyperlinks, in my hands in Ac2002, they were not correctly formatted (e.g. blue/underline) in datasheet view.  But I guess that problem has been resolved??

Please consider some checkbox variants for the next version.

I need to think very hard about what to do about all my complex data in true RTF format.  I'll  probably have to continue to use the old rtf control.  Aside from that, I am very impressed!

Thanks again for the quick and comprehensive responses!  It's a great help in planning for the future.
# Emanuele Spampinato said on April 19, 2006 2:02 PM:
Hi Erick,
I'm just playing with Access Beta 1 and about Form Authoring I've some questions.

Q1. How is it possible to use anchoring features to make controls floating inside the form while the form is resizing.

Q2. I hoped in some functionalities about ComboBox: A DropDown event and a way to hide the dropdown button when the control has not focus (like Microsoft Forms does in other Office applications). Any comments?

Thanks
# Kiwibruce said on April 21, 2006 11:31 AM:
Hi Erik,

Thanks for the reply on the Tree-view control, Am sad about the answer but that is life. But here is a challenge for the Access Dev team... Can someone revive the A97 Tree-view Wizard (http://support.microsoft.com/?kbid=163511) and update it to A2007 (or A2003) for that matter!)  How about that for a little homework project for someone on your team...... That would help out A LOT until you guys develop a bound Tree-view in the next version.   It wasn't perfect but it was at least a start to generating the pages of code need to run the tree-view control. and anyway, someone at MS built it once so the source code must be lying around on a server there somewhere. Go on... you know you want to...

Also as some info for everyone, I went to a talk by Jensen Harris (Lead Program Manager on the Microsoft Office "user experience" team) last week when he was up here in Vancouver and it was really interesting to hear in person the reasoning behind the Ribbon. Awesome presentation and I am now a compete convert!. For everyone else read his blog (http://blogs.msdn.com/jensenh/default.aspx) worth the read.

Bruce
# clintc said on April 21, 2006 12:24 PM:
Emanuel,
Erik is a little busy these days so I will take a crack. The anchoring properties can be set three ways: right click on the control, in design or layout view under the Layout tab click on Anchoring, in the property sheet (horizontal and vertical anchor).

Sorry--we haven't exposed an event or property to hide a dropdown button until it has focus. I will put that on the list to consider for next time.

Clint
# AL said on April 21, 2006 2:50 PM:
Hey Bruce,

In truth, the MS treeview OCX is not that hard to use, but it does take a few days to get the hang of it.  Also, there is a huge amount of good code available by Google (umm MS Search).  You can even do all sorts of fancy API modifications.  If you don't like that, there are a bunch of truly excellent treeview type OCX's, and some of them are free.  Regardless, you will always have to write a lot of code for treeviews.  That is the price for flexibility.  Personally, I would prefer a free multicolumn treeview with variable height rows, but at least I know that such a beast can be purchased for a reasonable price.

# jpcoulson said on April 24, 2006 2:54 PM:
I had never heard of MS Access before October 2004, but having been handed an assignment I dug in and began using it from scratch.  I finally found the user forums and since that time have built roughly 20 tools that are in use throughout my hospital.  I say this to let those who have commented know that SOME end users tackle the program and learn about proper, normalized tables and relationships.  As for this Blog, it is great and I am anxious to get ahold of the new version as soon as it's available.  I have signed up for a beta release.

Jeff
# bazarov said on April 25, 2006 10:33 PM:
How about native controls that replace all MS Common Controls?

I can't see how this would be difficult, as Access 97-2003 all support mscomctl.ocx.

The issue is not so much using the controls, but the very real headaches that deployment of Access applications using these controls create. The whole OCX paradigm that Access developers must use is dated and really something that MS should have fixed a long time ago.

Also, many corporate clients refuse point blank to accept separate OCX/DLL files in an Access application.

A native SideBar Control is well overdue. Look at the excellent free DevExpress DLL that works in Access so well. Is it so hard for MS to incoprorate the native Outlook control in to Access?

This brings me also to the archaic native Switchboard look and paradigm that has not changed since Access 95. Is there any joy here?

Regards

Tony D'Ambra
# A discussion of what's new in Access 2007 (formerly "Access 12") said on June 13, 2006 4:36 PM:
The last regular post was on Sorting and Grouping in Reports, and that followed a post about Sort &amp;amp;...
# Weddings said on June 6, 2008 2:16 AM:

Last week we looked at the WYSIWYG report authoring tools , this week we'll take a look at the similar forms designer. Since forms generally don't repeat like reports do this designer looks more like the old form authoring tools than the report designe

New Comments to this post are disabled
Page view tracker