I would like to prevent my ActiveX EXE from starting by double-clicking
it in Windows Explorer.
Only the main app that instantiates the ActiveX EXE should do this.
How do I prevent this?
The only crude way I can think of is to start a timer in the Initialize
event and if a parameter is not set by the timeout then it is not the
main app that is starting it.  But there has to be a more sophisticated
method.

Under Properties>Component, what do you have "Start Mode" as?  IIRC, if you
tick it to ActiveX Component, stand alone startup shouldn't be an issue.

After serious thinking Kevin Provance wrote :
Startup object is set to none.
Start mode is set to ActiveX component.
And yet it starts and displays a form.
I have to use Process Explorer to Kill.

Show quote Hide quote Can you post some example code that demonstrates that?

David

On 10/08/2010 23:15, BeeJ wrote:
It will exit immediately unless you do something in the Sub Main.
If you want to show a message, and exit, do something like:
   If App.StartMode = vbSModeStandalone Then
     MsgBox "This can not be run standalone"
   End If

Dee Earley formulated the question :
Show quoteHide quoteBut there is no sub main.
And the ActiveX EXE is starting.
The entry class has a startup call to a module where a form is opened.

So it looks like even with the parameters set as mentioned in a
previous post, the ActiveX still opens.

Maybe i can try the App.StartMode and see how it is starting and then
not call the startup and just drop thru.

Well, that answers it.  If there is no Sub Main, VB automatically loads the
default form at startup.

Remedy:  Add a module, add Sub Main and use Dee's code, or don't add a thing
if your AX EXE has no stand alone option.  If nothing is in sub main, double
clicking the EXE will run through sub main and exit.

Running Dee's code from Form_Load *would* work, but then you run into
problem unloading a form from it's load code, which can be a PITA.  Using a
Sub Main is better, and standard.

- Kev

Kevin Provance explained :
Show quoteHide quoteSo it seems there are two startup modes for my ActiveX EXE.
And I need to set the start up as Sub Main? even though it is
instantiated by a main app and the main app directly references the
ActiveX.Entry class, the Sub Main may or may not run (assuming it runs,
but if empty will do nothing).


1) instantiated by my main app.  Sub Main is a do nothing.
2) stand alone, Sub Main runs and falls through since it is the
startup.

Still a little confused but I am getting there and will try different
scenarios to see what happens.

There's no Sub Main in an ActiveX EXE. It's
Class_Initialize. And you shouldn't be showing
a form there. The EXE is supposed to be providing
functions to the caller. Class_Initialize should only
have necessary setup ops, if anything. Write a
sub or function to show the form. If you need to
prevent it running except by your software you could
write some kind of Init sub:

Private CallValid as Boolean

Private Sub Class_Initialize()
  CallValid = False
End Sub

Public Sub Init(iCode as long)
  If iCode = 12345 then CallValid = True
End Sub

With that you can just not respond to any
functions if CallValid <> True.


Show quoteHide quote

Mayayana explained :
There sure can be... Do you actually know vb6?

That is one of an activex exe's primary functions, yes - but creating
an activex exe as a client app is the classic way to get threading
behavior in VB6...  Again?  Do you actually know this language?

<snip>

My report back.

Yes, it all works now.

I have a Sub Main added.  I make that the startup object.
I have all the other ActiveX EXE related flags set as an ActiveX EXE
should.
In the sub main I check to see who is starting it and put up a MsgBox
if it is a stand alone attempt.  This is optional but I like it.
So if a user click on the ActiveX EXE a message box admonishes.

