How to change conditional compiler constants using VBA?

[Andrew]

I use conditional compiler constants, set through the VBA IDE in
Tools, <projectname> Properties, that I refer to throughout my code to
control which code is used during development, and which during
production. Usually, this only wraps code used to control quitting
the whole app versus just shutting a form, but it can also control
many other things.

However, as part of the build before delivering an update, I have to
remember to change the CC constants, as well as run code to set menu
and command bars for all the forms and reports, remove default project
properties to inhibit user access, recompile, then build a .MDE ready
to deliver.

I'd really like to automate the build, and the one step I can't crack
is setting the CC constant. No, I don't want to set them inline in
the code, nor by using them in a command line in the shortcut to run
the app.

Any ideas?

TIA

Andrew

[david epsom dot com dot au]

> properties to inhibit user access, recompile, then build a .MDE ready

to deliver. I'd really like to automate the build, and the one step I can't crack
is setting the CC constant. No, I don't want to set them inline in
My experience was that MDE's could not see CC constants defined
as project properties in the IDE when the build was scripted using
syscmd 603. Have you tried this? Which version of Access are you
using?

(david)

=========================================
"Andrew" <an**************************@bigpond.com> wrote in message
news:cb*************************@posting.google.co m... I use conditional compiler constants, set through the VBA IDE in
Tools, <projectname> Properties, that I refer to throughout my code to
control which code is used during development, and which during
production. Usually, this only wraps code used to control quitting
the whole app versus just shutting a form, but it can also control
many other things.

However, as part of the build before delivering an update, I have to
remember to change the CC constants, as well as run code to set menu
and command bars for all the forms and reports, remove default project
properties to inhibit user access, recompile, then build a .MDE ready
to deliver.

I'd really like to automate the build, and the one step I can't crack
is setting the CC constant. No, I don't want to set them inline in
the code, nor by using them in a command line in the shortcut to run
the app.

Any ideas?

TIA

Andrew

[Hopeful]

Hi David,

syscmd 603? I know syscmd acSysCmdRuntime (which = 6).

This is running under Access 2k, A2k runtime, and AXP. The .MDE seems to be
handling the CCs no problem, as long as I remember to recompile after
setting them.

Andrew

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...

properties to inhibit user access, recompile, then build a .MDE ready
to deliver.

I'd really like to automate the build, and the one step I can't crack
is setting the CC constant. No, I don't want to set them inline in

My experience was that MDE's could not see CC constants defined
as project properties in the IDE when the build was scripted using
syscmd 603. Have you tried this? Which version of Access are you
using?

(david)

=========================================
"Andrew" <an**************************@bigpond.com> wrote in message
news:cb*************************@posting.google.co m...

I use conditional compiler constants, set through the VBA IDE in
Tools, <projectname> Properties, that I refer to throughout my code to
control which code is used during development, and which during
production. Usually, this only wraps code used to control quitting
the whole app versus just shutting a form, but it can also control
many other things.

However, as part of the build before delivering an update, I have to
remember to change the CC constants, as well as run code to set menu
and command bars for all the forms and reports, remove default project
properties to inhibit user access, recompile, then build a .MDE ready
to deliver.

I'd really like to automate the build, and the one step I can't crack
is setting the CC constant. No, I don't want to set them inline in
the code, nor by using them in a command line in the shortcut to run
the app.

Any ideas?

TIA

Andrew

[david epsom dot com dot au]

appobj.syscmd 603 "sfile1", "sfile2"

is one of the ways of making an MDE from an MDB.

it does not require that you have the mdb as the current
database, which is probably why it looses the conditional
compile constants.

Are you scripting the 'make mde' phase of your build?
If so, which method are you using?

(david)
"Hopeful" <Li**@in.hope> wrote in message
news:7H******************@news-server.bigpond.net.au...

Hi David,

syscmd 603? I know syscmd acSysCmdRuntime (which = 6).

This is running under Access 2k, A2k runtime, and AXP. The .MDE seems to be handling the CCs no problem, as long as I remember to recompile after
setting them.

Andrew

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...

properties to inhibit user access, recompile, then build a .MDE ready
to deliver.

I'd really like to automate the build, and the one step I can't crack
is setting the CC constant. No, I don't want to set them inline in

