Third Of Five - just another voice in the Collective : Access 2003

Changing Default Control and Form/Report Settings

ThirdOfFive — Tue, 10 Oct 2006 19:00:00 GMT

This is one of those features that almost nobody knows about because it isn't very discoverable. In Access 2007 (and earlier), you can change the default property values for any new controls in a form or report. Here are the necessary steps:

Open/Create form or report in design mode;
Select the "Design" contextual tab (or the equivalent toolbar with the controls for Access 2003 and earlier);
Open the Property Sheet (using the Ribbon or hitting ALT+ENTER);
Notice that the property sheet caption says "Selection Type: Default <Control>";
Change the properties at will;

From this point on, any new controls you create will have its default properties set to what you customized.

It's worth mentioning that any changes you make will only exist in the context of this form or report alone. However, you can also create settings that apply to all newly created Forms and Report. For this purpose, follow the same steps 1-5 above, and do one more:

6. Save the Form or Reports with the name "Normal";

If there is a "Normal" (like Word's Normal.dot) form, all new forms will inherit its settings. The same goes for reports, but notice that form settings cannot be inherited by reports and vice-versa. Of course, if you delete the "Normal" form or report, you will not affect the default settings of the already created forms and reports since they already inherited them. Only newly form and reports from then on will not inherit the settings anymore.

This is a very neat feature to speed up creating a number of forms and reports that will use similarly set controls (or width/height even) without having to go through multiple copy and paste runs.

New Access to SQL Server Migration tool

ThirdOfFive — Wed, 05 Jul 2006 19:00:00 GMT

A new tool is available for Access to SQL Server migrations. The SQL Server Migration Assistant for Access is available here. Notice, however, that the tool is not released yet - these are pre-release quality bits. As usal, backup, backup, backup and backup before usage.

"Why should I care" tidbit from the docs:

Q. Why should I use SSMA for Access instead of the Office Upsizing Wizard?

A. SSMA for Access offers a richer set of features, such as network scanning, conversion assessment reports, and more. SSMA for Access also fixes many issues currently not handled correctly by the Office Upsizing Wizard.

Access and Colors: How Access 2003 works

ThirdOfFive — Thu, 23 Mar 2006 19:00:00 GMT

There is a lot of confusion regarding the Access color properties, such as font color, control background, etc. People just don't grok the numeric values that Access uses. And that's not surprising considering how misleading it is.

Perhaps one reason for that is that nowadays everybody uses HTML colors, which are actually very simple: 24 bit values with 8 bits per color component from the least significant to the more significant: blue, green, red. So values look like #RRGGBB. For example, red is #FF0000.

However, in Access the color properties are actually encoded as BGR (blue, red, green) values, from 0x000000 through 0xFFFFFF. Altough this might seem totally weird, there is good reason for it, and it comes through clearly as one notices that VBA's color functions work the same way. For example, the RGB function in VBA will generate BGR values. So, RGB(255, 0, 0) will return 255 instead of 16711680 (0xFF0000) as one would think. For example, a pure green in Access is 65280 = #00FF00 = &H00FF00 = RGB(0, 255, 0).

[VBA Homework: how would you convert between RGB and BGR?]

Finally, there is one additional bonus in the Access color properties: system colors. These special colors can be used through a set of negative numbers (below), and will change depending on the Windows Theme currently being used. So unless you plan accordingly, the contrast between fonts and background and other control when you are developing might not be there (it might appear as white on white) when a user has a funky theme installed. A nice bonus of using these system colors is that you will get automatic accessibility as users turn on high contrast.

-2147483648 : System Scrollbar
-2147483647 : System Desktop
-2147483646 : System Active Title Bar
-2147483645 : System Inactive Title Bar
-2147483644 : System Menu Background
-2147483643 : System Window
-2147483642 : System Window Frame
-2147483641 : System Menu Text
-2147483640 : System Window Text
-2147483639 : System Title Bar Text
-2147483638 : System Active Border
-2147483637 : System Inactive Border
-2147483636 : System Application Background
-2147483635 : System Highlight
-2147483634 : System Highlight Text
-2147483633 : System Button Face
-2147483632 : System Button Shadow
-2147483631 : System Disabled Text
-2147483630 : System Button Text
-2147483629 : System Inactive Caption Text
-2147483628 : System 3D Highlight
-2147483627 : System 3D Shadow
-2147483626 : System 3D Light
-2147483625 : System ToolTip Text
-2147483624 : System ToolTip Background
-2147483623 : System Static
-2147483622 : System Static Text
-2147483621 : System Gradient Active Caption
-2147483620 : System Gradient Inactive Caption
-2147483619 : System Menu Highlight
-2147483618 : System Menu Bar

Next week I'll talk about how we're improving color properties with Access 2007. Stay tuned!

Macros vs. VBA

ThirdOfFive — Fri, 14 Oct 2005 19:00:00 GMT

As many people have pointed out, macros do not offer the same range of functionality that VBA does. It's kind of interesting that some people even think that Macros were some sort of pre-VBA functionality that Access had. This is actually false - both macros and VBA were introduced in the same Access version (do you know which?).

Macros were thought as kind of a more structured, entry-level way to code in Access, while VBA had the steeper learning curve but had the full range of functionality on its hands.

So, why should you use macros?

I'm not even going to make the cheesy comment that anyone that ever used the DoCmd functions (e.g. DoCmd.OpenForm) were really using macro actions. Because, you know, that's actually not 100% true: the DoCmd commands were exposed at the same time to macros and VBA - they are different entry points to the same infrastructure.

I think the answer lies in the corollary: Don't Write Code Unless You Absolutely Must. And that is coming from someone that writes code pretty much all day long.

I believe that there is a use for macros (besides the obvious cases where you don't have an option, such as the AutoExec macro), and that use may very well be when you need to do something very simple (programmatically speaking, e.g. open a form) but you don't want to have the IT police freak out when they see VBA code.

(Even further, as Erik hinted here, in Access 12 macros gain some interesting functionality and can be used in a sandbox mode that doesn't require signing. And that's just one new thing - there are plenty more in the macro world.)

Erik Rucker's blog

ThirdOfFive — Thu, 13 Oct 2005 01:28:00 GMT

You might want to check out our GPM (Group Program Manager) blog here: http://blogs.msdn.com/access. I heard it's going to be all-Access 12 all-new content :)

Office 2003 SP2 is out

ThirdOfFive — Thu, 29 Sep 2005 00:57:00 GMT

Access users: Make sure you install SP2 (here: http://www.microsoft.com/downloads/details.aspx?FamilyId=57E27A97-2DB6-4654-9DB6-EC7D5B4DD867&displaylang=en) since it also contains some important Access fixes. This KB article describes what's changed Access-wise: http://support.microsoft.com/kb/906460/.

While I'm still talking about Access samples...

ThirdOfFive — Wed, 07 Sep 2005 19:00:00 GMT

I bumped into this Access sample the other day which is very interesting: an Access to/from Powerpoint presentation creator/exporter/importer. It shows you how to automagically create PowerPoint presentations using Access and how to make use of PowerPoint presentation within Access. And it's all powered by OLE, using the OLE control.

This got me thinking... you can do some very nifty things with this. You can, for example, create a catalog of PowerPoint presentations for a training shop. If you use SharePoint, you can have Access catalog all your intranet presentations from a central location and let you even preview them. You can likewise use Access to come up with statistics on posted Excel spreadsheets, Word docs and all other kinds of Office documents on your SharePoint sites. Pretty cool.

BTW - you might also want to take a look at the similar sample relating to Outlook and Access.

Northwind

ThirdOfFive — Mon, 05 Sep 2005 19:00:00 GMT

Perhaps one of the first things you play with when you start to learn about Access is the Northwind database.

Some people have some very strong dislike about Northwind. And you know what? They have very good reasons.

Northwind has a lot of depth by using a lot of different types of objects (queries, etc) and features. That's very helpful when you want to see what's included in the product and wants to test some ideas/code against a rich dataset. However, it's pretty much useless when you want to actually build a database from the ground up. And it's so full of custom code, bells and whistles that it's very hard to even copy something you like to another database.

For example, let's assume you're building a light CRM database to track customer complaints. How do you use Northwind to get you started? Um, you don't.

The good news is that there are a lot of free templates online that you can download from Office's website. In particular, I recommend you take a look at the new free Issues Template. It is a very good starting point for a good number of application people generally build, and changing it to get your CRM app is much more straightforward than Northwind. And did I mention this is all available for free?

Most Annoying Feature... ever

ThirdOfFive — Thu, 01 Sep 2005 16:00:00 GMT

This is a pet peeve… If you use Access and have multiple windows open, each window shows up as a separate icon in the task bar.

Thankfully, you can turn this feature off in the Options dialog. Of course, you need to have a database open to use this dialog (don’t get me started, but we’re addressing this in Access 12). In the ‘View’ tab, uncheck the ‘Windows in Taskbar’ option.

And voila, now we have an uncluttered taskbar. And now, for the bonus question: what do you think this feature is for?

Well, it was meant as kind of an SDI mode for Access. Good intention, but quite frankly I don’t like it.

Rumours of Access' demise greatly exaggerated

ThirdOfFive — Wed, 31 Aug 2005 16:00:00 GMT

I saw this thread the other day on UtterAccess (btw, a very nice resource for all things Access) which made me laught a little. Oh, the rumours. It's always fun to hear crazy stuff you know first hand to be completly made up.

Well, if it serves anything, I can authoratively say that that Access is alive and kicking. Or at it least I hope so, because otherwise I've been hallucinating about going to the office every day to work on Access for a while now.

If you use google..err..msn search, you can even find more hints about this.