Not losing focus on current textbox when pressing a different button

[Patrick [MSFT]]

Let me preface this with the goal I'm trying to achieve is mimic a feature
of another language (Dexterity used by Microsoft Dynamics) and so while a
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
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
it is in the database, then everything is OK (of course).

The pushbotton is a "lookup". In it, I open a new form which fills a grid
with all the customers in the system and allows the user to search/find.
When they have selected the customer, the Select button on the lookup is
pressed and the CustomerID is returned to textbox.

The problem:
In Dexterity I can basically set a property on my pushbutton that
essentially allows me to press the button but not lose focus on my textbox.
Ideally what happens is that I would perhaps enter in "BI" into the textbox,
press the lookup pushbutton, and the form opening then starts with all the
items in the list beginning with "BI" to give me a bit of a headstart in my
lookup to find the correct customer id.

What happens for me, currently, is that I can enter in "BI" into my textbox
and press my pushbutton lookup. But of course the validating event runs,
checks for a customer "BI" which doesn't exist, and then gives my error
message.

I was thinking of trying perhaps a MouseDown event on the pushbutton but the
Leaving event of the textbox fires before that event.

My solutions I thought of so far include:
In the textbox Validating event, check to see where the mouse is and compare
to the coordinates of the pushbutton. If over the pushbutton then don't
check the database and assumed the user pressed the lookup pushbutton.

Override the On_Paint event of my textbox. Draw a "button" onto the end of
the field itself. On the click event of the field (and mouse over to swith
the cursor from I-beam to arrow) check to see if I'm over the "button" I've
drawn on and if so then open my lookup form.

Instead of using an actual pushbutton, draw my own "button" on the form
itself. Use the click event of the form, check the coordinates, and if over
the "button" then open my form.

I'm not terribly well versed in Visual Studio 2005 as I've really only been
using it somewhat seriously for about 4 months now and I can't help but
think there has to be an easier way to do this. Or perhaps I'm just spoiled
by this kind of functionality in Dexterity?

thanks for any ideas you might come up with,
Patrick Roth
Microsoft Dynamics (formerly Microsoft Business Solutions)
Developer Support

[Michael C]

"Patrick [MSFT]" <pr**@online.microsft.comwrote in message
news:eh**************@TK2MSFTNGP03.phx.gbl...

Let me preface this with the goal I'm trying to achieve is mimic a feature
of another language (Dexterity used by Microsoft Dynamics) and so while a
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
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
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
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
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
need to fill in this id to get all the other fields available then just
disable every other field on the form.

Michael

[Patrick [MSFT]]

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

This is not a good way to do validation. I have only ever encountered 1

app

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

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

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" <no****@nospam.comwrote in message
news:ue**************@TK2MSFTNGP02.phx.gbl...

"Patrick [MSFT]" <pr**@online.microsft.comwrote in message
news:eh**************@TK2MSFTNGP03.phx.gbl...

Let me preface this with the goal I'm trying to achieve is mimic a

feature

of another language (Dexterity used by Microsoft Dynamics) and so while

a

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

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

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

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

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

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]

"Patrick [MSFT]" <pr**@online.microsft.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>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.

I really don't think it's necessary to mimic the UI faults of great plains
though. :-)

As for why you might code an application this way, what if I validate
after
the whole transaction is complete:

Ok, that's fair enough and might not suit this particular case. But the
point is you want to find *something* besides forcing the focus to remain in
the textbox. This is possibly the worst UI sin you can comit :-) If
everything else is grayed out there is no need to force focus to remain in
the textbox.

Michael