Object To Location 
Author Message
 Object To Location

VB6SP6
In this one example case the class is used only from the main form.
There is a bas module with a startup Sub Main that sets and shows the form.
Dim fMain as frmMain
Set fMain = New frmMain
fMain.Show
From then on, the form is always in existence until the app is exited.
I can declare and set the class either place, bas module or form.

What are the pros and cons to the location of the declaration / set of a
class?
Speed, memory usage ? Nothing?

If I put it in the form, it seems to be a top heavy thing, whereas in the
bas module it seems like it is widening the base - well that's the way I
think of it anyway.



Sat, 18 Dec 2010 05:00:01 GMT  
 Object To Location

Quote:
> VB6SP6. In this one example case the class is used only from
> the main form. There is a bas module with a startup Sub Main
> that sets and shows the form. Dim fMain as frmMain. From then
> on, the form is always in existence until the app is exited. I can
> declare and set the class either place, bas module or form. What
> are the pros and cons to the location . . .

While not directly related to your specific question, I recently had a
problem with my app crashing ("AppX has stopped responding") when I checked
App.Previnstance and used the result to close an instance of my application
if another instance was already running. This occurred in an app which was
doing some subclassing for the mouse scroll wheel and other things. I was
useing my main Form as the startup module and I checked App.Previnstance in
my main Form's Load event, closing it if an instance was already running.
That's when I got the "Appx has stopped responding", from the second
instance (the one I had just closed). Moving the App.Previnstance check to a
bas module (and making Sub Main the startup routine) solved the problem. I
was busy at the time and so I didn't look into it further, but I imagine it
was something to do with the second instance of the app in some way picking
up the subclassing of the first instance.

Mike



Sat, 18 Dec 2010 05:26:40 GMT  
 Object To Location


Quote:


> > VB6SP6. In this one example case the class is used only from
> > the main form. There is a bas module with a startup Sub Main
> > that sets and shows the form. Dim fMain as frmMain. From then
> > on, the form is always in existence until the app is exited. I can
> > declare and set the class either place, bas module or form. What
> > are the pros and cons to the location . . .

> While not directly related to your specific question, I recently had a
> problem with my app crashing ("AppX has stopped responding") when I
checked
> App.Previnstance and used the result to close an instance of my
application
> if another instance was already running. This occurred in an app which was
> doing some subclassing for the mouse scroll wheel and other things. I was
> useing my main Form as the startup module and I checked App.Previnstance
in
> my main Form's Load event, closing it if an instance was already running.
> That's when I got the "Appx has stopped responding", from the second
> instance (the one I had just closed). Moving the App.Previnstance check to
a
> bas module (and making Sub Main the startup routine) solved the problem. I
> was busy at the time and so I didn't look into it further, but I imagine
it
> was something to do with the second instance of the app in some way
picking
> up the subclassing of the first instance.

That is a know issue with App.PrevInstance() and a common reason for not
depending on it for a production/commercial application. (Use a Mutex
instead.)

-ralph



Sat, 18 Dec 2010 07:45:04 GMT  
 Object To Location


Quote:
> VB6SP6
> In this one example case the class is used only from the main form.
> There is a bas module with a startup Sub Main that sets and shows the
form.
> Dim fMain as frmMain
> Set fMain = New frmMain
> fMain.Show
> From then on, the form is always in existence until the app is exited.
> I can declare and set the class either place, bas module or form.

> What are the pros and cons to the location of the declaration / set of a
> class?
> Speed, memory usage ? Nothing?

> If I put it in the form, it seems to be a top heavy thing, whereas in the
> bas module it seems like it is widening the base - well that's the way I
> think of it anyway.

No difference in any meaningful way. Except as you noted - the ability to
manage the lifetime of the Object.

Note that when you declare an "Object Reference" in VB that variable
contains a reference to an Interface. Never the object itself. It's when you
create and assign an instance to a variable that the actual work gets done.



Sat, 18 Dec 2010 07:55:37 GMT  
 Object To Location
got it.
Quote:



