The End statement

[MM]

I've been using the following in startup.bas in various apps, no
problem. Then this morning, I ran the app side-by-side (using
manifest) on a test PC (XP) and when I tried to run more than one
instance, I got the critical stop.wav sound and I didn't see the
MsgBox.

Is using End a bad idea?


Public Sub Main()

If App.PrevInstance Then
MsgBox "You are already running this application."
Exit Sub
End
End If

InitCommonControlsVB

frmMain.Show

End Sub

MM

[MikeB]

What is End doing that Exit Sub isn't?


"MM" <kyli...@yahoo.co.uk> wrote in message
news:1uiup85u11784prt5...@4ax.com...

[Larry Serflaten]

MM wrote:

> Is using End a bad idea?

The statements in VB Help about End make it crystal clear why using
End is a bad idea. It will also tell you how VB programs should be
closed....

LFS

[Eduardo]

"MM" <kyli...@yahoo.co.uk> escribi� en el mensaje
news:1uiup85u11784prt5...@4ax.com...

It's clear that the End is never executed there, so it can't cause anything.

[MM]

Ah, good point!

MM

[ralph]

On Fri, 24 May 2013 09:20:09 -0300, "Eduardo" <m...@mm.com> wrote:

>

Except launch endless responses on the evils of End(). <g>

We can proceed with noting that .PrevInstance can be occasionally
unreliable.

Use a Mutex

-ralph

[MM]

Well, I moved the code to Form_Initialize (main form) with an Unload
Me, but it still loaded the program. Maybe it's because I've got a
couple of class modules, plus the following in GenProcs.bas:

Public NoteData As New clsNoteData
Public NotesDict As New Dictionary
Public SharpData As New clsSharpData
Public SharpsDict As New Dictionary

and these variables need to be set to nothing before unload works.

MM

[ralph]

"As New" opens up yet another can of worms.

You can temporarily set an object declared with "As New" to Nothing,
but any subsequent access will cause you to get a 'new' one. For
example, checking if an object Is Nothing. <g>

My advice: Never use "As New" in an App of any complexity. Especially
if you are using a Sub Main() where it is easy to pop in the
intialization code.

-ralph

[ObiWan]

> I've been using the following in startup.bas in various apps, no
> problem. Then this morning, I ran the app side-by-side (using
> manifest) on a test PC (XP) and when I tried to run more than one
> instance, I got the critical stop.wav sound and I didn't see the
> MsgBox.
>
> Is using End a bad idea?

yes, but given that it's unreachable I don't think it matters here

> Public Sub Main()
> If App.PrevInstance Then
> MsgBox "You are already running this application."
> Exit Sub
> End
> End If
>
> InitCommonControlsVB
>
> frmMain.Show
> End Sub

not sure (since didn't see the code) but I suspect that the call to
that "InitCommonControlsVB" is performing some kind of OLE init or the
like, now... (shooting in the dark), try changing the code this way

> Public Sub Main()
>
> InitCommonControlsVB

>
> If App.PrevInstance Then
> MsgBox "You are already running this application."
> Exit Sub
> End
> End If
>

> frmMain.Show
> End Sub

and repeat the test (run two instances), probably nothing will change,
but then...

[MM]

On Fri, 24 May 2013 09:24:16 -0500, ralph <nt_con...@yahoo.com>
wrote:

Slightly more info, maybe? ;)

MM

[MM]

It worked! Thanks for the mod.

MM

[MM]

Actually, I've modified it yet again, having got an idea from an old
post (from Diurnal) at
http://www.xtremevbtalk.com/archive/index.php/t-203255.html

So now I'm doing:

Public Sub Main()

InitCommonControlsVB

If App.PrevInstance Then
MsgBox "You are already running this application."
Exit Sub

Else
frmMain.Show
End If

End Sub

i.e. no End statement. This version works as well.

MM

[ralph]

For a Mutex?

A Google for "vb6 previnstance mutex" will result in many examples.