My experience was that MDE's could not see CC constants defined
as project properties in the IDE when the build was scripted using
syscmd 603. Have you tried this? Which version of Access are you
using?

(david)

=========================================
"Andrew" <an**************************@bigpond.com> wrote in message
news:cb*************************@posting.google.co m...

I use conditional compiler constants, set through the VBA IDE in
Tools, <projectname> Properties, that I refer to throughout my code to
control which code is used during development, and which during
production. Usually, this only wraps code used to control quitting
the whole app versus just shutting a form, but it can also control
many other things.

However, as part of the build before delivering an update, I have to
remember to change the CC constants, as well as run code to set menu
and command bars for all the forms and reports, remove default project
properties to inhibit user access, recompile, then build a .MDE ready
to deliver.

I'd really like to automate the build, and the one step I can't crack
is setting the CC constant. No, I don't want to set them inline in
the code, nor by using them in a command line in the shortcut to run
the app.

Any ideas?

TIA

Andrew

[Andrew]

Ah, that's a useful command.

No, I'd not got as far as scripting the 'Make .MDE'. The steps that I take
as standard are:
0. Update version information using a hidden local table and hidden form,
that then exports a version history text file to include in the set-up
1. run procedure to apply custom toolbars/menubars to forms and reports
(never use macros...uuggh!)
2. run procedure to switch off all database properties that allow the user
to get behind the scenes
3. manually change the CC constant(s)
4. recompile (occasionally I'll precede the whole shebang with a command
line decompile as well to clean out the file)
5. manually run 'Make .mde'

After the 'Make .mde' the app reopens now paying attention to the new CC
constants, and behaving as it should in production.

All the routines are run using an AutoKeys shortcut that calls a single
wrapper routine that starts with a message box to allow you to toggle things
on or off, and passes this on to the other routines. This allows me to get
back in to the mdb to carry on with the next round of work.

The whole lot then gets pulled together with any supporting files, usually
using Inno setup (or the dread P & D wizard for runtime installations until
I can figure out an Inno script for the runtime files). Since it's the .mde
is delivered, of course there's not a load that the user can do should the
stumble across the AutoKeys shortcut, and the message encourages them to
cancel anyhow. The worst that could happen is that they might manage to
break into code, and for the user base I'm dealing with, that's not a
threat!

I've written a small VB app that wraps up the decompile process, and I was
thinking it might be possible to write another to wrap up the entire build
process. So the first step would be to work out how to change the CC
constants, then recompile, then 'Make .mde' all from outside. It would be a
very handy tool if I can pull it off.

Where did you come across the syscmd 603? Do you know of any other
undocumented syscmd tricks?

Here's me asking for all your secrets - sorry! Still, if you don't ask...

All the best,

Andrew

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...

appobj.syscmd 603 "sfile1", "sfile2"

is one of the ways of making an MDE from an MDB.

it does not require that you have the mdb as the current
database, which is probably why it looses the conditional
compile constants.

Are you scripting the 'make mde' phase of your build?
If so, which method are you using?

(david)
"Hopeful" <Li**@in.hope> wrote in message
news:7H******************@news-server.bigpond.net.au...

Hi David,

syscmd 603? I know syscmd acSysCmdRuntime (which = 6).

This is running under Access 2k, A2k runtime, and AXP. The .MDE seems

to be

handling the CCs no problem, as long as I remember to recompile after
setting them.

Andrew

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...

> properties to inhibit user access, recompile, then build a .MDE ready > to deliver.

> I'd really like to automate the build, and the one step I can't crack > is setting the CC constant. No, I don't want to set them inline in

My experience was that MDE's could not see CC constants defined
as project properties in the IDE when the build was scripted using
syscmd 603. Have you tried this? Which version of Access are you
using?

(david)

=========================================
"Andrew" <an**************************@bigpond.com> wrote in message
news:cb*************************@posting.google.co m...
> I use conditional compiler constants, set through the VBA IDE in
> Tools, <projectname> Properties, that I refer to throughout my code to > control which code is used during development, and which during
> production. Usually, this only wraps code used to control quitting
> the whole app versus just shutting a form, but it can also control
> many other things.
>
> However, as part of the build before delivering an update, I have to
> remember to change the CC constants, as well as run code to set menu
> and command bars for all the forms and reports, remove default project > properties to inhibit user access, recompile, then build a .MDE ready > to deliver.
>
> I'd really like to automate the build, and the one step I can't crack > is setting the CC constant. No, I don't want to set them inline in
> the code, nor by using them in a command line in the shortcut to run
> the app.
>
> Any ideas?
>
> TIA
>
> Andrew