When it is instantiated as an ActiveX EXE from the main app, the sub
main is dropped through (see Dee's code) and the class interface is
active and functional.

That was a learning curve of great heights for me but worth it cause I
learned something new and interesting.

In one ActiveX EXE i show a form by calling a startup from initialize. 
That seems OK.
In other ActiveX EXEs i have no forms.  They all work.
And I finally got them to all close properly and leave nothing behind.

But most important, all the timing has now smoothed out and looks good.

Thanks for all who directly helped and those who, although off a
little, did make me think harder.  It all works together and I squeezed
out something that works.

I now consider myself an ActiveX EXE expert (sort of).
I am writing up a how to article.  Wonder if anyone will be interested.
Oh well, I like putting my thoughts together in one place.
Why, cause in a couple of weeks I will have to go back and read my
article to figure out how to do it again.

On 12/08/2010 02:07, BeeJ wrote:
Show quoteHide quoteAhh, that'd be useful, I'm no good at writing articles that make sense
to anyone bar me..

<plug>
I'll happily offer it a home on my VB wiki at:
http://hashvb.earlsoft.co.uk/
</plug>

Show quote Hide quote Am I missing something? I can't dublicate that behavior. If I compile an
activex.exe with 1 class, 1 form and 1 module with sub main, Double clicking
the file does not show a form, does not fire class intialize, does not run
sub main and does not show up in Task Manager. Showing a form at start up is
not even an option.

David

On 12/08/2010 11:44, David Youngblood wrote:
Show quoteHide quoteThat is how it should be (If you'd told it not to use Sub Main).
I don't know why BeeJ's form was being shown.

After serious thinking Dee Earley wrote :
Show quoteHide quoteThis is without a Sub Main.  i.e. startup object is set to none.
In class_initialize of the entry class that gets instantiated by the
main app, I call a sub in a module that opens a form.  I did this
rather than to have to call a sub in this class from the main app.

Dee Earley expressed precisely :
Show quoteHide quoteI should say, there was no Sub Main and the startup object was set to
none.

It now seems that the ActiveX EXE has two ways of starting now with the
current implementation of a Sub Main and a startup object set to Sub
Main - as a main app instantiation like ActiveX.Entry and as a stand
alone.
I now still have the Class_Initialize call to a module sub that opens a
form but the form only opens when the ActiveX EXE is instantiated by
the main app.  As a stand alone it pops up the MsgBox.  so all is good.

David Youngblood submitted this idea :
Show quoteHide quoteThe behavior is when there is NO Sub Main and the startup object is set
to none and the Class_Initialize has a call to a module to open a form.

Show quote Hide quote Yes, I understood what you said. But what I'm saying is, to my knowledge
(and testing) it isn't so. As I said, I can not duplicate the issue.
Class_Initialize does not fire when the ActiveX Exe is ran from explorer.
That's why I asked for code to try to duplicate the problem. I glad to hear
that you to got it working though.

David

dwy wrote :
Show quoteHide quoteAh.  I was thinking the other direction.
I see what you say.  But that is exactly what happens.
Now I am curious as to what is going on.
I had no startup object and no sub main.  Let me look at the code again
and see.  unfortunately i do not know how to step the code from a stand
alone startup to see where it is going.  and i do not want to spend the
time adding MsgBox all over to trace.  thinking ... (that is more fun
anyway).

First, let me disclaimer this by saying everything I learned about ActiveX,
DLL, EXE, COM, etc I learned by reading and rereading on several occasions
Dan Applemans "Developing COM/Active X Components with Visual Basic 6".  If
you have the money, I *highly* recommend this book.  Along with numerous
examples, Appleman writes the history and detailed explainations of AX and
COM in terms that the VB programmer can easily understand (which is why I
did not say layman, since a basic understanding of VB is required).

As far as BeeJ's issue, I don't know if I understand why exactly his project
was doing what it was doing...since I did not have the actual project and
code in front of me.  All I know, and shared and about the siutation is what
I learned - and do with every project I've ever written is the Sub Main
method.  Every program has an entry point, which should be - IMO - a
prodecure in a module, regardless the language.  I am not a fan of loading a
form to start a project.  Again, IMO, it's sloppy.  Plus, there are more
freedoms to do other things with Sub Main, as BeeJ has probably learned.

Dee was right about the code starting from Class_Initialize, when accessing
the project via a reference.  That is the entry point (or the one VB let's
you see...what goes on in the background is something else, as explained in
Appleman's book, and an entirely different subject) as an AX object.  The
alternative way to start the application is via explorer.  Since it's now
starting as an EXE, the entry point would be SubMain, or whatever is set as
the Startup Object (not to be confused with StartUp Mode).  Since I never
use anything else but Sub Main, BeeJ's problem has never been a problem I
experienced.  So instead of spending a lot of time trying to figure out -
remotely even - why B's project was doing what it was doing, it seemed a
better alternative to tell him how to do it what I have perceived as the
correct way, and use Sub Main which fixes the entire problem and frees the
application up to display messages, load objects, or not load
them...whatever.

I should point out that Start Mode (AX versus Standalone) is for design time
only.  Once compiled, the mode is determined by how the application is
accessed (starting as EXE or referenced as component).  Put another way,
once compiled, the setting is moot.

For more info, if you have the MSDN library installed with your VB setup,
search for the following chapters:  "Creating an ActiveX exe component" and
"General principles of component design".  Examples available.  Plus,
APpleman's book if you can afford it.  Aftermarket copies might be available
for less on amazon...if you go that route, make sure you get the CD that
comes with!!!

If you are developing ActiveX components, the Component Tools Guide should
be your closest friend...

http://msdn.microsoft.com/en-us/library/aa240845(VS.60).aspx

How to clone an object
ini in app.pth works for xp, best practice for Vista/W7?
compile error Only udts defined in public object modules can be coerced ...
Class Access
VB6-rotate form 90 degrees?
Make a Backup
Error 32765
Reading keyboard's key names (Internalization)
Cleanup remnants
RegClean Revisited