Help make Access 14 better - Send us your most used forms!

The Access team is looking to make improvements to the form design experience by helping users get started building powerful and interesting forms.  Most Access professionals have a set of forms that they re-use quite a bit.  What we are interested in specifically is how these common forms are laid out.  There are obviously re-used patterns that you are using in terms of how you layout controls to provide your customers with a compelling experience; we’d love to see examples of them.  Ask yourself the question,

“If the Access team provided me with 5 super easy ways to lay my controls out nicely on a form, what would those 5 forms look like?” 

If this question brings a picture to your mind of one or more form that would be helpful to you, send it to us! Your feedback will help make the next version very cool.

Office Blogs Comments

Comments: (23) Collapse

  • Though I dont have any samples to provide, I do make good use of the template feature for forms and reports. It would also be very useful to have default Fonts, Font Sizes, Colors (fore color, background colors), border styles, effects and things of that nature for each of the different controls. VB maximizer for VB6 had a nice feature when adding controls, it had default prefixes for each of the control names so you can follow reddick\hungarian notation, and also assisted in coupling the label name with the associated control name. A feature of that sorts would also be helpful. Of course, form inheritance would also drastically improve the way we design interfaces.

  • One thing I think would be a GREAT addition as a standard (or wizard-based) feature in Access would be a multiple-field search form. Essentially you have multiple search fields on a form (Search1, Search2, etc.) and the user types in parameters for each of these fields which then either feed a query, or build the SQL statement in VBA code and run the query that way. If you'd like an example, I'd be happy to send you one.

  • Sorry this is off topic but it address the first part of your caption... Can you also make the next version completely independent of all previous versions. Surely this is just a case of using a different install folder and completely different trees in the registry. Access 2007 is basically unusable to me as a developer due to the reconfiguration delay after using Access 2003 (30sec with SP1) and the fact that it is not recommended to run 2003 and 2007 concurrently without Virtual PC. Please remember that developers must run multiple versions of Access as we still need to support databases built 10years ago in Access 97 that still work, are still used and would be un-economic to update to the latest version. Manay developers would be in the position of supporting 50-100 database systems written over 10-15yrs in several different versions of Access. We could do this up until Access 2007 - but it looks like 2007 is a version that must be skipped just like 1, 95 and 2000 for various reasons. This would be OK except that I can't modify SQL Server 2005 objects from a Access 2003 ADP. So without Access 2007 I must use the Management Studio - even when the object I am debugging in the Access window and want to edit is right there in front of me. PLEASE PLEASE make Access 14 better by making it completely independent of all previous versions.

  • Agree with Mark's comments about installing multiple versions next to each other. Another feature I miss, is a easy search for objects (tables, queries, forms, reports, modules) in the whole database. I have projects with hunderds of objects and send too much time searching for the object I need. With forms layout I would like something like the XtraLayoutControl from devexpress. That would give a lot of flexibiltity and increased speed of making form-layouts.

  • Mark (Mark Plumpton), I agree with you. To ms access team, Allow us to compile ms access end product even like visual foxpro or rbase or make a single EXE distribution. Forms enhancement in ms access 14 is not an issue if you allow us developer to use the 3rd party controls like Developer Express DevExperience! Make the one to many forms wizard like Netbeans.

  • No offense, but I hope Access 14 will be a bit more than just making things easier, which are already possible.

    I hope you will also add a few things which are not possible right now (or very difficult), like improved conditional formatting, formatting in listboxes, perhaps an improved version of the treeview control and things like that.

  • Even thou i have a lot of forms i will like to send, there is no way i can upload images here. But i will like to mention some things. Like Thomas Wortig said.

    a) improved conditional formating

    b) formatting of listboxes

    c) tree control.

    d) maybe a grid . . . But there are other stuff i have seen in this new version that really bothers me, when automatically resizing controls some of them go on top of other controls, so this is like not too good. We need to be very carefull while configuring, across top, right, left anchoring feature... Now, my idea will be that access team should include a feature like the table layout panel, that is included in vb.net 2008, that is a great feature, you just dock all your controls in the control and they all grow, and none of them grow on top of each other.

  • I agree with many of the points above, especially the one about version independence on the same instance of Windows. That would *really* be showing a committment to developers. I'd also like to see a more up to date tree view, fully integrated with code complete etc, and the ability to have standard menus rather than the riboon, especially in these days of netbooks with their 600pixel vertical resolutions. I don't use the form templates, so can't comment on them - I build all of my forms myself. In terms of layout, I tend to use a web page metaphor - hyperlinks down left and top and on the main subform etc.

    I can't recall whether it's been added to 2007, but if not, more control of the formatting of controls when hovering on and especially off them with the mouse would be good. Also agree with the ability to roll standalone exe files, a la REALbasic. Very convenient, as many clients are not allowed to install the Access runtime (too much overhead for their IT departsments). A standalone exe is easier to get approved. And my all time number one, but which I know will never happen (but a man can dream, right?) - a version of Access for OS X..... Ah go on, go on, go, go on! :-) Many thanks

  • More theme, More autoformating features, Improve link to SQL Server and Oracle

  • VB.NET is now in it's 3.5 version, but Access' VBA is still based on VB6. Although it isn't a mere silly macro or scripting language, it's somewhat old-fashioned compared with VB.NET. By the way, there is a VBA.NET avaiable to create applications that can be automated using a real .NET programming language. VBA isn't wrong at all, but it just misses the following: a. try .. catch .. finally .. end try

    b. true object orientation

    c. more independence of the Registry

    d. more solid code streaming Here are the relevant arguments about my points: ad a. On .. Error is specially dangerous involving database handling. So it is possible to use On Error Resume Next just to ignore any runtime error that occurs during a programmed database mutation. This is a very bad practice that should be avoided! ad b. VBA still isn't truly object oriented. Classes cannot be derived which can be very practical! ad c. Components should be registered to the Registry, but that database is error prone especially on Windows 9X. Errors in the registry can render a component or even the application totally unusable. ad d. VBA code is stored in an object stream in the Access database which can easily be distorted. Windows 9X users are the most affected by seeing IPF errors which can DESTROY the database which is victimized by the IPF error. Source and Object code of the VBA code should be strictly separated so that at least the source code is perfectly imnpact. In case of a repair action the object code can then be safely removed so that at next startup a new compile can be drawn from the source code and everybode gets and stays happy. I've mentioned Windows 9X, since I've had to work with it at my former work and I've experienced bad errors with Excel and Access involving VBA programming

  • Please, don't make Access a toy for a few non-programmers. Instead, fix all known bugs and make Access stable. We don't need templates. We need professional tools (see VTools, Sagekey, ...). I don't understand why you can't give us a professional deployment solution - I've been programming in Access since A97 but deployment and installation has not been fixed yet - A2007's PSW doesn't even include referenced files & their dependencies in the MSI file!!!

  • Hello, Looks like MS Access 14 is done. So from now onwards major suggestions regarding Access 14 are useless. I hope that you did manage to make implementation of Access databases in workgroups / departments easier with:

    1- a FE automatic updater to use in FE-BE environment . 2- MS Access 14 folder and registries independent of previous Acceess versions.

    3- some form of web application server like Alpha Five would be good... When will be Access beta version avalaible? Once again, thanks for the blog. Sam Caro.

  • I don't have many forms that I reuse between multiple application. I often copy forms in a single app as a template for a new form in that same app. Mostly this is because the default format properties of each control aren't nice to look at. As for the current way for setting default control properties, is hard to edit the defaults. It would be nice if there was a way to save the default properties of a control and import them from one db to another. Like the border, font, colors etc for a textbox. You can edit these defaults by selecting the control from the toolbox and editing the properties window before you drag in onto the design. I think that's how it's done, I rarely do it because you have to do it all over again for each mdb. Can you make it stick with the access options, or make it importable from one mdb to another like import specs can be? Also, can you add a border option that draws a line only on the bottom edge of a label or textbox. Thanks, Josh

  • Josh, it seems that the current way for "setting defaults" that you mentioned is not really setting defaults for the MDB, just the form, and only until you close it. At least thats the behaviour I get when working within ADPs.

  • Please include a - A. robust connectivity with SQL Server, B. Report can be open as multiple popup NOT as a modal. C. Subform can be open in continuous form like Datasheet.

    D. Auto error number function or something similiar so erl() function can provide line number.

    E. Easier integration with .Net Languages like C# (option to use VBA or .Net languages)

    F. Better control for User Interface.

    G. Navigation Pan like visual studio i.e. Individual pan for Tables, Queries, Forms etc. and each should remember their selected object. This should work like visual studio, on mouse hover should open etc. Search functionality I dont whether it should be individualistic for each pan or common.

    H. Property window should not open for query design or there should be a option to set that property window will not open in Query Design. Very frustrating.

    Enough points for a day...i guess

1 2  Next >
Comments

Comments: (loading) Collapse