By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,905 Members | 2,075 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,905 IT Pros & Developers. It's quick & easy.

Want to Open a form and have NO default

P: n/a
I have a main form for a little application and I want the Main Form to
open with NONE of the buttons having focus. Now, the first button has
focus.

It's just a plain form, with buttons (created with Wizard code - I'm
not experienced at all), to open various forms to perform the work:
Add Item, Add new vendor, Print Reports, close the App.

Probably something easy; I just don't know what it is!

Thanks,
Sara

Nov 13 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
sara wrote:
I have a main form for a little application and I want the Main Form
to open with NONE of the buttons having focus. Now, the first button
has focus.

It's just a plain form, with buttons (created with Wizard code - I'm
not experienced at all), to open various forms to perform the work:
Add Item, Add new vendor, Print Reports, close the App.

Probably something easy; I just don't know what it is!

Thanks,
Sara


As long as there are things on the form that CAN have focus then one of them
MUST have it. Create a TextBox so small as to be functionally invisible and
make it first in the TabOrder.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #2

P: n/a
Rick Brandt wrote:
sara wrote:
I have a main form for a little application and I want the Main Form
to open with NONE of the buttons having focus. Now, the first button
has focus.

It's just a plain form, with buttons (created with Wizard code - I'm
not experienced at all), to open various forms to perform the work:
Add Item, Add new vendor, Print Reports, close the App.

Probably something easy; I just don't know what it is!

Thanks,
Sara

As long as there are things on the form that CAN have focus then one of them
MUST have it. Create a TextBox so small as to be functionally invisible and
make it first in the TabOrder.


I find a transparent button works better.

A tip here is to set .Transparent=True in the Open event of the form, if
it's .transparent property is true in design mode, it will also be
transparent in design mode making it hard to find on the form.

--
[OO=00=OO]
Nov 13 '05 #3

P: n/a
On Mon, 11 Jul 2005 08:24:15 +0100, Trevor Best <no****@besty.org.uk>
wrote:

A tip here is to set .Transparent=True in the Open event of the form, if
it's .transparent property is true in design mode, it will also be
transparent in design mode making it hard to find on the form.

--

Now that IS a good idea for VB as well. Now I must decide whether to
break the rule "never change a working program" while I still remember
it.
David

Nov 13 '05 #4

P: n/a
On 11 Jul 2005 03:29:02 -0500, not@here (David Schofield) wrote:
On Mon, 11 Jul 2005 08:24:15 +0100, Trevor Best <no****@besty.org.uk>
wrote:

A tip here is to set .Transparent=True in the Open event of the form, if
it's .transparent property is true in design mode, it will also be
transparent in design mode making it hard to find on the form.

--

Now that IS a good idea for VB as well. Now I must decide whether to
break the rule "never change a working program" while I still remember
it.
David


I learned the rule "never change a working program" many years back, then
finally learned that the cost of that rule is higher than the benefit.

The real key is to make sure you have a proper testing policy in place, then
make any code improvements as early as possible while they're still easy and
haven't allowed much newer code to become dependent on the old code you'd like
to have changed. Automated code tests are best if you have the stomach for
it. I'm a Test Driven Development advocate, but still find I can't always do
full TDD unless I'm working with a partner or team who also wants to do it.

Even without TDD, though, if every time you make a change, and cause a
non-obvious bug, add something to your coding or pre-deployment procedures
that will keep that class of problem from reaching the customer (catch bugs as
soon as reasonably possible - makes them much easier to track down and fix).
This will give you the confidence to make code changes freely as they become
desirable. Your result will be much a more better and more maintainable
application than if you try not to make changes to things that are working.
Nov 13 '05 #5

P: n/a
Steve Jorgensen wrote:
it. I'm a Test Driven Development advocate, but still find I can't always do
full TDD unless I'm working with a partner or team who also wants to do it.


The problem I find, is finding some numpty to test it. If I or another
programmer tests it, they just don't do the stupid things with it that
users do.

--
[OO=00=OO]
Nov 13 '05 #6

P: n/a
Trevor Best <no****@besty.org.uk> wrote in
news:42**********************@news.zen.co.uk:
Steve Jorgensen wrote:
it. I'm a Test Driven Development advocate, but still find I
can't always do full TDD unless I'm working with a partner or
team who also wants to do it.


The problem I find, is finding some numpty to test it. If I or
another programmer tests it, they just don't do the stupid things
with it that users do.


My rule of thumb is: every application has as many undiscovered bugs
as there are users who haven't tried it out yet.

This is proven by the fact that the minute you put a new user in
front of it, a new bug will pop up.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #7

P: n/a
On Mon, 11 Jul 2005 19:06:25 +0100, Trevor Best <no****@besty.org.uk> wrote:
Steve Jorgensen wrote:
it. I'm a Test Driven Development advocate, but still find I can't always do
full TDD unless I'm working with a partner or team who also wants to do it.


The problem I find, is finding some numpty to test it. If I or another
programmer tests it, they just don't do the stupid things with it that
users do.


That's why you need a set of policies that gets followed and maintained over
time. From memory, here are some of the pre-deployment steps I created for my
work with one client (different programmers/clients may need slightly
different policies).

1. Test the items that were added or changed in the development copy. Do
both read-only and data-destructive tests.

1a. Don't forget to check right-click menus. This customer uses them A LOT.

2. Test things that we know might be affected by the changed item. Ponder a
moment and think of any non-obvious connections. Do both read-only and
data-destructive tests.

3. Test all of the application's mission-critical features regardless of
connection with the changed items. (It's OK if there's a small chance some
non-critical things broke, but you don't want the client to call you to drive
back out later tonight, right!)

Note that step 3 tests will be done every time we release, so anything we can
do to make those tests easier to run is valuable - automate tests where
possible. Also, if these tests are hard to run, the application may be harder
to use than we would like - improve the UI?

4. Deploy the application, and repeat steps 1, 2, and 3 but do only read-only
tests, not data-destructive tests.

5. If all of the above steps are not done, don't deploy the update today -
wait for next session. If we must deploy, make sure the customer has a way to
run the older version if something goes wrong, and strenuously warn the client
that the new code is not fully tested or guaranteed.
Nov 13 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.