[AccessD] The Future of Access

Arthur Fuller fuller.artful at gmail.com
Fri Oct 25 10:14:12 CDT 2013


Jim,

I didn't say that this app was especially complex, Jim. Its task is
management of volunteers for a non-profit organization. It has volunteers,
opportunities, assignments, volunteer preferences and languages and skills
and a few things like "owns car" etc.. There's an internal side that
external users don't see that involves things like police check, etc. Also,
the internal employees can search the volunteers to find potential
match-ups with opportunies, and email any matches. There's a volunteers
browse with search and filter abilities, plus a detail form that pops up
when a volunteer is selected in the browse, There are associative (bridge)
tables such as...

Volunteers -= VolunteerReasons =- Reasons               Reasons for
Volunteering
Volunteers -= VolunteerLanguages =- Languages         Languages Spoken
Volunteers -= VolunteerSkills =- Skills                         Skills

For lack of graphic abilities here, I'm using the conventions "-=" means
one to many and "=-" means many to 1.

The external portion works on smart phones and tablets and traditional
browsers. No additional code was required to make that happen. On tablets
the app responds to touch gestures and orientation change. In Access
terminology, several "subforms" handle the associative tables above (there
are several more as well). These rearrange themselves to suit the platform,
without any additional coding by me. Each subform also has the ability to
dynamically add to the related table (i.e. a potential volunteer arrives at
the languages-spoken subform and drops the list down, and enters the name
of a language not contained in the Languages table. S/he can add it at that
point). Ditto for the other subforms: add a skill not yet in the Skills
table, etc.

The volunteer email addresses are tagged as links. Clicking on one of them
invokes Outlook to send an email to that volunteer. (That's in the internal
part of the app.)

Not rocket science. That wasn't my point. The hardest single thing for an
Access developer to get used to is that in Alpha 90% of your activity
involves filling in property sheets. When there's nothing built-in to do
what you need, you can reach out into Javascript, HTML5, CSS and Xbasic.

In this case, I didn't have to reach out even once. The whole thing was
finished in a couple of days, and they weren't even close to 8 hours a day.

Arthur




On Fri, Oct 25, 2013 at 10:18 AM, Jim Dettman <jimdettman at verizon.net>wrote:

> <<It's customized in all sorts of ways and I didn't write a single line of
> code.>>
>
>  Man, where/when have I heard that before!  The holy grail of software
> development.
>
>  This is mostly a tongue in cheek response.  I'm not doubting you per say,
> but it's never that simple, especially across multiple platforms.
>
> Jim.
>
>


More information about the AccessD mailing list