Some a simple conditional, others with belt, suspenders, and an extra
pair of pants.

-ralph

[CoderX]

"MM" <kyli...@yahoo.co.uk> wrote in message

news:ug5vp8d7u9a9cm758...@4ax.com...

>>Use a Mutex
>
> Slightly more info, maybe? ;)
>
> MM

Google, maybe?

[Schmidt]

Am 24.05.2013 19:03, schrieb MM:

> So now I'm doing:
>
> Public Sub Main()
>
> InitCommonControlsVB
>
> If App.PrevInstance Then
> MsgBox "You are already running this application."
> Exit Sub
> Else
> frmMain.Show
> End If
>
> End Sub
>
> i.e. no End statement. This version works as well.

Well, since you are at it, deleting unnecessary stuff -
the Exit Sub is also superfluous now... ;-)

Public Sub Main()

InitCommonControlsVB

If App.PrevInstance Then
MsgBox "You are already running this application."

Else
frmMain.Show
End If

End Sub

Olaf

[MM]

On Sat, 25 May 2013 00:18:55 +0200, Schmidt <n...@vbRichClient.com>
wrote:

>Am 24.05.2013 19:03, schrieb MM:
>
>> So now I'm doing:
>>
>> Public Sub Main()
>>
>> InitCommonControlsVB
>>
>> If App.PrevInstance Then
>> MsgBox "You are already running this application."
>> Exit Sub
>> Else
>> frmMain.Show
>> End If
>>
>> End Sub
>>
>> i.e. no End statement. This version works as well.
>
>
>Well, since you are at it, deleting unnecessary stuff -
>the Exit Sub is also superfluous now... ;-)

Yeah... I see that now! Must have been asleep at the switch,

>
>Public Sub Main()
>
> InitCommonControlsVB
>
> If App.PrevInstance Then
> MsgBox "You are already running this application."
> Else
> frmMain.Show
> End If
>
>End Sub
>
>
>Olaf

MM

[MikeB]

"MM" <kyli...@yahoo.co.uk> wrote in message

news:j67vp8501poi38e5u...@4ax.com...

Which isn't doing anything different than your original if you had simply
removed the End statement. But for me, I wouldn't start anything
("InitCommonControlsVB") until the pathway ahead was clear, that way there
is nothing under the hood to do clean up before exiting.

[Schmidt]

Am 25.05.2013 13:45, schrieb MikeB:

>> Public Sub Main()
>>
>> InitCommonControlsVB
>>
>> If App.PrevInstance Then
>> MsgBox "You are already running this application."
>> Exit Sub
>> Else
>> frmMain.Show
>> End If
>>
>> End Sub
>
> Which isn't doing anything different than your original
> if you had simply removed the End statement.

The End statement was never reached - it played the role of
a "dead code", similar to a comment, nothing more...

> But for me, I wouldn't start anything ("InitCommonControlsVB")
> until the pathway ahead was clear, that way there is nothing
> under the hood to do clean up before exiting.

And here I'd think, that executing InitCommonControlsVB
no matter what (which is different from the original code),
is the sole reason, that this version works now.

If you include a "hint" over an appropriate Manifest, that
your executable "supports something", then the upstarting
process also has "to deliver" what it claims to be able to do
(as early as possible, in the init-phase - no matter if the
process will exit soon - the OS apparently does some checks
in the upfiring-phase, that processes behave conform to their
manifests, entering a "state" which is claimed there).

Olaf

[BeeJ]

Schmidt pretended :

Hmmmm ...

http://msdn.microsoft.com/en-us/library/windows/desktop/bb775695(v=vs.85).aspx

[BeeJ]

And ...

http://blogs.msdn.com/b/oldnewthing/archive/2005/07/18/439939.aspx

[Schmidt]

Am 25.05.2013 15:37, schrieb BeeJ:

