I guess that would depend on what your app is doing. In my case, as I
mentioned the accounting application does it this way. The object of the
new .NET app is to mimic Great Plains and so that it would appear seemless
to that application.
As for why you might code an application this way, what if I validate after
the whole transaction is complete:
1. you call me up and want to place an order for a bunch of items.
2. I enter in what I _think_ is your customer id.
3. I then enter in a bunch of items one at a time
4. But perhaps I enter in the customer id wrong. You have a contract with
me to provide customer/item specific pricing but since I typed in the
customer wrong when I entered it. Since I have the wrong ID, when I'm
quoting you the price over the phone it'll be wrong.
5. Also I might have mis-typed my items wrong on entry and so when I told
you I had 5 "widgets" on hand as it turns out I really didn't because it
wasn't entered correctly and reserved by inventory. So by the time I enter
your order and press "submit" some other user just entered 1 item and
allocated by widget already. That really needs to be realtime.
Your other idea is a good one, disable everything else that relies on this
one field being valided first. I think I'll probably implement something
like this.
As it turns out, the solution was apparently obvious. I just missed it
about a dozen times as I didn't realize as the property really applies to
_other_ fields. I switched the "CausesValidation" property on my button to
False. So now when I press my button the validate event doesn't run and I
open my window and set focus back onto the text field again. Not quite as
convenient as Dexterity but darn close and good enough for me.
thanks for your response,
patrick
microsoft dynamics
Quote:
This is not a good way to do validation. I have only ever encountered 1
app
Quote:
that does it this way and I uninstalled it pretty quick. This is annoying
for the user because they might want to fill in other fields first or tab
to
Quote:
a close button. Getting rid of this behaviour will solve your problem.
Instead check for a valid customer id when they push the ok button. If
they
Quote:
need to fill in this id to get all the other fields available then just
disable every other field on the form.
>
Michael
"Michael C" <nospam@nospam.comwrote in message
news:uepsp2h1GHA.4908@TK2MSFTNGP02.phx.gbl...
Quote:
"Patrick [MSFT]" <prot@online.microsft.comwrote in message
news:ehbR2Ug1GHA.1336@TK2MSFTNGP03.phx.gbl...
Quote:
Let me preface this with the goal I'm trying to achieve is mimic a
feature
Quote:
Quote:
of another language (Dexterity used by Microsoft Dynamics) and so while
a
Quote:
Quote:
filling a drop down list is a workable solution I'd rather do it like
Microsoft Dynamics does and use separate textbox and lookup button.
What I have is, simply, is a C# winform, a textbox and a pushbutton.
On the textbox, on the validating event of the textbox I check my
customer
Quote:
Quote:
table using ADO and verify that the Customer ID entered is indeed in the
database. If it is not, give a message and keep focus on the textbox.
If
Quote:
Quote:
it is in the database, then everything is OK (of course).
>
This is not a good way to do validation. I have only ever encountered 1
app
Quote:
that does it this way and I uninstalled it pretty quick. This is annoying
for the user because they might want to fill in other fields first or tab
to
Quote:
a close button. Getting rid of this behaviour will solve your problem.
Instead check for a valid customer id when they push the ok button. If
they
Quote:
need to fill in this id to get all the other fields available then just
disable every other field on the form.
>
Michael
>
>