Re: Access 2007 Technical Questions

Issue 1: Error checking isn't user friendly (Very Critical)

The problem is much your design approach. You always have two choices when
choosing a tool
to develop software:


change your designs to fit the tool
or
change your tool.

I would be quite pretentious of me to post in a VB6 newsgroup,and complain
that
you don't have inheritance or all of the OO features. Or, how about
something
as
simple as bound data forms that we have in ms-access? VB6 is NOT going
to get bound forms! It is just not going to happen. As much as you
would like the universe to move to "your" view of things, a major change in
the event model and change to ms-access is not likely.

To be fair, it would be nice to be able to turn of validation. However, you
also have to turn off the before update event. And, even further, you might
even have to turn off a for more events. So, *just* turning off validation
would not work, since we do have the before update event also (this is
likely were *most* of your validation code was/goes anyway..right?).

Not much you can do here:


Either you have to change your designs, or change your tool.

If you conclude that you can't get the level of user friendly with bound
controls, then you simply have to dump ms-access.

Now that you spend the time (or perhaps a better word wasted the time)
moving to un-bound controls, then you really receive no benefits of using
ms-access. VB6 and other tools are *optimized* with wizards etc to
help make up for the "lack" of bound controls. If you extensively use
un-bound forms and controls in ms-access, you loose all of the advantages
from a cost point of view, but receive NONE of the tools that other systems
have to make up for the lack of bound form. It is the worst of both worlds,
and you are spending money that your company could give to the poor, or
for use in helping other people (or, just simply not throwing $$ down the
drain).

However, it is fair to ask what kind of workarounds, and what approaches do
work in ms-access.

I have two suggestions that will work quite well in ms-access.

Suggestion #1

Keep bound controls, and move the validation code to the forms before
update event. This of course means that you loose a field by field
validation.
However, the simple solution in that case is to use the controls before
update event and have that validation code in there also. BUT DO NOT
USE THE CANCEL feature of the before update.. This means that a user
receives a message that the control is required (or not setup to whatever
value etc etc etc) but is ALLOWED to continue to move on in the form.

In fact, from a user friendly point of view, this approach is BETTER then
forcing the user to STAY on control, or use some quit button on the form!
You see, in your "quit" link example, that ONLY works if the users hits the
quit command. What happens if they need to go back a few fields and edit
something but are now are STUCK on the validation for the current control.
This just simply causes HUGE user frustration. If you want a debate on
user friendlness, then you DO NOT want to force a user to be stick on that
control, and ONLY give them the option to quite. Hence, move the *final*
valuation that prevents a record save, or form exit of the form to the forms
before update event.

Further, if the user does NOT ENTER INTO THAT REQUIRED FIELD/control,
, then you STILL MUST HAVE form's level validation code!!!. In other words,
if you have some control on the form that is required, or MUST meet some
special
value, but the user DOES NOT EDIT that control, THEN YOU MUST still have
that forms
level validation code anyway!! So, my point here that even when you used
control level
validation (I am talking about before update + cancel feature of a control),
you STILL had to write a forms level validation routine anyway to catch
those
controls/fields that were not edited by the user!!!

In conclusion, you at *always* had to write a forms level validation
routine in the forms before update event routine for user friendly code.
So, for each control, give the user a error message/warning..but
simply do not use the cancel feature of that control. Simply reduce user
frustration, and allow the user to continue to work their way through the
form. As I said, 9 out of 10 users prefer this, and they do NOT
like get being stuck on a particular control, but can continue to move to,
and edit
other controls on the screen. With the VB6 approach, you can't move to other
controls but must ONLY be faced with a cancel, or quit that disables the
validation.

The above approach I outline is not only MORE user friendly since they don't
get stick
in the middle of a form, it ALSO LESS CODE then what you wind up with in
VB6, or your wrong
choice of un-bound controls. This approach is friendly, and works very well
with bound forms +
controls.

So, In above, we are STILL giving the user a message when they enter some
value in a control
that is incorrect, but they are allowed to continue on to the next
control...and
users prefer this. And, thus our *final* validation is in the forms before
update catches this stuff (and as mentioned, you *always* had to write that
code anyway!).


Suggestion #2
Move your quite command, or other commands that "must skip" the
validation to a toolbar, or a menu bar. Again, this is more "widows" like,
interface, and the added benefit is that menu commands DO NOT TRIGGER
the before update event, or even any of
the last focus events. I used this approach in place of #1, and also that of
validation in VB6. So, I have used menu bars to get around the fact that we
don't have the ability to turn off the before update events, or validation
code (by the way, we need to turn off BOTH events to allow the equivalent
features of VB6 -- and, in thinking about this, perhaps a few more vents.
So,
turning on the events in ms-access is FAR MORE complex problem then the
very simple validation that you have in vb6).

Again, of course, if you are not willing to modify you designs to the above,
then I can't help you. However, in no way can I see that above
two choices is ANY LESS user-friendly then what you done (expect that you
wasted huge $$ moving to un-bound controls).

You can't design your appcation with one architecture in mind, and then hope
that FoxPro, or ms-access, or power-builder will work the way you want (they
don't by the way...YOU have to change your design...not the other way
around). Learning to design within in the bounds of the tool you are
using is the difference between developers that understand the subtleties of
developing..and those that don't...

As a number of others stated, you can very well reach a *VERY* high degree
of validation AND ALSO reach a level of user friendly nesss. As mentioned,
the above two suggestions are of many possible approaches. I too also have
some VERY high degree of demands for checking and validations,but also that
of
user friendly at the same time..

the EditMode property no longer
has it's enum value that it suppose to have. This more or less has
rendered
DAO programming useless.

I not seen this error pointed out. You might want to elaborate this with a
new question/post


Issue 3: ADO programming doesn't allow for DynamicCursor Keyset against a
Jet Engine (Critical)

ADO, and JET are only pieces used by ms-access, or VB.net, or VB6. Are you
saying the above ONLY applies to ms-access, or are you talking that the
general use of ADO and JET has this problem? (this would thus not be a
problem special to ms-access, but to ado in general, and presumably, then
also
this problem would exist with .net also???)

Issue 4: Listbox properties doesn't update until it has lost focus when
it's allowed to have multiple selections (Moderate)

Hum, that don't sound right. Try using the after update event, and use the
itemsselect collection...

Place the following code in the after update event of a multi-select list
box....


MsgBox Me.MyListBoxName.ItemsSelected.Count

Try the above. ItemsSelected should be updated correctly...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@xxxxxxx
http://www.members.shaw.ca/AlbertKallal




.

Loading