> Hmmmm ...
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/bb775695(v=vs.85).aspx
and
> http://blogs.msdn.com/b/oldnewthing/archive/2005/07/18/439939.aspx


Not sure, what you're aiming at - since we don't know for sure,
what MM is doing behind his InitCommonControlsVB-function.

What I *do* know is, that when you enable "modern styles" in
your manifest, and include it as a resource - then you have
to follow through with a matching InitCommonControls(Ex) call -
otherwise the upstarting Process will make problems (will not
start at all, or just crashes shortly after the startup).

Since I wrote about "some state" which is expected in this case -
maybe "the state" is just a loaded Dll-Module, checked "to be there"...
So maybe it is enough, to use the "plain" InitCommonControls-Function
(even if it does nothing at all) just as an implicit Dll-Load-Trigger -
but maybe a simple LoadLibrary-Call would be enough in this case too
(alternatively).

Don't have an interest nor the time to experiment with that -
since I don't use the CommonControls anymore.


Olaf

[ObiWan]

> > So now I'm doing:
> >
> > Public Sub Main()
> >
> > InitCommonControlsVB
> >
> > If App.PrevInstance Then
> > MsgBox "You are already running this application."
> > Exit Sub
> > Else
> > frmMain.Show
> > End If
> >
> > End Sub

> Which isn't doing anything different than your original if you had
> simply removed the End statement. But for me, I wouldn't start
> anything ("InitCommonControlsVB") until the pathway ahead was clear,
> that way there is nothing under the hood to do clean up before
> exiting.

Well... given that the OP posted (in another branch of this thread)
some totally dumb code using the "As New" and then some similar stuff,
my suspect is that he has some code which is dealing with "termination"
and that this code *expects* to have some initialized objects, now,
since the startup check didn't initialize "whatever" ... :)

then ok, it's a totally dumb and wrong design but we aren't dealing
with it in this thread

[Schmidt]

Am 25.05.2013 18:58, schrieb ObiWan:

> Well... given that the OP posted (in another branch of this thread)

> some totally dumb code using the "As New"...

Since when is usage of "As New" considered "totally dumb"?

It is a valid VB-construct which just implies an implicit
and hidden Is-Nothing-Check, before accessing the Variable.

And if somebody decides to use it - especially when he has
some years of experience under his belt, and knows exactly
what to expect from the auto-instancing-behaviour of those
Variables, how on earth does this qualify as "totally dumb"?

It's a nice feature in my opinion.

> my suspect is that he has some code which is dealing with
> "termination" and that this code *expects* to have some
> initialized objects,

What does this have to do with the OPs problem? IIRC, it was
manifesting itself only on startup of a *second* instance of
an App (with a Manifest).

And the relevant codelines for this case were only:

Public Sub Main()

If App.PrevInstance Then
MsgBox "You are already running this application."
Exit Sub

That's all. Just the App.Previnstance-Check and a plain
and simple MsgBox, no "As New" Variable anywhere.

So, why do you think, the App failed (only beeping, not
starting up the Process)?

I mean, I've already mentioned what I've encountered some
years ago. Such crashes are quite normal, in case you define
a Manifest - and then don't initialize the CommonControls-Dll.

To avoid this weird startup-behaviour for "manifested"
Apps, you will have to Init (load) the CommonControls-Dll,
before your upstarting process attempts to show anything
"visual".

> then ok, it's a totally dumb and wrong design but we
> aren't dealing with it in this thread
>

I have no clue, what "totally dumb and wrong design" you
are constantly babbling about.

Care to explain?

Olaf

[MM]

NB: My app is using InitCommonControlsEx, i.e.
Declare Function InitCommonControlsEx Lib "comctl32.dll" _
(iccex As tagInitCommonControlsEx) As Boolean

The InitCommonControlsVB is just a wrapper.

MM

[MM]

On Sat, 25 May 2013 17:25:25 +0200, Schmidt <n...@vbRichClient.com>
wrote:

>since I don't use the CommonControls anymore.

