Can you please write me a small code where it may be affected of your second
Ummm... I'm not sure I can actually do that... I'll give it a shot.
Dim strModName as string
'Get the Module name form MSys
strModName = DLookup("field?", "Msys...", "field? = somemodule"
(i'm not sure the exact syntax of the MSys tables... never really played
around with them)
Then you would have to use that module name somewhere else in your
application... I say it shouldn't be an issue because I can't image what you
might ever need to do using a module name. I can't even think of an obscure
example.
The only other way this may be an issue... I *think* I'm recalling this
correctly... is if you change the module name in an external library (be it
mdb or mde) and use the module name to call functions from your normal
frontend. I'm not positive this is possible (to call using the module name),
but I think it may be.
For example:
an library named libCmnUtil.mdb
has a module named modStringManips
with a function named CapFirst()
from your main project, you have a reference set to libComUtil.mdb so you
can access those functions. From the normal project, you happen to fully
disambiguate the function call to libCmnUtil. Like so...
strName = libCmnUtil.modStringManips.CapFirst(strName)
I'm pretty sure this is a valid syntax, though I may be mistaken.
Alternatively, you could use:
strName = libCmnUtil.CapFirst(strName)
Anyway, if you happen to have code like the first lib example, you would
need to update the hardcoded module name. But there's two reasons that this
shouldn't be a problem either...
1) There is no requirement whatsoever to disambiguate the module name,
because there can never be two public functions in the same project with the
same name
2) If you're using an external reference, by the time you implement the
reference your library db needs to be fully up to snuff anyway, because any
changes to that library project are going to mess up your works anyway,
whether it be a module name or renaming an argument in an existing function
(this isn't entirely true... there is a way to do it, but it's a bit off on a
tangent so I won't get into it)
I suppose one other way that this may make a difference is if you plan to
manipulate the code in your project programmatically. This is not easily
done and most people would have no use for it other than to make some addin's
(like MZTools) to help the development process. I *assume* that using this
type of programming you would need to reference a module name, but I've never
actually done this so I wouldn't know for sure. There may very well be a way
to get this information enumerated, so you can use an index rather than a
name... not sure.
So unless you...
a) use the name of the module somewhere in your code (no reason to... so it
shouldn't be an issue), or
b) use the project in question as an external reference library, or
c) programmatically alter the code in the project you want to change the
module name in
.... this should not ever be an issue. Upon scraping the dark and dusty
corners of my mind, this is all I can come up with, and all three of them are
pretty farfetched to begin with.
Make a test copy and try it there. You really should have no troubles at
all with it (like I said, I do it often... on projects being built from the
ground up as well as ones that have already been fully implemented).
(to get back on the external library subject, the reason changing the module
name shouldn't be an issue is that because every single time you change
*anything* in an externally referenced .mde file, you need to redistribute
that library, and re-reference it fromany projects that reference it. You
can't so much as add a blank line to an mde library and continue to use it
without re-referencing it (an mde library gets a brand new GUID every time
it's compiled, and the link between the main and library projects are based
on GUIDs). The rules do change a little bit for an mdb file... mdb's you can
add additional (optional) arguments or functions (as long as you don't remove
anything previously there) without having to redistribute. An mdb keeps the
same GUID. But really... if you're playing around with stuff like this
you're being very very careful about *everything* you're doing, and double
and triple checking everything and not taking any chances at all, right??
hth
--
Jack Leach
www.tristatemachine.com
"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