[Steve Jorgensen]

On 1 Mar 2004 06:16:38 -0800, an**************************@bigpond.com
(Andrew) wrote:

I use conditional compiler constants, set through the VBA IDE in
Tools, <projectname> Properties, that I refer to throughout my code to
control which code is used during development, and which during
production. Usually, this only wraps code used to control quitting
the whole app versus just shutting a form, but it can also control
many other things.

However, as part of the build before delivering an update, I have to
remember to change the CC constants, as well as run code to set menu
and command bars for all the forms and reports, remove default project
properties to inhibit user access, recompile, then build a .MDE ready
to deliver.

I'd really like to automate the build, and the one step I can't crack
is setting the CC constant. No, I don't want to set them inline in
the code, nor by using them in a command line in the shortcut to run
the app.

Any ideas?

TIA

Andrew

In addition to other comments, I wanted to add something I've learned in my
own coding process. I've had some troubles with precompiler constants, and I
found some alternative schemes I now tend to prefer.

Problems:
1. Sometimes, precompiler conditional code can be really messy, especially
when it overlaps some standard VBA conditional code.
2. Sometimes the editor can get really confused.
3. Sometimes, it messes up Decompile.

Alternatives:
1. Use standard VBA conditions. In most cases, the performance hit is
immesurably small.
2. Create standard and stub versions of optional code, and comment out the
standard or stub version as desired.

[Lyle Fairfield]

"Andrew" <an**************@webster.org> wrote in
news:LG******************@news-server.bigpond.net.au:

Where did you come across the syscmd 603? Do you know of any other
undocumented syscmd tricks?

This is a Klingon discovery. As a real programmer, you would not want to use
it?

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Andrew]

Hmmm.

Make it so.

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

"Andrew" <an**************@webster.org> wrote in
news:LG******************@news-server.bigpond.net.au:

Where did you come across the syscmd 603? Do you know of any other
undocumented syscmd tricks?
This is a Klingon discovery. As a real programmer, you would not want to

use it?

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Andrew]

Hi Steve,

Thanks for joining in.

You've got me thinking. What I want to do is simply flip a flag somewhere,
so that in 'Developer mode' certain code runs (e.g. DoCmd.Close instead of
DoCmd.Quit), while in 'Production mode' other code runs (e.g. DoCmd.Quit
instead of DoCmd.Close). There are usually a couple of other things spread
out around the code, so CC constants seem to provide a one-stop-shop for
turning them all on or off.

However, what I could do, so it can be done from code, is add a Custom
Database Property (or more than one), and flip that at the same time as I'm
running all the other database property code to enable/disable user access
to the clever stuff behind the scenes. Then wrap the conditional code with
a test that checks the state of the property, rather than a load of #If's.
If I was feeling particularly bright, I might make the property an integer
and using bitwise comparison to set/test several values at the same time.

Hmmm.

I'll have to go and experiment.

However, it's late now here in Oz, so I'm going to leave it until tomorrow.

All the best,

Andrew

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:cl********************************@4ax.com...

On 1 Mar 2004 06:16:38 -0800, an**************************@bigpond.com
(Andrew) wrote:

I use conditional compiler constants, set through the VBA IDE in
Tools, <projectname> Properties, that I refer to throughout my code to
control which code is used during development, and which during
production. Usually, this only wraps code used to control quitting
the whole app versus just shutting a form, but it can also control
many other things.

However, as part of the build before delivering an update, I have to
remember to change the CC constants, as well as run code to set menu
and command bars for all the forms and reports, remove default project
properties to inhibit user access, recompile, then build a .MDE ready
to deliver.

I'd really like to automate the build, and the one step I can't crack
is setting the CC constant. No, I don't want to set them inline in
the code, nor by using them in a command line in the shortcut to run
the app.

Any ideas?

TIA

Andrew
In addition to other comments, I wanted to add something I've learned in