Any reason why not?

MM

[MM]

On Sun, 26 May 2013 00:36:45 +0200, Schmidt <n...@vbRichClient.com>
wrote:

I think he's just miffed that I called him to account a few days ago
over his rudeness towards BeeJ in an earlier post. Some people are
like Rottweilers, not cuddly little kittens. We just have to learn to
live with all sorts! ;)

MM

[ObiWan]

> > Well... given that the OP posted (in another branch of this thread)
> > some totally dumb code using the "As New"...
>
> Since when is usage of "As New" considered "totally dumb"?

I consider it dumb when used with global (or module level) objects
since it may (and usually does) cause a lot of "strange" issues; the
"as new" is a valid and useful construct in some cases, but using it
everywhere isn't a good idea

> And if somebody decides to use it - especially when he has
> some years of experience under his belt, and knows exactly
> what to expect from the auto-instancing-behaviour of those
> Variables, how on earth does this qualify as "totally dumb"?

if someone decides to use it and knows exactly the side-effects then
ok, but then, seeing those "global" objects auto-instanced makes me
think; all in all it's easy to add a bit of code to create whatever
object in the constructor and avoiding the "As New", sure, in other
cases you may want/need it but in general I consider it bad practice

> > my suspect is that he has some code which is dealing with
> > "termination" and that this code *expects* to have some
> > initialized objects,
>
> What does this have to do with the OPs problem? IIRC, it was
> manifesting itself only on startup of a *second* instance of
> an App (with a Manifest).

As I wrote, I was just "shooting in the dark" (I didn't see the OP
code), my guess was that the "destructor" code of the app was expecting
to see some initialized (from "InitCommonControlsVB") stuff and since
the function wasn't called in case there was another running instance,
the "destructor" (termination code, if you prefer) crashed; again, it's
just a wild guess

> I mean, I've already mentioned what I've encountered some
> years ago. Such crashes are quite normal, in case you define
> a Manifest - and then don't initialize the CommonControls-Dll.

which is probably what happened and that init was (most probably) what
the "InitCommonControlsVB" did, since the "if ...Previnstance" forced
an app termination even before initializing the common controls

[ObiWan]

> I think he's just miffed that I called him to account a few days ago
> over his rudeness towards BeeJ in an earlier post. Some people are
> like Rottweilers, not cuddly little kittens. We just have to learn to
> live with all sorts! ;)

Do you really believe that ? LOL, you're totally off-target, man !

[Eduardo]

"Schmidt" <n...@vbRichClient.com> escribi� en el mensaje
news:knqdbt$8us$1...@dont-email.me...

As I see it, it must be the Msgbox that raised the error.
To show a messagebox without first starting the controls.

[ralph]

On Sun, 26 May 2013 00:36:45 +0200, Schmidt <n...@vbRichClient.com>
wrote:

>Am 25.05.2013 18:58, schrieb ObiWan:
>
>> Well... given that the OP posted (in another branch of this thread)
>> some totally dumb code using the "As New"...
>
>Since when is usage of "As New" considered "totally dumb"?
>
>It is a valid VB-construct which just implies an implicit
>and hidden Is-Nothing-Check, before accessing the Variable.
>
>And if somebody decides to use it - especially when he has
>some years of experience under his belt, and knows exactly
>what to expect from the auto-instancing-behaviour of those
>Variables, how on earth does this qualify as "totally dumb"?
>
>It's a nice feature in my opinion.
>

I find myself siding with ObiWan regarding the "As New" construct.
Although "totally dumb" might be a bit harsh, one can question the
wisdom of using it in a 'global' context AND then wondering if a stray
object instance might be a problem.

It is a "nice feature" only within a narrow range of circumstances*
where its use and consequences are fully understood.

-ralph
[* this could include both 'global' and 'local' usage. There is no
single attribute that says "As New is OK here", it is more a case of
assessing that "The side-effects of As New is not an issue here". <g>]

