Are MS Access Applications MDI or SDI?

[Felipe]

There is a company well-known to many serious MS Access programmers. The
company, FMS, sells a bunch of MS Access add-ins and is a Microsoft Gold
Certified Partner. So when it comes to talking about MS Access, this company
has a lot of credibility.

On the FMS Web site (fmsinc.com), there are some articles and white papers
dealing with MS Access. In one of the articles
(http://www.fmsinc.com/tpapers/genaccess/DBOD.asp), the author states the
following in a section labeled "Limited User Interface":

"Applications built in Access, unlike Visual Basic, are limited in
appearance. Multiple document interface (MDI) applications cannot be built
in Access and in general, users can tell if an application is written in
Access. For some situations, programs like VB provide a more desirable user
experience on Windows".

I'm confused. The author clearly states that MDI applications cannot be
built in MS Access - yet we all know that multiple windows can be opened
simultaneously.

So my question: Are custom MS Access applications MDI or SDI? If they
*really* can be MDI, then what could the author mean by his statements.
Normally I'd discount such statements, but considering that the source is
very much biased TOWARDS favoring MS Access and is generally considered an
industry expert, I tend to think he knows what he's talking about. Please
help understand.

Thanks!

 

[TC]

As for MDI versus SDI, I guess it depends what you mean by those terms.
IMHO, MDI (Multiple Dcument Interface) means that you can have multiple
"document" windows open, each one with their own individual size &
position. In Access, you can have multiple form & report windows open,
each one with their own individual size & position. So IMHO, Access is
MDI by default. You have to write some code (not much) to make it SDI
(Single Document Interface); eg. by having each form maximize itself,
so it entirely covers whatever form it was called from; thereby giving
the illusion that there is only one "document" (ie. form or report)
open at a time.

As for the statement: "in general, users can tell if an application is
written in Access" - it depends what "in general" means. If it means,
"when the application has been written by an inexperienced developer" -
it's probably true. If it means "when the application has been written
by an experienced Access developer' - it's basically nonsense. You can
easily write an Access application where there is nothing to tell, just
by looking at the screen, that it was programmed in Access.

HTH,
TC (MVP Access)
http://tc2.atspace.com

 

[Dirk Goldgar]

There is a company well-known to many serious MS Access programmers.
The company, FMS, sells a bunch of MS Access add-ins and is a
Microsoft Gold Certified Partner. So when it comes to talking about
MS Access, this company has a lot of credibility.

On the FMS Web site (fmsinc.com), there are some articles and white
papers dealing with MS Access. In one of the articles
(http://www.fmsinc.com/tpapers/genaccess/DBOD.asp), the author states
the following in a section labeled "Limited User Interface":

"Applications built in Access, unlike Visual Basic, are limited in
appearance. Multiple document interface (MDI) applications cannot be
built in Access and in general, users can tell if an application is
written in Access. For some situations, programs like VB provide a
more desirable user experience on Windows".

I'm confused. The author clearly states that MDI applications cannot
be built in MS Access - yet we all know that multiple windows can be
opened simultaneously.

So my question: Are custom MS Access applications MDI or SDI? If they
*really* can be MDI, then what could the author mean by his
statements. Normally I'd discount such statements, but considering
that the source is very much biased TOWARDS favoring MS Access and is
generally considered an industry expert, I tend to think he knows
what he's talking about. Please help understand.

The definitions of MDI and SDI are a bit fuzzy. A traditional MDI
application -- like Microsoft Access -- has a main or parent window that
allows multiple document windows to be opened within the parent window.
For example, Access forms open inside the Access application window --
except for popup forms. An SDI application opens one separate and
independent window per document. For example, Notepad is an SDI
application.

But notice that, when you open two different files in Notepad, you have
two instances of NOTEPAD.EXE running. Contrast that with Microsoft
Word. These days, MS Word supports an SDI interface -- if you open two
separate .doc files, each is opened in a separate and apparently
independent window. But (normally) only one instance of WINWORD.EXE is
running. So the application presents an SDI *interface*, but the same
instance of the program is actually managing two different documents in
two different windows, not contained in a parent "Word" window.

I'd say this is what the author of that article is talking about, and
what *he* means by "MDI". It's really a special case of what is
normally called *SDI*. He's right in that it's not at all easy to build
anything that looks like an SDI interface using Microsoft Access. It
can be done, with some API jiggery-pokery, but that's not the way Access
normally works. But the author's terminology is either just plain
wrong, or he's using a non-traditional definition. Frankly, I've always
thought that these terms were misleading; maybe there's even been some
agreement among UI professionals to redefine them to make more sense. I
haven't heard of it, though.

 

[Guest]

You can only open one database (one 'document') at a time in Access.

You can, actually, open more than one document, (reference or add-in)
database, but the GUI doesn't have a MDI, so you can only see one
document: CurrentDB (or CurrentProject).

You can, actually, see the other open documents in the VBA
environment, because the VBA environment is MDI.

If Access did have a MDI, it would look exactly the Access GUI we
know, because Access was built to the same design as MDI applications
like Word and Excel. Furthermore, you can (and do) write 'Access
MDI' applications, where the 'Access Document' is data from the
database instead of a separate disk file. This is not technically MDI,
but it appears to be MDI, offers the features of MDI, and is bound
to the database instead of the file system, which is appropriate for
Access.

This makes the quotation a little confused. In general, users can tell if
an application is written in Access: one of the reasons is because it
always looks like an MDI. In VB, you can write applications that
do not look like an MDI.

So what can I say:
"Applications built in Access, unlike Visual Basic, are limited in
appearance. In general, users can tell if an application is written
in Access. All Access applications look like MDI. Also, (MDI)
applications cannot be built in Access. For some situations, programs
like VB provide a more desirable user experience on Windows".

His wife has taken over - no more talking for now, goodbye.