Compile menu item is grayed out after decompile command

[rdemyan via AccessMonster.com]

I have a launcher program that creates the shortcut to open my application
using the Shell command. On the form I have a decompile checkbox that I can
conveniently use to decompile my program. I follow the protocol described
by Allen Browne.

Opening my program in decompile mode has always functioned flawlessly.

But I recently converted my program to A2002-2003 format from A2000. Now
when I try to decompile using the launching program code, the "Compile" menu
item is grayed out???!

Any ideas on why this is happening and how do I fix it.

TIA.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200608/1

[Nick 'The Database Guy']

Hi Tia,

I seem to be getting the same problem!

Nick

Does this happen when you open the database from the command prompt
with the
rdemyan via AccessMonster.com wrote:

I have a launcher program that creates the shortcut to open my application
using the Shell command. On the form I have a decompile checkbox that I can
conveniently use to decompile my program. I follow the protocol described
by Allen Browne.

Opening my program in decompile mode has always functioned flawlessly.

But I recently converted my program to A2002-2003 format from A2000. Now
when I try to decompile using the launching program code, the "Compile" menu
item is grayed out???!

Any ideas on why this is happening and how do I fix it.

TIA.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200608/1

[rdemyan via AccessMonster.com]

Hi Nick:

It's actually rdemyan. TIA (thanks in advance).

Actually, it occurred to me that maybe it was a corruption problem. So I
took a recent backup and converted it to A2003 and that seems to be working
okay.

These corruption problems in Access sure are frustrating. I have 170 forms,
120 tables 75,000 lines of code in my app. Now that I have to convert to
A2003, I guess I have no choice but to go through and test everything.
During the conversion, one of my modules lost code, which fortunately was
picked up by compile. But still, this whole thing is a nightmare.

Good luck with your project.

Nick 'The Database Guy' wrote:

>Hi Tia,

I seem to be getting the same problem!

Nick

Does this happen when you open the database from the command prompt
with the

>I have a launcher program that creates the shortcut to open my application
using the Shell command. On the form I have a decompile checkbox that I can

[quoted text clipped - 14 lines]

>Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200608/1

--
Message posted via http://www.accessmonster.com

[David W. Fenton]

"rdemyan via AccessMonster.com" <u6836@uwewrote in
news:6438e473e3fea@uwe:

These corruption problems in Access sure are frustrating.

I've never had much problem with corruption, myself. I think the
"secret" is:

1. turn off COMPILE ON DEMAND.

2. decompile regularly to flush out any problems early.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[rdemyan via AccessMonster.com]

David:

What is Compile on Demand; I've never heard of it. Also, I do decompile
regularly and have it conveniently set up on my launcher as a checkbox.

However, I was going through some older threads and you posted that when one
does a decompile that the startup code should be bypassed. I HAVE NOT been
doing that. Do you still believe that should be done?

Thanks.

David W. Fenton wrote:

>These corruption problems in Access sure are frustrating.

I've never had much problem with corruption, myself. I think the
"secret" is:

1. turn off COMPILE ON DEMAND.

2. decompile regularly to flush out any problems early.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200608/1

[John Mishefske]

rdemyan via AccessMonster.com wrote:

David:

What is Compile on Demand; I've never heard of it. Also, I do decompile
regularly and have it conveniently set up on my launcher as a checkbox.

It's an option in the VBA editor - Alt-F11, Tools, Options, General tab.

--
'---------------
'John Mishefske
'---------------

[David W. Fenton]

"rdemyan via AccessMonster.com" <u6836@uwewrote in
news:643f340f3d209@uwe:

However, I was going through some older threads and you posted
that when one does a decompile that the startup code should be
bypassed. I HAVE NOT been doing that. Do you still believe that
should be done?

Well, I'm not sure exactly what you mean.

If you're *not* bypassing the startup, the decompile may not work.
Consider:

1. if decompile does the decompile and then opens your app. that
will cause the code to recompile, because it has to if you're
opening any code-bearing objects.