my own coding process. I've had some troubles with precompiler constants, and I found some alternative schemes I now tend to prefer.

Problems:
1. Sometimes, precompiler conditional code can be really messy, especially when it overlaps some standard VBA conditional code.
2. Sometimes the editor can get really confused.
3. Sometimes, it messes up Decompile.

Alternatives:
1. Use standard VBA conditions. In most cases, the performance hit is
immesurably small.
2. Create standard and stub versions of optional code, and comment out the standard or stub version as desired.

[Steve Jorgensen]

Let us know how that goes.

On Wed, 03 Mar 2004 13:17:48 GMT, "Andrew" <an**************@webster.org>
wrote:

Hi Steve,

Thanks for joining in.

You've got me thinking. What I want to do is simply flip a flag somewhere,
so that in 'Developer mode' certain code runs (e.g. DoCmd.Close instead of
DoCmd.Quit), while in 'Production mode' other code runs (e.g. DoCmd.Quit
instead of DoCmd.Close). There are usually a couple of other things spread
out around the code, so CC constants seem to provide a one-stop-shop for
turning them all on or off.

However, what I could do, so it can be done from code, is add a Custom
Database Property (or more than one), and flip that at the same time as I'm
running all the other database property code to enable/disable user access
to the clever stuff behind the scenes. Then wrap the conditional code with
a test that checks the state of the property, rather than a load of #If's.
If I was feeling particularly bright, I might make the property an integer
and using bitwise comparison to set/test several values at the same time.

Hmmm.

I'll have to go and experiment.

However, it's late now here in Oz, so I'm going to leave it until tomorrow.

All the best,

Andrew

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:cl********************************@4ax.com.. .

On 1 Mar 2004 06:16:38 -0800, an**************************@bigpond.com
(Andrew) wrote:

>I use conditional compiler constants, set through the VBA IDE in
>Tools, <projectname> Properties, that I refer to throughout my code to
>control which code is used during development, and which during
>production. Usually, this only wraps code used to control quitting
>the whole app versus just shutting a form, but it can also control
>many other things.
>
>However, as part of the build before delivering an update, I have to
>remember to change the CC constants, as well as run code to set menu
>and command bars for all the forms and reports, remove default project
>properties to inhibit user access, recompile, then build a .MDE ready
>to deliver.
>
>I'd really like to automate the build, and the one step I can't crack
>is setting the CC constant. No, I don't want to set them inline in
>the code, nor by using them in a command line in the shortcut to run
>the app.
>
>Any ideas?
>
>TIA
>
>Andrew

In addition to other comments, I wanted to add something I've learned in

my

own coding process. I've had some troubles with precompiler constants,

and I

found some alternative schemes I now tend to prefer.

Problems:
1. Sometimes, precompiler conditional code can be really messy,

especially

when it overlaps some standard VBA conditional code.
2. Sometimes the editor can get really confused.
3. Sometimes, it messes up Decompile.

Alternatives:
1. Use standard VBA conditions. In most cases, the performance hit is
immesurably small.
2. Create standard and stub versions of optional code, and comment out

the

standard or stub version as desired.

[david epsom dot com dot au]

You can make an mde by selecting from the menu, or by using
the syscmd, or by using SendKeys. And you MIGHT be able to
automate the actual menu item, using the menu object:
infinitely better than SendKeys, and that would enable you
to use the CCC's

I got the syscmd constant from the newsgroups (microsoft.public
..access.modulesdaovba): now I pass it on to you :~) I think
that Dan Haught (FMS) is credited with the first documentation
of Syscmd 603. He got it from one of the Microsoft Access
Wizards or from examination of the exe/dll entry points.

Regarding Conditional Compile: It works slightly differently
in A2K than in A97, but after compilation it is much more stable
than using a flag! At least when you are debugging, you know
which branch you are in! Not like a variable, accidentally
cleared during debugging by hitting 'end' on an error message.

And if you use a database property or table value, make sure
there is no code that will accidentally clear it if a transient
variable has the wrong value!
(david)

"Andrew" <an**************@webster.org> wrote in message
news:LG******************@news-server.bigpond.net.au...

Ah, that's a useful command.

