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

Buttons don't work if form is opened on startup

P: n/a
Buttons don't work if form is opened on startup
A2k
If 'frmMain' is set to open by default at startup none of the buttons
work.
If 'frmMain' is opened from the database window then all the buttons
work.

The form's name ('frmMain') is selected from in the Startup dialog
box.

Here is what is so very strange about this situation.
(read carefully)
This is a recent occurrence. It worked flawlessly a week ago.

Background:
I'm in the habit of versioning applications during development so I
can go back to previous level of development. At each new juncture I
increment a number in the filename. All versions were working
perfectly when I left them, including the current version #69.

== Theory #1 ==
File 69 got corrupted when I last worked on it.

Test theory #1:
Look at other versions or copies of the file to see if the behavior is
unique to the one file

Open previous versions.
I checked version 68 and then 67 - The problem present.
I checked version 66 - No problem with this file.
(The mystery deepens)

Conclusion to test for theory #1:
A corruption took place in previous files but I some how filed to
notice it until now. (I know this isn't true, but I need a theory.)

== Theory #2 ==
Open a copy on a computer that had a copy of the latest file #69 that
I had open last week.

Test Theory #2
Open a previously copied file 69 existing on another computer (#2)
(computer #1 - WinXP Pro Workstation) (computer #2 - WinXP Pro Laptop)

A week ago I demonstrated the application to my customer on my laptop
- there was no problem with that copy at the time.

So... I fired up the laptop opened the previously working copy of the
same version 69 - Worked.

Conclusion from the test for Theory #2: I have several corrupted files
on computer #1 and one uncorrupted file on computer #2

== Theory #3 ==
If I restore the uncorrupted copy of file 69 from computer #2 to
computer #1 all will be well.

Test theory #3:
I copied the ‘uncorrupted' copy of file 69 to computer #1 –
‘uncorrupted file does not work - Same problem.

Conclusion from the test for theory #3: There is a problem unique to
Computer #1
- perhaps files moved to computer #1 inherit the problem
- perhaps a windows update issue
- perhaps an office update issue
- perhaps an issue from loading MS Office 2003 on computer #1
- However, I first noticed hints of the problem several days before I
performed windows and office updates and before I loaded MS Office
2003. At that time I had no time to look into it (I was in the middle
of some other task). I noticed that it took several seconds (maybe 10)
for the button event to work (now they don't work at all)

== Theory #4 ==
There is some unique problem with the installation of office on
computer #1 that recently expressed itself.

Test theory #4:
Move files from computer #1 to computer #2.
Results: all files move from computer #1 to #2 (66, 67, 68 & 69) work!

Conclusion from testing theory #4: There is a problem unique to
Computer #1

== Theory #5 =
There is some unique problem with the installation of office on
computer #1 (another test)

Test theory #5:
Copy various files from both computer #1 & #2 to a third computer
(computer #3 - Win2K Pro Desktop)

Results: Computer #3 behaves identical to computer #1.
(Computer #1 WinXP Pro Workstation) (Computer #3 Win2k Pro Desktop)

Conclusion: The problem is NOT unique to computer #1. Operating
systems are different but office versions are the same. Computers
share the same behavior so the office installation have been exposed
to some common change.

However, That is not true. Computer #3 is largely unused - for several
months it has not had Office updated (or anything else for that
mater). Whereas both computer #1 & 2 have been kept up to date and
often exchange and share files.

I am all out of theories or explanations and have no solution.

Anyone have any ideas?
Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Hi Doug,
Maybe this is the same problem as I have? Look at thread 'Strange corruption A2k'
I just 'solved' it by opening another form (sort of a greeting) as my startupform.

In this form I don't use ANY code, but a macro in the on-timer-event to close the form and open my
Mainform again.
If I use code to do the same then the code is not fired ... (or maybe code is not 'found' = same
problem)
Anyhow this 'works' for me now.

Did not find the 'real' cause or a 'real' solution.
I have the idea this thing is related to Office2000 Servicepack 3 that I recently installed ...
--
Arno R
"Douglas Buchanan" <db*********@comcast.net> schreef in bericht
news:db*************************@posting.google.co m...
Buttons don't work if form is opened on startup
A2k
If 'frmMain' is set to open by default at startup none of the buttons
work.
If 'frmMain' is opened from the database window then all the buttons
work.

The form's name ('frmMain') is selected from in the Startup dialog
box.

Here is what is so very strange about this situation.
(read carefully)
This is a recent occurrence. It worked flawlessly a week ago.

Background:
I'm in the habit of versioning applications during development so I
can go back to previous level of development. At each new juncture I
increment a number in the filename. All versions were working
perfectly when I left them, including the current version #69.

== Theory #1 ==
File 69 got corrupted when I last worked on it.

Test theory #1:
Look at other versions or copies of the file to see if the behavior is
unique to the one file

Open previous versions.
I checked version 68 and then 67 - The problem present.
I checked version 66 - No problem with this file.
(The mystery deepens)

Conclusion to test for theory #1:
A corruption took place in previous files but I some how filed to
notice it until now. (I know this isn't true, but I need a theory.)

== Theory #2 ==
Open a copy on a computer that had a copy of the latest file #69 that
I had open last week.

Test Theory #2
Open a previously copied file 69 existing on another computer (#2)
(computer #1 - WinXP Pro Workstation) (computer #2 - WinXP Pro Laptop)

A week ago I demonstrated the application to my customer on my laptop
- there was no problem with that copy at the time.

So... I fired up the laptop opened the previously working copy of the
same version 69 - Worked.

Conclusion from the test for Theory #2: I have several corrupted files
on computer #1 and one uncorrupted file on computer #2

== Theory #3 ==
If I restore the uncorrupted copy of file 69 from computer #2 to
computer #1 all will be well.

Test theory #3:
I copied the 'uncorrupted' copy of file 69 to computer #1 -
'uncorrupted file does not work - Same problem.

Conclusion from the test for theory #3: There is a problem unique to
Computer #1
- perhaps files moved to computer #1 inherit the problem
- perhaps a windows update issue
- perhaps an office update issue
- perhaps an issue from loading MS Office 2003 on computer #1
- However, I first noticed hints of the problem several days before I
performed windows and office updates and before I loaded MS Office
2003. At that time I had no time to look into it (I was in the middle
of some other task). I noticed that it took several seconds (maybe 10)
for the button event to work (now they don't work at all)

== Theory #4 ==
There is some unique problem with the installation of office on
computer #1 that recently expressed itself.

Test theory #4:
Move files from computer #1 to computer #2.
Results: all files move from computer #1 to #2 (66, 67, 68 & 69) work!

Conclusion from testing theory #4: There is a problem unique to
Computer #1

== Theory #5 =
There is some unique problem with the installation of office on
computer #1 (another test)

Test theory #5:
Copy various files from both computer #1 & #2 to a third computer
(computer #3 - Win2K Pro Desktop)

Results: Computer #3 behaves identical to computer #1.
(Computer #1 WinXP Pro Workstation) (Computer #3 Win2k Pro Desktop)

Conclusion: The problem is NOT unique to computer #1. Operating
systems are different but office versions are the same. Computers
share the same behavior so the office installation have been exposed
to some common change.

However, That is not true. Computer #3 is largely unused - for several
months it has not had Office updated (or anything else for that
mater). Whereas both computer #1 & 2 have been kept up to date and
often exchange and share files.

I am all out of theories or explanations and have no solution.

Anyone have any ideas?

Nov 12 '05 #2

P: n/a
I plan to solve my problem in the same way you did.

You said you had the idea this thing is related to Office2000
Servicepack 3 that you recently installed ... I don't think that's it
because SR-3 has been out for quite some time, I've had it installed
when it became available. I would expect there it would be much more
well known problem if that were the case. I have SR-3 installed on all
my computers and it is not a consistant problem among them - even for
the same OS.

Thank you for your reply.
Doug

"Arno R" <ar****************@tiscali.nl> wrote in message news:<3f**********************@dreader2.news.tisca li.nl>...
Hi Doug,
Maybe this is the same problem as I have? Look at thread 'Strange corruption A2k'
I just 'solved' it by opening another form (sort of a greeting) as my startupform.

In this form I don't use ANY code, but a macro in the on-timer-event to close the form and open my
Mainform again.
If I use code to do the same then the code is not fired ... (or maybe code is not 'found' = same
problem)
Anyhow this 'works' for me now.

Did not find the 'real' cause or a 'real' solution.
I have the idea this thing is related to Office2000 Servicepack 3 that I recently installed ...
--
Arno R
"Douglas Buchanan" <db*********@comcast.net> schreef in bericht
news:db*************************@posting.google.co m...
Buttons don't work if form is opened on startup
A2k
If 'frmMain' is set to open by default at startup none of the buttons
work.
If 'frmMain' is opened from the database window then all the buttons
work.

The form's name ('frmMain') is selected from in the Startup dialog
box.

Here is what is so very strange about this situation.
(read carefully)
This is a recent occurrence. It worked flawlessly a week ago.

Background:
I'm in the habit of versioning applications during development so I
can go back to previous level of development. At each new juncture I
increment a number in the filename. All versions were working
perfectly when I left them, including the current version #69.

== Theory #1 ==
File 69 got corrupted when I last worked on it.

Test theory #1:
Look at other versions or copies of the file to see if the behavior is
unique to the one file

Open previous versions.
I checked version 68 and then 67 - The problem present.
I checked version 66 - No problem with this file.
(The mystery deepens)

Conclusion to test for theory #1:
A corruption took place in previous files but I some how filed to
notice it until now. (I know this isn't true, but I need a theory.)

== Theory #2 ==
Open a copy on a computer that had a copy of the latest file #69 that
I had open last week.

Test Theory #2
Open a previously copied file 69 existing on another computer (#2)
(computer #1 - WinXP Pro Workstation) (computer #2 - WinXP Pro Laptop)

A week ago I demonstrated the application to my customer on my laptop
- there was no problem with that copy at the time.

So... I fired up the laptop opened the previously working copy of the
same version 69 - Worked.

Conclusion from the test for Theory #2: I have several corrupted files
on computer #1 and one uncorrupted file on computer #2

== Theory #3 ==
If I restore the uncorrupted copy of file 69 from computer #2 to
computer #1 all will be well.

Test theory #3:
I copied the 'uncorrupted' copy of file 69 to computer #1 -
'uncorrupted file does not work - Same problem.

Conclusion from the test for theory #3: There is a problem unique to
Computer #1
- perhaps files moved to computer #1 inherit the problem
- perhaps a windows update issue
- perhaps an office update issue
- perhaps an issue from loading MS Office 2003 on computer #1
- However, I first noticed hints of the problem several days before I
performed windows and office updates and before I loaded MS Office
2003. At that time I had no time to look into it (I was in the middle
of some other task). I noticed that it took several seconds (maybe 10)
for the button event to work (now they don't work at all)

== Theory #4 ==
There is some unique problem with the installation of office on
computer #1 that recently expressed itself.

Test theory #4:
Move files from computer #1 to computer #2.
Results: all files move from computer #1 to #2 (66, 67, 68 & 69) work!

Conclusion from testing theory #4: There is a problem unique to
Computer #1

== Theory #5 =
There is some unique problem with the installation of office on
computer #1 (another test)

Test theory #5:
Copy various files from both computer #1 & #2 to a third computer
(computer #3 - Win2K Pro Desktop)

Results: Computer #3 behaves identical to computer #1.
(Computer #1 WinXP Pro Workstation) (Computer #3 Win2k Pro Desktop)

Conclusion: The problem is NOT unique to computer #1. Operating
systems are different but office versions are the same. Computers
share the same behavior so the office installation have been exposed
to some common change.

However, That is not true. Computer #3 is largely unused - for several
months it has not had Office updated (or anything else for that
mater). Whereas both computer #1 & 2 have been kept up to date and
often exchange and share files.

I am all out of theories or explanations and have no solution.

Anyone have any ideas?

Nov 12 '05 #3

P: n/a
Hi Doug,
Maybe if you need a 'real' solution: Look at thread 'Strange corruption A2k'
My problem was a kind of corruption in the A97 mdb that was 'transferred' to A2k by the conversion.
Still don't know how and what but I 'really' got it solved now.

Did you try SaveAsText/LoadFromText yet ?
Good luck,

Arno R
"Douglas Buchanan" <db*********@comcast.net> schreef in bericht
news:db*************************@posting.google.co m...
I plan to solve my problem in the same way you did.

You said you had the idea this thing is related to Office2000
Servicepack 3 that you recently installed ... I don't think that's it
because SR-3 has been out for quite some time, I've had it installed
when it became available. I would expect there it would be much more
well known problem if that were the case. I have SR-3 installed on all
my computers and it is not a consistant problem among them - even for
the same OS.

Thank you for your reply.
Doug

"Arno R" <ar****************@tiscali.nl> wrote in message

news:<3f**********************@dreader2.news.tisca li.nl>...
Hi Doug,
Maybe this is the same problem as I have? Look at thread 'Strange corruption A2k'
I just 'solved' it by opening another form (sort of a greeting) as my startupform.

In this form I don't use ANY code, but a macro in the on-timer-event to close the form and open my Mainform again.
If I use code to do the same then the code is not fired ... (or maybe code is not 'found' = same
problem)
Anyhow this 'works' for me now.

Did not find the 'real' cause or a 'real' solution.
I have the idea this thing is related to Office2000 Servicepack 3 that I recently installed ...
--
Arno R
"Douglas Buchanan" <db*********@comcast.net> schreef in bericht
news:db*************************@posting.google.co m...
Buttons don't work if form is opened on startup
A2k
If 'frmMain' is set to open by default at startup none of the buttons
work.
If 'frmMain' is opened from the database window then all the buttons
work.

The form's name ('frmMain') is selected from in the Startup dialog
box.

Here is what is so very strange about this situation.
(read carefully)
This is a recent occurrence. It worked flawlessly a week ago.

Background:
I'm in the habit of versioning applications during development so I
can go back to previous level of development. At each new juncture I
increment a number in the filename. All versions were working
perfectly when I left them, including the current version #69.

== Theory #1 ==
File 69 got corrupted when I last worked on it.

Test theory #1:
Look at other versions or copies of the file to see if the behavior is
unique to the one file

Open previous versions.
I checked version 68 and then 67 - The problem present.
I checked version 66 - No problem with this file.
(The mystery deepens)

Conclusion to test for theory #1:
A corruption took place in previous files but I some how filed to
notice it until now. (I know this isn't true, but I need a theory.)

== Theory #2 ==
Open a copy on a computer that had a copy of the latest file #69 that
I had open last week.

Test Theory #2
Open a previously copied file 69 existing on another computer (#2)
(computer #1 - WinXP Pro Workstation) (computer #2 - WinXP Pro Laptop)

A week ago I demonstrated the application to my customer on my laptop
- there was no problem with that copy at the time.

So... I fired up the laptop opened the previously working copy of the
same version 69 - Worked.

Conclusion from the test for Theory #2: I have several corrupted files
on computer #1 and one uncorrupted file on computer #2

== Theory #3 ==
If I restore the uncorrupted copy of file 69 from computer #2 to
computer #1 all will be well.

Test theory #3:
I copied the 'uncorrupted' copy of file 69 to computer #1 -
'uncorrupted file does not work - Same problem.

Conclusion from the test for theory #3: There is a problem unique to
Computer #1
- perhaps files moved to computer #1 inherit the problem
- perhaps a windows update issue
- perhaps an office update issue
- perhaps an issue from loading MS Office 2003 on computer #1
- However, I first noticed hints of the problem several days before I
performed windows and office updates and before I loaded MS Office
2003. At that time I had no time to look into it (I was in the middle
of some other task). I noticed that it took several seconds (maybe 10)
for the button event to work (now they don't work at all)

== Theory #4 ==
There is some unique problem with the installation of office on
computer #1 that recently expressed itself.

Test theory #4:
Move files from computer #1 to computer #2.
Results: all files move from computer #1 to #2 (66, 67, 68 & 69) work!

Conclusion from testing theory #4: There is a problem unique to
Computer #1

== Theory #5 =
There is some unique problem with the installation of office on
computer #1 (another test)

Test theory #5:
Copy various files from both computer #1 & #2 to a third computer
(computer #3 - Win2K Pro Desktop)

Results: Computer #3 behaves identical to computer #1.
(Computer #1 WinXP Pro Workstation) (Computer #3 Win2k Pro Desktop)

Conclusion: The problem is NOT unique to computer #1. Operating
systems are different but office versions are the same. Computers
share the same behavior so the office installation have been exposed
to some common change.

However, That is not true. Computer #3 is largely unused - for several
months it has not had Office updated (or anything else for that
mater). Whereas both computer #1 & 2 have been kept up to date and
often exchange and share files.

I am all out of theories or explanations and have no solution.

Anyone have any ideas?


Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.