2. if the decompile happens *after* the startup routines (which I
don't think it does), it just means you're wasting time waiting for
the startup to run.

I'm pretty sure #1 is the case, according to what I've seen in
testing.

For *all* decompile operations you should bypass startup, because
otherwise, you'll end up with code recompiled. The goal of a
decompile is to rid your MDB of all the compiled code that has
accumulated in layers from use and from compiling during
development. The order of operations is:

1. compact the MDB, bypassing startup.

2. decompile the MDB, bypassing startup.

3. in a different Access instance, compact the MDB, bypassing
startup.

4. compile the MDB.

5. compact the MDB, bypassing startup.

Failing to bypass startup may result in code being compiled before
you want it to be (you don't want anything compiled until Step 4).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[rdemyan via AccessMonster.com]

What you say makes sense. However, every time I decompile and don't bypass
the startup code, the menu item, Compile, in the VB Editor is not grayed out.
I think it would be grayed out if the code had actually compiled successfully
during the startup.

Also, I have noted the drastic reduction in size of my mdb after decompiling
and compacting, strongly suggesting that these binary files were removed.

Still, I'll take your advice because it is easy to implement and removes a
possible variable in the decompile process.

Thanks.

David W. Fenton wrote:

>However, I was going through some older threads and you posted
that when one does a decompile that the startup code should be
bypassed. I HAVE NOT been doing that. Do you still believe that
should be done?

Well, I'm not sure exactly what you mean.

If you're *not* bypassing the startup, the decompile may not work.
Consider:

1. if decompile does the decompile and then opens your app. that
will cause the code to recompile, because it has to if you're
opening any code-bearing objects.

2. if the decompile happens *after* the startup routines (which I
don't think it does), it just means you're wasting time waiting for
the startup to run.

I'm pretty sure #1 is the case, according to what I've seen in
testing.

For *all* decompile operations you should bypass startup, because
otherwise, you'll end up with code recompiled. The goal of a
decompile is to rid your MDB of all the compiled code that has
accumulated in layers from use and from compiling during
development. The order of operations is:

1. compact the MDB, bypassing startup.

2. decompile the MDB, bypassing startup.

3. in a different Access instance, compact the MDB, bypassing
startup.

4. compile the MDB.

5. compact the MDB, bypassing startup.

Failing to bypass startup may result in code being compiled before
you want it to be (you don't want anything compiled until Step 4).

--
Message posted via http://www.accessmonster.com

[David W. Fenton]

"rdemyan via AccessMonster.com" <u6836@uwewrote in
news:644a8d285589d@uwe:

What you say makes sense. However, every time I decompile and
don't bypass the startup code, the menu item, Compile, in the VB
Editor is not grayed out. I think it would be grayed out if the
code had actually compiled successfully during the startup.

The reason it's a *problem* to run the startup code is that only the
code that *runs* is compiled, which means your project is
*partially* compiled (hence the Compile button is still enabled).
And it's partial compiling that leads to the problems:

http://trigeminal.com/usenet/usenet004.asp?1033

Also, I have noted the drastic reduction in size of my mdb after
decompiling and compacting, strongly suggesting that these binary
files were removed.

Well, of course the binary compilation was removed. That's the whole
point.

Still, I'll take your advice because it is easy to implement and
removes a possible variable in the decompile process.

Read the article cited above. The information in that article is
essential to understanding why decompiling is necessary (and why you
want to turn off COMPILE ON DEMAND).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Lyle Fairfield]

David W. Fenton wrote:

"rdemyan via AccessMonster.com" <u6836@uwewrote in
news:6438e473e3fea@uwe:

These corruption problems in Access sure are frustrating.

I've never had much problem with corruption, myself. I think the
"secret" is:

1. turn off COMPILE ON DEMAND.

2. decompile regularly to flush out any problems early.

I think the secret is that you write concise code, carefully. 75000
lines in one app????????? C'MON! I don't even know what COMPILE ON
DEMAND is. Probably I won't bother to find out as I haven't had any
(that I can remember) corruption problems over the last ten or twelve
years that I have been doing Access applications.

Oh yeah, the other monster, Spell-Not-On-Demand or whatever it's
called. I leave it totally as default. Has it ever caused me a problem?
Never.

[Lyle Fairfield]

rdemyan via AccessMonster.com wrote:

These corruption problems in Access sure are frustrating.

Have you considered writing better code?

[Tim Marshall]

David W. Fenton wrote:

2. decompile the MDB, bypassing startup.

David, how do you do this? For the other steps, one holds the startup
key down. I've been wondering about this for a major app of mine in
A2K3 in which when I run the decompile (using the /decompile switch on a
short cut) - the decompile ends with my start up form on screen and all
the options (like db window off, etc, etc) in play.

What's the best way to do this? Turn everything back to the defaults in
the Startup menu item and then back to your app? Or is it a simple
matter of just holding the start key when you double clcikc the
decompile short cut?

I realize I could answer my question by trying it, but I'm at home right
now and won't be back at work for a few days...
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertheriumwrote in
news:eb**********@coranto.ucs.mun.ca:

David W. Fenton wrote:

>2. decompile the MDB, bypassing startup.

David, how do you do this? . . .

Know what? That *not* bypassing the startup is likely to result in a
partial recompile after the decompile? Because I know how Access and
VBA work, that's how.

. . . For the other steps, one holds the startup
key down. I've been wondering about this for a major app of mine
in A2K3 in which when I run the decompile (using the /decompile
switch on a short cut) - the decompile ends with my start up form
on screen and all the options (like db window off, etc, etc) in
play.

Then you have an incomplete recompile after the decompile.

Form's with code cannot open until the code has been compiled. Every
module with functions called in the form's code have to be compiled.
But no others. So, if your opening form calls a function in one
standalone module, you'll end up with the form fully compiled and
the single module fully compiled, and the rest uncompiled. And
that's why the compile button is still enabled, because your app is
not fully compiled.

And you've derailed the purpose of decompiling, which is to get a
pristine copy of your MDB with absolutely no compiled code.

What's the best way to do this? Turn everything back to the
defaults in the Startup menu item and then back to your app? Or
is it a simple matter of just holding the start key when you
double clcikc the decompile short cut?

Eh? I have decompile shortcut that just opens Access in decompile
mode. I then choose the MDB I want to decompile and before clicking
the OPEN or OK button, I hold down the shift key.

That is, just like everywhere else in Access.

I realize I could answer my question by trying it, but I'm at home
right now and won't be back at work for a few days...

You're probably thinking it's harder than it is because you're not
in front of the computer.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Lyle Fairfield]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in
news:Xn**********************************@127.0.0. 1:

Form's with code cannot open until the code has been compiled. Every
module with functions called in the form's code have to be compiled.

I add this code to a form's module:

Private Sub Form_Activate()
MsgBox Application.IsCompiled
End Sub

I save my changes.

I open the form.

I get:

---------------------------
Microsoft Office Access
---------------------------
False
---------------------------
OK
---------------------------

I close the form.

I open it again.

I get:

---------------------------
Microsoft Office Access
---------------------------
False
---------------------------
OK
---------------------------

I open the form's code module. I click on the Debug Menu item.
The Compile option is enabled. I click it.

I open the form again.

I get:

---------------------------
Microsoft Office Access
---------------------------
True
---------------------------
OK
---------------------------


--
Lyle Fairfield

[Tim Marshall]

David W. Fenton wrote:

>>>2. decompile the MDB, bypassing startup.

David, how do you do this? . . .

Know what? That *not* bypassing the startup is likely to result in a
partial recompile after the decompile? Because I know how Access and
VBA work, that's how.

I think you might have misread me... I didn't ask how you *know*
<whatever>, I asked how do you do this, ie, decompile the mdb, bypassing
startup. 8)
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Tim Marshall]