No, I'd not got as far as scripting the 'Make .MDE'. The steps that I take as standard are:
0. Update version information using a hidden local table and hidden form,
that then exports a version history text file to include in the set-up
1. run procedure to apply custom toolbars/menubars to forms and reports
(never use macros...uuggh!)
2. run procedure to switch off all database properties that allow the user
to get behind the scenes
3. manually change the CC constant(s)
4. recompile (occasionally I'll precede the whole shebang with a command
line decompile as well to clean out the file)
5. manually run 'Make .mde'

After the 'Make .mde' the app reopens now paying attention to the new CC
constants, and behaving as it should in production.

All the routines are run using an AutoKeys shortcut that calls a single
wrapper routine that starts with a message box to allow you to toggle things on or off, and passes this on to the other routines. This allows me to get back in to the mdb to carry on with the next round of work.

The whole lot then gets pulled together with any supporting files, usually
using Inno setup (or the dread P & D wizard for runtime installations until I can figure out an Inno script for the runtime files). Since it's the ..mde is delivered, of course there's not a load that the user can do should the
stumble across the AutoKeys shortcut, and the message encourages them to
cancel anyhow. The worst that could happen is that they might manage to
break into code, and for the user base I'm dealing with, that's not a
threat!

I've written a small VB app that wraps up the decompile process, and I was
thinking it might be possible to write another to wrap up the entire build
process. So the first step would be to work out how to change the CC
constants, then recompile, then 'Make .mde' all from outside. It would be a very handy tool if I can pull it off.

Where did you come across the syscmd 603? Do you know of any other
undocumented syscmd tricks?

Here's me asking for all your secrets - sorry! Still, if you don't ask...

All the best,

Andrew

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...

appobj.syscmd 603 "sfile1", "sfile2"

is one of the ways of making an MDE from an MDB.

it does not require that you have the mdb as the current
database, which is probably why it looses the conditional
compile constants.

Are you scripting the 'make mde' phase of your build?
If so, which method are you using?

(david)
"Hopeful" <Li**@in.hope> wrote in message
news:7H******************@news-server.bigpond.net.au...

Hi David,

syscmd 603? I know syscmd acSysCmdRuntime (which = 6).

This is running under Access 2k, A2k runtime, and AXP. The .MDE seems to

be

handling the CCs no problem, as long as I remember to recompile after
setting them.

Andrew

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...
> > properties to inhibit user access, recompile, then build a .MDE

ready > > to deliver.
>
> > I'd really like to automate the build, and the one step I can't crack > > is setting the CC constant. No, I don't want to set them inline in >
> My experience was that MDE's could not see CC constants defined
> as project properties in the IDE when the build was scripted using
> syscmd 603. Have you tried this? Which version of Access are you
> using?
>
> (david)
>
> =========================================
> "Andrew" <an**************************@bigpond.com> wrote in message
> news:cb*************************@posting.google.co m...
> > I use conditional compiler constants, set through the VBA IDE in
> > Tools, <projectname> Properties, that I refer to throughout my code to

> > control which code is used during development, and which during
> > production. Usually, this only wraps code used to control

quitting > > the whole app versus just shutting a form, but it can also control
> > many other things.
> >
> > However, as part of the build before delivering an update, I have to > > remember to change the CC constants, as well as run code to set menu > > and command bars for all the forms and reports, remove default

project > > properties to inhibit user access, recompile, then build a .MDE ready > > to deliver.
> >
> > I'd really like to automate the build, and the one step I can't crack > > is setting the CC constant. No, I don't want to set them inline in > > the code, nor by using them in a command line in the shortcut to run > > the app.
> >
> > Any ideas?
> >
> > TIA
> >
> > Andrew
>
>

[Andrew]

Well I did a bit of poking around the web and found the following
(attribution within quote)
#############################
Thanks to Jacques Soudan of www.troisj.com for this compilation of
undocumented constants for the SysCmd function:

SysCmd(7) 'Detects the Access VERSION number

For Access 97:

SysCmd 603, PathMdb, PathMde 'convert MDB -> MDE
SysCmd 602, PathMdb, PathMdb 'compact DB
SysCmd 555 'create MSysIMEX... tables
SysCmd(504, 16483) 'save and compile code
SysCmd(504, 16484) 'save code without compiling
SysCmd(501, i) 'list of references, i = 0, 1, ... n
SysCmd(500) 'count of references