> > VB6SP6
> > In this one example case the class is used only from the main form.
> > There is a bas module with a startup Sub Main that sets and shows the
> form.
> > Dim fMain as frmMain
> > Set fMain = New frmMain
> > fMain.Show
> > From then on, the form is always in existence until the app is exited.
> > I can declare and set the class either place, bas module or form.

> > What are the pros and cons to the location of the declaration / set of a
> > class?
> > Speed, memory usage ? Nothing?

> > If I put it in the form, it seems to be a top heavy thing, whereas in the
> > bas module it seems like it is widening the base - well that's the way I
> > think of it anyway.

> No difference in any meaningful way. Except as you noted - the ability to
> manage the lifetime of the Object.

> Note that when you declare an "Object Reference" in VB that variable
> contains a reference to an Interface. Never the object itself. It's when you
> create and assign an instance to a variable that the actual work gets done.



Sat, 18 Dec 2010 08:49:00 GMT  
 Object To Location

Quote:
> That is a known issue with App.PrevInstance() [crashing
> when closing a second instance when subclassing is in use
> on the first instance] and a common reason for not depending
> on it for a production/commercial application. (Use a Mutex
> instead.)

Thanks, Ralph. I wasn't aware of that. I just came across the problem during
testing and I found that using Sub Main as my startup object and moving the
check for App.Previnstance into Sub Main fixed the problem. I've tried it
under all sorts of conditions and so far it has provided an entirely
reliable solution. I'll certainly have a look at your Mutex suggestion
though. I understand the general idea about mutual exclusions, but not from
a MS Windows point of view where there are probably various functions
specifically designed to set them up and deal with them. Can you provide me
with any pointers? In the meantime, do you suggest that I move away from my
current solution anyway (checking App.Previnstance in Sub Main and closing
the second app simply by failing to open up any Forms or run any more code)?
Can you see a potential problem with that? It certainly seems to work okay,
but I wouldn't like to continue using it if there are forseeable problems.

Mike



Sat, 18 Dec 2010 13:01:47 GMT  
 Object To Location


Quote:


> > That is a known issue with App.PrevInstance() [crashing
> > when closing a second instance when subclassing is in use
> > on the first instance] and a common reason for not depending
> > on it for a production/commercial application. (Use a Mutex
> > instead.)

> Thanks, Ralph. I wasn't aware of that. I just came across the problem
during
> testing and I found that using Sub Main as my startup object and moving
the
> check for App.Previnstance into Sub Main fixed the problem. I've tried it
> under all sorts of conditions and so far it has provided an entirely
> reliable solution. I'll certainly have a look at your Mutex suggestion
> though. I understand the general idea about mutual exclusions, but not
from
> a MS Windows point of view where there are probably various functions
> specifically designed to set them up and deal with them. Can you provide
me
> with any pointers? In the meantime, do you suggest that I move away from
my
> current solution anyway (checking App.Previnstance in Sub Main and closing
> the second app simply by failing to open up any Forms or run any more
code)?
> Can you see a potential problem with that? It certainly seems to work
okay,
> but I wouldn't like to continue using it if there are forseeable problems.

It is related to the phenomena where if you have an App that is using
App.PrevInstance and an e{*filter*}d User multiple-clicks to launch an
Application. (Perhaps on a busy box.) The app can become confused and load
substantial 'parts' before PrevInstance is ever reached.

"Instance checking" has been built into every Application Framework (eg,
MFC) since the dawn of frameworks, and they all work 99.9% of the time, and
they all fail under some obscure condition.



Sat, 18 Dec 2010 15:57:32 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Changing OLE Objects linked location

2. Chicago Oracle Power Objects User Group - Notice Location Change

3. Crystal Report: How to Set Location of OLE object at Run Time

4. Finding Location of Objects in other applications.

5. location object Q

6. location object problem

7. location object problem

8. get COM object location by ProgID?

9. File location of object in use

10. Changing the location of an OLE object to point to somewhere else

11. change cursor location of connection object back and forth

12. COM Object Location

 

 
Powered by phpBB® Forum Software