David W. Fenton wrote:

Eh? I have decompile shortcut that just opens Access in decompile
mode. I then choose the MDB I want to decompile and before clicking
the OPEN or OK button, I hold down the shift key.

That is, just like everywhere else in Access.

That's what I've been doing wrong. The way I've been decompiling was to
create a shortcut with the app name, instead of opening Access in
decompile mode. In all seriousness, that's how I thought it was done
and I'm sure I based it on various posts I've seen here in the past.

Similar to http://www.trigeminal.com/usenet/usenet004.asp?1033

So whenever I've been working on an app, I always create a decompile
shortcut fro that app. Hmmmm.

The way you describe is pretty easy to do, I think. I just never
realized the finer points of what happens as you describe in this last post.

Thanks! 8)
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertheriumwrote in
news:eb**********@coranto.ucs.mun.ca:

David W. Fenton wrote:

>Eh? I have decompile shortcut that just opens Access in decompile
mode. I then choose the MDB I want to decompile and before
clicking the OPEN or OK button, I hold down the shift key.

That is, just like everywhere else in Access.

That's what I've been doing wrong. The way I've been decompiling
was to create a shortcut with the app name, instead of opening
Access in decompile mode. In all seriousness, that's how I
thought it was done and I'm sure I based it on various posts I've
seen here in the past.

Similar to http://www.trigeminal.com/usenet/usenet004.asp?1033

So whenever I've been working on an app, I always create a
decompile shortcut fro that app. Hmmmm.

The way you describe is pretty easy to do, I think. I just never
realized the finer points of what happens as you describe in this
last post.

I'd rather not litter my desktop with unnecessary shortcuts, so I
just have one general-purpose decompile shortcut for each version of
Access.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Tim Marshall]

David W. Fenton wrote:

I'd rather not litter my desktop with unnecessary shortcuts, so I
just have one general-purpose decompile shortcut for each version of
Access.

Yup, I agree (though mine were in the various directories I had for my
apps) - I got rid of a bunch today and now have one general purpose
short cut for exactly this sort of thing. And hurray! I decompiled my
latest large app without firing off the splash form (and consequent APIs
for screen res checking, oracle connections, etc, etc).
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me