opening a form from a form

[AccessVandal via AccessMonster.com]

Hi Bruce,

I thought I had described it in some detail. I have not found a situation
in which the Dirty property is true during the Before Insert or Dirty event.
Can you describe such a situation? Not meaning to sound like I'm issuing a
challenge here, but you seem to be siuggesting that with a different form
design the Dirty property would be True for the Before Insert or Dirty
events

That's what I am saying, A misunderstanding here, no offence taken,
BeforeInsert/Dirty event,
1.If there are no code in these event, when user key input data into a field
the result is Dirty = True.
2.If there is code, the user can choose the edit or insert records, if user
cancel then the result Dirty = False. If the user did not cancel, then the
result is True.

3.If there is no code, we'll probably use the BeforeUpdate event the check
the Dirty value.

What I'm saying, is that the initial result or during in the
BeforeInsert/Dirty event the Dirty is False. It is only after the event that
you need to evaluated the result of "Dirty".

As I understand, the OP was talking about enabling the controls when a user
starts typing into a record. I can sort of understand why that approach
might be taken for a new record, but it is harder to see why it would happen
for an existing record. In any case I did not take the question to be about
different permissions for different users. Having said that, I agree that
if there are security issues the Open event is a good place to hide or
disable controls. With User Level Security in place that is how I approach
it so I do not have to design different FEs for different users.

So, what's the point of disable/enable the controls when use have user level
security? As accord to OP, how are you going to control security with such
event?

 

[BruceM]

OK, so we seem to agree that testing for Dirty in the Before Insert or Dirty
events is pointless, because it will always be False *during* the event.
Canceling as part of the event will leave the Dirty property at False.

The Before Update event by definition runs when the record has been dirtied;
otherwise there is nothing to update. Dirty will always be True *during*
Before Update.

Hi Bruce,


That's what I am saying, A misunderstanding here, no offence taken,
BeforeInsert/Dirty event,
1.If there are no code in these event, when user key input data into a
field
the result is Dirty = True.
2.If there is code, the user can choose the edit or insert records, if
user
cancel then the result Dirty = False. If the user did not cancel, then the
result is True.

3.If there is no code, we'll probably use the BeforeUpdate event the check
the Dirty value.

What I'm saying, is that the initial result or during in the
BeforeInsert/Dirty event the Dirty is False. It is only after the event
that
you need to evaluated the result of "Dirty".


So, what's the point of disable/enable the controls when use have user
level
security? As accord to OP, how are you going to control security with such
event?

The OP said nothing about ULS. About command buttons she said:
"I would like to enable [the two command buttons] as soon as any typing
occurs on the form. I'm using the on dirty event at the form level but it
is not firing when filling in a new record."
I don't understand the point of enabling controls as soon as the form is
dirtied, although as I said I can understand reasons for doing so in a new
record. However, I chose not to attempt to discourage the OP from that
course. Without seeing more of the code I do not see why Dirty did not fire
for a new record, but if the idea is to enable the buttons when typing
starts in a new record I would just use the Before Insert event. That's all
I was saying. In any case, the OP seems to have dropped out of this
conversation some while ago.

 

[AccessVandal via AccessMonster.com]

Hi Bruce,

The OP said, “as soon as any typing occurs†means that regardless of existing
or new records. One thing is for sure; you can’t idiot proof an application
that way. What about accidental pressing of a key? Still, it’s not a good way
to enable controls in the BeforeInsert event. Pressing any keys on the
keyboard just to enable control does not serve any purpose at all, might as
well just enable the controls in the first place.

One of the possible reasons for OP to use keyboard, like a single or two key
to enable the control and isolate all keys on the keyboard.

‘ E for Edit / I for Insert
If KeyAscii = 101 or KeyAscii = 105 then
‘enable controls
else
‘disable controls
end if
‘disable key preview

Let’s not discuss this topic as the OP had abandoned this thread.

OK, so we seem to agree that testing for Dirty in the Before Insert or Dirty
events is pointless, because it will always be False *during* the event.
Canceling as part of the event will leave the Dirty property at False.

The Before Update event by definition runs when the record has been dirtied;
otherwise there is nothing to update. Dirty will always be True *during*
Before Update.
The OP said nothing about ULS. About command buttons she said:
"I would like to enable [the two command buttons] as soon as any typing
occurs on the form. I'm using the on dirty event at the form level but it
is not firing when filling in a new record."
I don't understand the point of enabling controls as soon as the form is
dirtied, although as I said I can understand reasons for doing so in a new
record. However, I chose not to attempt to discourage the OP from that
course. Without seeing more of the code I do not see why Dirty did not fire
for a new record, but if the idea is to enable the buttons when typing
starts in a new record I would just use the Before Insert event. That's all
I was saying. In any case, the OP seems to have dropped out of this
conversation some while ago.