For Access 2000+:

SysCmd 603, PathMdb, PathMde 'convert MDB -> MDE
SysCmd 602, PathMdb, PathMdb 'compact DB
'You must use in this case following method, example:
Dim accApp As Access.Application
Set accApp = New Access.Application
accApp.SysCmd 603, PathMdb, PathMde
accApp.SysCmd 602, PathMdb, PathMdb
Set accApp = Nothing
SysCmd(605, 0) 'convert DB to previous version
SysCmd(605, "C:\Database97.mdb") 'convert DB to previous version
SysCmd(607,"C:\Project1.adp") 'convert DB to ADP project
SysCmd(608, i) '60 tips about Access programming for i=0, 1, ... 60
SysCmd(710, 68486165) 'set Polish keyboard (if installed)
SysCmd(710, 67699721) 'set US keyboard
SysCmd(710, 68748313) 'set Russian keyboard
SysCmd(710, 67634184) 'set Greek keyboard
SysCmd(710, ...) 'set other country keyboard
SysCmd(710,1) 'set next installed keyboard
SysCmd(710,0) 'set previous installed keyboard
SysCmd(711) 'return put keyboard currently
SysCmd(714) 'returns TRUE, if any form, report, macro or module is in design
mode
SysCmd(715) 'returns Build number of MSACCESS.EXE file to check Access
version or e.g. which Service Pack is installed.
From Access Extra newsletter October 2003
############################

So that's covered my save and compile, and make MDE commands. Now I've just
got to make some time to sit down and write out all the code!

Andrew
"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...

You can make an mde by selecting from the menu, or by using
the syscmd, or by using SendKeys. And you MIGHT be able to
automate the actual menu item, using the menu object:
infinitely better than SendKeys, and that would enable you
to use the CCC's

I got the syscmd constant from the newsgroups (microsoft.public
.access.modulesdaovba): now I pass it on to you :~) I think
that Dan Haught (FMS) is credited with the first documentation
of Syscmd 603. He got it from one of the Microsoft Access
Wizards or from examination of the exe/dll entry points.

Regarding Conditional Compile: It works slightly differently
in A2K than in A97, but after compilation it is much more stable
than using a flag! At least when you are debugging, you know
which branch you are in! Not like a variable, accidentally
cleared during debugging by hitting 'end' on an error message.

And if you use a database property or table value, make sure
there is no code that will accidentally clear it if a transient
variable has the wrong value!
(david)

"Andrew" <an**************@webster.org> wrote in message
news:LG******************@news-server.bigpond.net.au...

Ah, that's a useful command.

No, I'd not got as far as scripting the 'Make .MDE'. The steps that I take

as standard are:
0. Update version information using a hidden local table and hidden form,

that then exports a version history text file to include in the set-up
1. run procedure to apply custom toolbars/menubars to forms and reports
(never use macros...uuggh!)
2. run procedure to switch off all database properties that allow the user to get behind the scenes
3. manually change the CC constant(s)
4. recompile (occasionally I'll precede the whole shebang with a command
line decompile as well to clean out the file)
5. manually run 'Make .mde'

After the 'Make .mde' the app reopens now paying attention to the new CC
constants, and behaving as it should in production.

All the routines are run using an AutoKeys shortcut that calls a single
wrapper routine that starts with a message box to allow you to toggle

things

on or off, and passes this on to the other routines. This allows me to

get

back in to the mdb to carry on with the next round of work.

The whole lot then gets pulled together with any supporting files, usually using Inno setup (or the dread P & D wizard for runtime installations

until

I can figure out an Inno script for the runtime files). Since it's the

.mde

is delivered, of course there's not a load that the user can do should the stumble across the AutoKeys shortcut, and the message encourages them to
cancel anyhow. The worst that could happen is that they might manage to
break into code, and for the user base I'm dealing with, that's not a
threat!

I've written a small VB app that wraps up the decompile process, and I was thinking it might be possible to write another to wrap up the entire build process. So the first step would be to work out how to change the CC
constants, then recompile, then 'Make .mde' all from outside. It would be a

very handy tool if I can pull it off.

Where did you come across the syscmd 603? Do you know of any other
undocumented syscmd tricks?

