If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
opening a form from a form
Hi Bruce,
BruceM wrote: 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? -- Please Rate the posting if helps you Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/For...forms/200809/1 |
#22
|
|||
|
|||
opening a form from a form
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. "AccessVandal via AccessMonster.com" u18947@uwe wrote in message news:8a8d1ec8ef325@uwe... Hi Bruce, BruceM wrote: 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? 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. -- Please Rate the posting if helps you Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/For...forms/200809/1 |
#23
|
|||
|
|||
opening a form from a form
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. BruceM wrote: 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. -- Please Rate the posting if helps you Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/For...forms/200809/1 |
Thread Tools | |
Display Modes | |
|
|