[ObiWan]

> Although "totally dumb" might be a bit harsh

Yes, wrong wording on my side, I admit it

> It is a "nice feature" only within a narrow range of circumstances*
> where its use and consequences are fully understood.

totally agreed, using it everywhere isn't a good idea :)

[ObiWan]

> As I see it, it must be the Msgbox that raised the error.
> To show a messagebox without first starting the controls.

I suspect you got the cigar :D

[Schmidt]

Am 27.05.2013 17:49, schrieb ralph:

> I find myself siding with ObiWan regarding the "As New" construct.
> Although "totally dumb" might be a bit harsh, one can question the
> wisdom of using it in a 'global' context AND then wondering if a
> stray object instance might be a problem.
>

It's just that I rarely encountered an occasion, where "stray
object instances" caused a problem with 'As New' Definitions.

I mean, where is the risk in holding e.g. a global Variable
for caching-purposes like this one for example:

Public gCacheCol As New Collection

Nice and simple - no extra-instantiation-line needed - you
can immediately query your cache for its current count:
Debug.Print gCacheCol.Count
Even delete everything it contains so far with a simple:
Set gCacheCol = Nothing
And after that it will be further usable (with auto-re-
instancing), in case you start re-adding things to it, etc.

Really can't see, how "stray-instances" should come into play
here, and even if they are, what "evil" they could cause
e.g. on shutdown...

> It is a "nice feature" only within a narrow range of circumstances*
> where its use and consequences are fully understood.
>

Well, that's the case with nearly any language-feature... ;-)

And since we can only guess about "how deep others understand"
(certain features), what's wrong with the usual "benefit-of-
-the-doubt" approach?


Olaf

[ralph]

On Wed, 29 May 2013 16:29:33 +0200, Schmidt <n...@vbRichClient.com>
wrote:

Short answer - because I've spent a ton of hours working with new and
intermediate programmers - in all that time I've discovered few, if
any, have trouble with objects with explicitly defined lifetimes. I
have found they do have problems when "As New" is universally applied
without thought.

As for your example, nothing is really wrong. I do the same quite
often for what I consider helper/BR classes. (Things like format or
convert currency, format for queries, time conversions, etc.) Though
not limited to those types.

[Note: You had the knowledge to add a Set to Nothing if any internal
storage is involved.]

Advanced programmers often have trouble understanding the issues less
experienced programmers run into because they have the experience and
knowledge to not "go there in the first place". Often as not -
unconsciously during design before a line of code is written. <g>

My comment on "stray-instances" was based simply on the OP's question.
It is obvious that the construct was not related to the his problem in
this case, however, he expressed wonder if it *might be*. To answer
that question one merely needs to exam the lifetimes and replace
implicity with explicity, thus removing all doubt.

I could provide contrived examples where "As New" could lead to
"stray-instances", but I guarantee your immediate response would be -
"Why on earth would anyone ever write that?". <bg>

-ralph

[MM]

On Wed, 29 May 2013 16:29:33 +0200, Schmidt <n...@vbRichClient.com>
wrote:

>> It is a "nice feature" only within a narrow range of circumstances*
>> where its use and consequences are fully understood.

Yeah! My latest app with the Public... As New construct even contains
a GoSub in one procedure! If it works, why not? I'm evil, n'est-ce
pas? http://www.littletyke.myzen.co.uk/lt/html/vuchord.html

MM

[se]

"MM" <kyli...@yahoo.co.uk> skrev i meddelelsen
news:gakdq81v61v04e7k1...@4ax.com...

Now, who are you quoting. The lines above is
Ralphs. And his answers to Schmidt is like a
miserable retreat. Containing almost what Olaf
Schmidt already said. I always wondered, if
Ralph is, or have been, a programmer. Have you
ever ever seen an helpfull answer from Ralph,
but long academic-like cackles.

/se

[ralph]

As many of his associates have equally wondered over the years.

-ralph