Here's me asking for all your secrets - sorry! Still, if you don't

ask...
All the best,

Andrew

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...

appobj.syscmd 603 "sfile1", "sfile2"

is one of the ways of making an MDE from an MDB.

it does not require that you have the mdb as the current
database, which is probably why it looses the conditional
compile constants.

Are you scripting the 'make mde' phase of your build?
If so, which method are you using?

(david)
"Hopeful" <Li**@in.hope> wrote in message
news:7H******************@news-server.bigpond.net.au...
> Hi David,
>
> syscmd 603? I know syscmd acSysCmdRuntime (which = 6).
>
> This is running under Access 2k, A2k runtime, and AXP. The .MDE seems

to

be
> handling the CCs no problem, as long as I remember to recompile

after > setting them.
>
> Andrew
>
> "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message > news:40***********************@news.syd.swiftdsl.c om.au...
> > > properties to inhibit user access, recompile, then build a .MDE

ready

> > > to deliver.
> >
> > > I'd really like to automate the build, and the one step I can't

crack

> > > is setting the CC constant. No, I don't want to set them inline

in > >
> > My experience was that MDE's could not see CC constants defined
> > as project properties in the IDE when the build was scripted using
> > syscmd 603. Have you tried this? Which version of Access are you
> > using?
> >
> > (david)
> >
> > =========================================
> > "Andrew" <an**************************@bigpond.com> wrote in message > > news:cb*************************@posting.google.co m...
> > > I use conditional compiler constants, set through the VBA IDE in
> > > Tools, <projectname> Properties, that I refer to throughout my code

to

> > > control which code is used during development, and which during
> > > production. Usually, this only wraps code used to control

quitting > > > the whole app versus just shutting a form, but it can also control > > > many other things.
> > >
> > > However, as part of the build before delivering an update, I

have to > > > remember to change the CC constants, as well as run code to set menu > > > and command bars for all the forms and reports, remove default

project

> > > properties to inhibit user access, recompile, then build a .MDE

ready

> > > to deliver.
> > >
> > > I'd really like to automate the build, and the one step I can't

crack

> > > is setting the CC constant. No, I don't want to set them inline in > > > the code, nor by using them in a command line in the shortcut to run > > > the app.
> > >
> > > Any ideas?
> > >
> > > TIA
> > >
> > > Andrew
> >
> >
>
>

[Lyle Fairfield]

"Andrew" <an**************@webster.org> wrote in
news:le******************@news-server.bigpond.net.au:

Well I did a bit of poking around the web and found the following
(attribution within quote)
############################# <snips> 'You must use in this case following method, example:
Dim accApp As Access.Application
Set accApp = New Access.Application
accApp.SysCmd 603, PathMdb, PathMde
accApp.SysCmd 602, PathMdb, PathMdb
Set accApp = Nothing
From Access Extra newsletter October 2003
############################ "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...

I got the syscmd constant from the newsgroups (microsoft.public
.access.modulesdaovba): now I pass it on to you :~) I think
that Dan Haught (FMS) is credited with the first documentation
of Syscmd 603. He got it from one of the Microsoft Access
Wizards or from examination of the exe/dll entry points.

Dan posted SysCmd 608 on September 11 1998.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Andrew]

Hi Lyle,

Are you taking gingko? That's a hell of a memory you've got there!

Andrew
"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

"Andrew" <an**************@webster.org> wrote in
news:le******************@news-server.bigpond.net.au:

Well I did a bit of poking around the web and found the following
(attribution within quote)
#############################

<snips>

'You must use in this case following method, example:
Dim accApp As Access.Application
Set accApp = New Access.Application
accApp.SysCmd 603, PathMdb, PathMde
accApp.SysCmd 602, PathMdb, PathMdb
Set accApp = Nothing
From Access Extra newsletter October 2003
############################

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:40***********************@news.syd.swiftdsl.c om.au...

I got the syscmd constant from the newsgroups (microsoft.public
.access.modulesdaovba): now I pass it on to you :~) I think
that Dan Haught (FMS) is credited with the first documentation
of Syscmd 603. He got it from one of the Microsoft Access
Wizards or from examination of the exe/dll entry points.

Dan posted SysCmd 608 on September 11 1998.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)