Hiding Application or a Worksheet takes away the ability to use Application properties

I can't figure out why this is 'useful'. I'm trying to get my app to run in what looks like a stand-alone manner (ie no Excel visibility at all). I'm hiding the window, and if there is only the one workbook open, then I'm hiding the application.

However, when I do this the availability of the application to VBA disappears!

If I want to hide the application from the user, it's probably because I want to do something with that application, right? So why would MS think it was constructive to hide all the application properties?

Can anyone come up with a reason why this would be a good idea? (Seriously, I can't figure it out, and I'd love to be educated).

Tony

Thanks, Winon,

I understand what you're describing, what I can't get at is what sort of business sense it makes to release a product that behaves like this.
I want to be able to manage the total environment, free of the possibility of a user making a well-intentioned if ill-advised change. The smart way to do this is to remove the UI of Excel. The VBE is not really hidden (after all, there's a form being displayed, right;-)

I've attached the application. The procedure that does the nasty bit is AppInit, in ThisWorkbook. SecLogin is a form that provides logon security via a different app (also under re-development in parallel with this app), which uses a completely different workbook.

The problems are manifested at a lower level of code, inside the CRAGConsultation form code, where all of the event handlers need to set and reset Application.EnableEvents. For that to work, I need the Application object to be available to me. And, of course it is available to me, because it's running my code! It just won't let me do anything to it. Like I said, I just don't see the business sense.

I suppose - dons thinking cap - that I could abstract Application.EnableEvents and fake it with MyEvents or something like that, but that looks and feels like a kludge of the stickiest type, and at any rate it would really mess-up my Object Model.

Here's AppInit:

Please Login or Register  to view this content.

And here's a typical event handler, showing how I use Application.EnableEvents:

Please Login or Register  to view this content.

You mentioned that there may be other ways of accomplishing what I want. One way that had occurred to me is to use my own substitute and work with that (MyEvents, or some such).
Other than the fact that this would really screw up my existing development framework, it doesn't actually do what I want it to, so I'm still vulnerable to an event somewhere getting out of control and munging the whole environment.

Yes - and the first time I saw that hidden Click event cropping up after I typed a character into a combo-box, I realized how unrestrained MS is with these things!

Let me know if there's a better way of doing this - and I'd still love to hear a good business rationale for this type of behavior!

Tony

Removing it altogether is obviously a possibility! (Incidentally, stepping through AppInit and stopping after the first .Visible will restore things ;-)

So, you see my problem (and no doubt, feel my, er, pain). But can you imagine any conceivable business value from this?

I'm stumped.

For now I'll go back to the way I was doing things, but it sure would be nice to 'get rid of' Excel and just leave my app :-(

Tony