--

--
Mike

--

--

As I mentioned, the bExcelAvailable() function resides in a separate module
(mFunctions.bas) where all my other test functions are stored. It was added
to my post only to demonstrate late binding open/close (,the latter being the
subject of this thread). Thus, the late binding test occurs in another
module; the early binding code is used only after confirmation is made. This
is done in the startup procedure because it's all this FrontLoader does.
Unless I misunderstand you about this, it is the understanding I have from
Rob as to how to use this project.

<AFAIK>I do use it in the context Rob intended it be used. In fact, in the
case of my version of the FrontLoader that I posted here, I have no intention
of using the tested instance. I admit the first version wasn't so clear about
that but the revised version makes this very apparent. The test just sets the
startup parameter bHasExcel which, in this case, is the only prerequesite for
continuing. Only after all other tests determine conditions are 'good to go'
do I create the instance I intend to use.

What you suggest is that I leave the test instance running. I agree with
your point in the context you're implying, which is  immediate use. That is
never my intention in a FrontLoader. This means I would have to add more code
to Sub Main() to destroy it if shutdown is neccessary by results of the
subsequent pre-start tests. It's six-of-one or half-dozen-of-another then,
isn't it? But since the function already exists for its intended purpose then
it makes sense to me to use it that way. They're self-contained tests. They
don't impede performance or require any maintenance. That's why they are
designated as 'test functions' and stored in my mFunctions.bas module. In
some cases, I may test for several MSO apps regardless of which one I use as
my app platform.

Please understand I make no contest that you are correct in your assertion
it isn't necessary to destroy the test instance. I also see that the Sub
Main() procedure could be easily revised to accomodate your suggestion. I've
never looked at this project beyond using it (almost) "as is" given its
source, but you can trust I will certainly discuss it with Rob. Often things
require a second set of eyes to make improvements beyond what the first set
of eyes could see. I know Rob and I both are receptive to this and I will
bring this to his attention.

p.s.: I suppose I should rename that module mTestFunctions.bas so it more
properly complies with my naming conventions. -It's a relic from early days
of getting my feet wet with VBA when I didn't know anything about naming
conventions.
--

Having the group of tests available in another module just facilitates the
ease of using them 'on demand' in a consistent fashion, without worry about
cleaning up if subsequent tests indicate a shutdown. Your noting of my
omission to check for the existence of my XLA file just defers the need of
any instance even further. The app license and registration check could be
lengthy depending on what user inputs may be required.

In other apps (VB/VBA), the MSO group is tested according to app useage.
This is also done at startup so I can set my AppState global parameters to
reflect what app features will be made available to the user. This determines
the .Enabled, .Visible, or .Locked state of respective menus/controls.
Usually, I will notify the user as to what/if any/why features are not going
to be available during the current session.

I think the reason for using early binding in the Sub Main() routine is so
intellisense would be available. I haven't looked at this in any other
context, otherwise. Although I don't see a problem with this, I'll ask Rob
why this is done this way! Late binding works equally well<IMO>, and which is
why I stated in my OP that binding wasn't an issue to the OP's code failing.
--

I agree with you about the VBA context. I avoid this by testing in the
FrontLoader.exe or by using a VB6.DLL in VBA apps. Although my preference is
to test in the FrontLoader and pass the parameters to the running instance,
not all my apps use a FrontLoader yet (unfortunately). I admit the DLL route
can be a bit tricky, but it is definitely safer<IMO> than setting refs in the
VBA app. The startup tests, therefore, allow me to restrict user access to
features that automate unavailable MSO apps. I'm aware that the DLL itself
could trigger the same behavior if it were "MISSING" in the refs. In this
case, startup would notify the user to reinstall.

It's unfortunate that VBA doesn't manage DLLs like VB6 does, in that they
must always be properly registered with the OS. I like the idea that VB6 apps
don't require this!<g>

That said, the FrontLoader approach makes more sense to me! The more I learn
about VB6, using MSO as a platform makes even less sense to me!<g>
--

I like the simplicity of your code sample. Very nice! I see what you mean by
moving things out of my startup procedure because I generally follow this
example. Again, I gave it no thought considering the source and so was
content to use it "as is".

I'm guessing that your useage of Excel (or the other MSO apps) is quite
different than mine, where the VB6 app is the main application and is only
using MSO apps as needed, on demand (if installed). In my case, Excel is the
host for the main application, VB6 is used as a fontloader to, or in-process
component of, the XLA (Excel actually). I will always want a clean instance
that contains only workbooks/addins used by my app. (my apps support
'plugins' and so may open other XLA files on startup) That doesn't dismiss
the fact that the user may open other workbooks in the same running instance,
so shutdown needs to take this into account and handle it appropriately.
Since it does not interfere with a default instance the user may be working
in before starting my app, there's no compromise to that instance.

In the case of dictator apps, the Excel instance is entirely locked down to
only permit app-specific functionality. In most cases, the user has no idea
they are actually working in Excel and therefore wouldn't likely even think
to try to open a workbook (assuming they could find a way that would allow
them to). In fact, even if they tried 'dropping' a file into the UI my app
could close it immediately if it was not a valid app document.
--

Please accept my thanks for your contribution to my learning process. This
is ever-ongoing. Please know I sincerely appreciate the time and effort you
put into addressing these issues. I am most grateful for this opportunity to
learn from you!

Kind regards,
Garry