Shared Form - Different Actions for Same Button
Brian
I have a form that is shared between two applications. (It will be compiled
into the two exes). I want to have a button on the shared form activate
unique actions depending on which app the form is launched from. The action
by the shared button will not close the window (so I can't use the Hide event
as a trigger)... My question... how do I have the button initiate the
actions without having the issue as shown below:
cmdShareButton_Click()
if frmA is parent then frmA.perform_an_action
if frmB is parent then frmB.perform_an_action
end sub
This causes me to load application structure (in this case frmA and frmB)
for both apps into each other...
There must be a better way to handle this issue.
Can
Bill McCarthy
Typically this is where you would use an event based notification. Declare
a Public event in your shared form, then let the other forms handle that
event.
"Brian" <Br...@discussions.microsoft.com> wrote in message
news:A0CEB409-C68D-4A9B...@microsoft.com...
Brian
capability is limited....
Thanks,
Bill McCarthy
Actually that doesn't seem to be working in VB6. I can declare a variable
WithEvents, eg:
Private WithEvents frm3 As Form3
But can't seem to instantiate it and still get the events.
So a different approach is to have a standard interface in your other forms
(parent forms). Pass a reference to the parent form to the child form, and
it calls on that interface.
e.g:
- add a class module, call it INotify. Add to is a Sub called NotifyMe
- in your parent forms, type: Implements INotify
- then select INotify in the left drop down, and in the right NotifyMe wand
the method stub will be added. Put your parent specific code there, repeat
for each parent form
- in the child form add aProperty Set of type INotify. Then when you want
to notify the parent form, check ot see if m_INotify is nothing, and if not
then call m_Inofity.NotifyMe
- form the parents you just need to set the INotify property
Alternatively you cna do this late bound, skip the interface and just catch
any errors.
"Brian" <Br...@discussions.microsoft.com> wrote in message
news:E05E2567-8017-48F5...@microsoft.com...
Karl E. Peterson
> Actually that doesn't seem to be working in VB6. I can declare a variable
> WithEvents, eg:
> Private WithEvents frm3 As Form3
> But can't seem to instantiate it and still get the events.
Works fine in VB6. http://vb.mvps.org/samples/FormBdr
--
.NET: It's About Trust!
http://vfred.mvps.org
Larry Serflaten
"Brian" <Br...@discussions.microsoft.com> wrote
What about checking the contents of the App object? The FileDescription,
ProductName, or Title all seem like you could set them to be unique to
each application....
LFS
Karl E. Peterson
> cmdShareButton_Click()
>
> if frmA is parent then frmA.perform_an_action
>
> if frmB is parent then frmB.perform_an_action
>
> end sub
>
> This causes me to load application structure (in this case frmA and frmB)
> for both apps into each other...
>
> There must be a better way to handle this issue.
Conditional compilation would be very simple to implement.
#If ThisIsAppA Then
frmA.perform_an_action
#Else
frmB.perform_an_action
#End If
Bill McCarthy
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:uirOgGbg...@TK2MSFTNGP03.phx.gbl...
> Bill McCarthy wrote:
>> Actually that doesn't seem to be working in VB6. I can declare a variable
>> WithEvents, eg:
>> Private WithEvents frm3 As Form3
>> But can't seem to instantiate it and still get the events.
>
> Works fine in VB6. http://vb.mvps.org/samples/FormBdr
> --
I'm not seeing any events raised from one form handled in another in that
sample.
Karl E. Peterson
> "Karl E. Peterson" <ka...@mvps.org> wrote ...
>> Bill McCarthy wrote:
>>> Actually that doesn't seem to be working in VB6. I can declare a variable
>>> WithEvents, eg:
>>> Private WithEvents frm3 As Form3
>>> But can't seem to instantiate it and still get the events.
>>
>> Works fine in VB6. http://vb.mvps.org/samples/FormBdr
>
> sample.
I guess you'll need to use some imagination. <shrug>
Bill McCarthy
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:%23FnrnUb...@TK2MSFTNGP02.phx.gbl...
So you saying you can raise events in one form and have another handle them
? In case this isn't clear, I'm talking about custom events, eg:
' child form code
Public Event Notify
Sub NotifytheParent
RasieEvent Notify
End Sub
I tried declaring that child form WithEvents. I could set that variable to
an instance but the event handler never got called.
I seem to recall some limitations in VB6 like this.....
expvb
standard EXE projects? If so, use conditional compilation as Karl suggested.
However, "#Const" only declare the constant for the file that it appears in.
If you want a global #const, you have to put them in the Make tab of the
project under "Conditional Compilation Arguments". Example:
ThisIsAppA = -1
If you need to declare more than one #Const, use:
ThisIsAppA = -1: IsDebug = -1
Karl E. Peterson
>>>>> Actually that doesn't seem to be working in VB6. I can declare a
>>>>> variable
>>>>> WithEvents, eg:
>>>>> Private WithEvents frm3 As Form3
>>>>> But can't seem to instantiate it and still get the events.
>>>>
>>>> Works fine in VB6. http://vb.mvps.org/samples/FormBdr
>>>
>>> I'm not seeing any events raised from one form handled in another in that
>>> sample.
>>
>> I guess you'll need to use some imagination. <shrug>
>
> ? In case this isn't clear, I'm talking about custom events, eg:
Yep.
> I tried declaring that child form WithEvents. I could set that variable to
> an instance but the event handler never got called.
> I seem to recall some limitations in VB6 like this.....
Nope. Simplest possible demonstration of wits...
Module1:
========================================
Option Explicit
Public Sub Main()
Form1.Show
Form2.Show
Set Form2.Client = Form1
End Sub
========================================
Form1:
========================================
Option Explicit
Public Event BiteMe()
Private Sub Command1_Click()
RaiseEvent BiteMe
End Sub
========================================
Form2:
========================================
Option Explicit
Private WithEvents bm As Form1
Public Property Set Client(ByVal NewClient As Form1)
Set bm = NewClient
End Property
Private Sub bm_BiteMe()
MsgBox "Bite Me!"
End Sub
========================================
Bill McCarthy
>>
>> So you saying you can raise events in one form and have another handle
>> them
>> ? In case this isn't clear, I'm talking about custom events, eg:
>
> Yep.
>
Thanks. I found out what went wrong. I changed the name of the WithEvents
variable and hence the handler wasn't wired anymore. To use to proper
renaming/refactoring tools I guess <g>
Back on track, Brian, as per my first suggestion, I'd use an event based
notification.
Karl E. Peterson
> "Karl E. Peterson" <ka...@mvps.org> wrote ...
>>>
>>> So you saying you can raise events in one form and have another handle
>>> them
>>> ? In case this isn't clear, I'm talking about custom events, eg:
>>
>> Yep.
>
> Thanks. I found out what went wrong. I changed the name of the WithEvents
> variable and hence the handler wasn't wired anymore. To use to proper
> renaming/refactoring tools I guess <g>
Bah, no fun flying with instruments when the sky is blue!
Bill McCarthy
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:e99UGsbg...@TK2MSFTNGP04.phx.gbl...
Ah but instruments can warn you when things go wrong ;)
So what are the limitations of WithEvents in VB6 ?
Is the only one you can't use control arrays with WithEvents ?
Bill McCarthy
"Bill McCarthy" <TPASoft.com Are Identity Thieves> wrote in message
news:eV8cvubg...@TK2MSFTNGP03.phx.gbl...
>
> So what are the limitations of WithEvents in VB6 ?
> Is the only one you can't use control arrays with WithEvents ?
>
To answer my own question, from the help file:
Limitations on WithEvents Variables
-----------------------------------------------
You should be aware of the following limitations on the use of WithEvents
variables:
+ A WithEvents variable cannot be a generic object variable. That is, you
cannot declare it As Object — you must specify the class name when you
declare the variable.
+ You cannot declare a WithEvents variable As New. The event source object
must be explicitly created and assigned to the WithEvents variable.
+ You cannot declare WithEvents variables in a standard module. You can
declare them only in class modules, form modules, and other modules that
define classes.
+ You cannot create arrays of WithEvents variables.
Karl E. Peterson
> "Karl E. Peterson" <ka...@mvps.org> wrote ...
>> Bill McCarthy wrote:
>>> "Karl E. Peterson" <ka...@mvps.org> wrote ...
>>>>>
>>>>> So you saying you can raise events in one form and have another handle
>>>>> them
>>>>> ? In case this isn't clear, I'm talking about custom events, eg:
>>>>
>>>> Yep.
>>>
>>> Thanks. I found out what went wrong. I changed the name of the
>>> WithEvents
>>> variable and hence the handler wasn't wired anymore. To use to proper
>>> renaming/refactoring tools I guess <g>
>>
>> Bah, no fun flying with instruments when the sky is blue!
>
And you can take a helicopter to the top of many mountains, but it's nowhere near
the accomplishment of slogging your own ass up there!
> So what are the limitations of WithEvents in VB6 ?
Prolly depends on one's definition of "limitations."
> Is the only one you can't use control arrays with WithEvents ?
That's an ugly one, yeah. That's often when I turn to using implemented interfaces.
Karl E. Peterson
>> So what are the limitations of WithEvents in VB6 ?
>> Is the only one you can't use control arrays with WithEvents ?
>
> To answer my own question, from the help file:
>
> Limitations on WithEvents Variables
> -----------------------------------------------
>
> You should be aware of the following limitations on the use of WithEvents
> variables:
>
> + A WithEvents variable cannot be a generic object variable. That is, you
> cannot declare it As Object — you must specify the class name when you
> declare the variable.
>
> + You cannot declare a WithEvents variable As New. The event source object
> must be explicitly created and assigned to the WithEvents variable.
>
> + You cannot declare WithEvents variables in a standard module. You can
> declare them only in class modules, form modules, and other modules that
> define classes.
>
> + You cannot create arrays of WithEvents variables.
I don't think those first three are worth the bits it takes to mention them, to be
honest.
1) Generic objects don't expose interfaces you can early-bind to.
2) Declaring anything As New is most often just plain stupid.
3) Standard Modules are for callbacks, silly rabbit.
Whatever...
Ken Halter
news:eV8cvubg...@TK2MSFTNGP03.phx.gbl...
>
In VB6, one of those instruments would be Intellisense. If you're typing the
name of any declared object/variable, all you have to do is type the first
couple of letters, hit Ctrl-Space and either VB will complete the name for
you, or give a list of possibles. Longer variable names help, too.
> So what are the limitations of WithEvents in VB6 ?
> Is the only one you can't use control arrays with WithEvents ?
No control arrays and no 'As Object' or any thing else that's late bound...
again... after typing WithEvents <space>, if the objects name doesn't show
in intellisense, it won't work.
There are ways around the control array problem, though... there are plenty
of "collections, withevents" and similar samples around... heck, even I have
a couple...
This one gets around the control array issue, but doesn't get around any
'max number of uinique names per form' issues.
Add Controls at Runtime With Events (kind of)
http://www.vbsight.com/CodeA.htm
..and a related sample..
Use the Implements keyword to Share Events
http://www.vbsight.com/CodeU.htm
Brian
wanted too.
Very interesting discussion for this little issue.
As a follow up question... are there any issues with defining a form as a
client of another form? How is this different from a parent/child
relationship?
I'll do some research on my end as well.
Thanks for the support.
"Karl E. Peterson" wrote:
> ..NET: It's About Trust!
> http://vfred.mvps.org
>
>
>
Brian
the parent form would have to have a specific reference...
if app is AppA then call frmA.Action
if app is AppB then call frmB.Action
...again forcing the addition of frmA in AppB and frmA in AppB.
The compilation trick is something I haven't played with... but seems
somewhat messy.
But with the .Client setup... it allows me to trigger that event in any
number of other forms.
Larry Serflaten
"Brian" <Br...@discussions.microsoft.com> wrote
> But this would still leave me in a bind as the call to a function unique to
> the parent form would have to have a specific reference...
>
> if app is AppA then call frmA.Action
> if app is AppB then call frmB.Action
>
> ...again forcing the addition of frmA in AppB and frmA in AppB.
You are correct there. I was thinking if AppA's main form was
called frmMain and AppB's main form was also called frmMain
your test would be something like this:
If App.FileDescription = "My First Application" Then
frmMain.DoThis
ElseIf App.FileDescription = "My Second App" Then
frmMain.DoThat
End If
That would solve the delema you posed:
> I want to have a button on the shared form activate
> unique actions depending on which app the form is launched from
What you've shown above is that the button calls the same sub on
two different forms...
Another way to do that, as was suggested, is to pass a reference to
the shared form:
Private mParent As Form
Public Sub LaunchForm(Parent as form)
Set mParent = Parent
Me.Show
End Sub
Private Sub Command1_Click()
mParent.Action
End Sub
Then, instead of using the form's Show method you'd call your custom
show method:
frmShared.LaunchForm Me
As long as the form calling that Launch method has a public routine
called Action, it would be called on the click of the button.....
LFS
Dave O.
"Larry Serflaten" <serf...@usinternet.com> wrote in message
news:OrSqIOhg...@TK2MSFTNGP06.phx.gbl...
>
> "Brian" <Br...@discussions.microsoft.com> wrote
>> But this would still leave me in a bind as the call to a function unique
>> to
>> the parent form would have to have a specific reference...
>>
>> if app is AppA then call frmA.Action
>> if app is AppB then call frmB.Action
>>
>> ...again forcing the addition of frmA in AppB and frmA in AppB.
>
> You are correct there. I was thinking if AppA's main form was
> called frmMain and AppB's main form was also called frmMain
> your test would be something like this:
>
> If App.FileDescription = "My First Application" Then
> frmMain.DoThis
> ElseIf App.FileDescription = "My Second App" Then
> frmMain.DoThat
> End If
>
> That would solve the delema you posed:
>
What am I missing here? why can he not just have the button fire functions
which while different in each app, both have the same name? If done like
that there is no need for the form with the button to know which app is
running.
If the 2 apps don't have forms with the same name stick a public routine
into a module.
Dave O.
Jeff Johnson
news:uDZdX8bg...@TK2MSFTNGP02.phx.gbl...
>> Ah but instruments can warn you when things go wrong ;)
>
> In VB6, one of those instruments would be Intellisense. If you're typing
> the name of any declared object/variable, all you have to do is type the
> first couple of letters, hit Ctrl-Space and either VB will complete the
> name for you, or give a list of possibles. Longer variable names help,
> too.
Doesn't help much when making a change after the fact, though, which is how
I interpreted what he was referring to. That's where MZTools can help....
Ken Halter
news:%23UWgq1h...@TK2MSFTNGP02.phx.gbl...
>
> Doesn't help much when making a change after the fact, though, which is
> how I interpreted what he was referring to. That's where MZTools can
> help....
I assumed it was an unintentional 'change after the fact'... as is common
with people who look at the keyboard while typing, instead of the screen.
Karl E. Peterson
> What am I missing here? why can he not just have the button fire functions
> which while different in each app, both have the same name? If done like
> that there is no need for the form with the button to know which app is
> running.
This was my first thought too. Shouldn't be calling another form in the first
place. Should be calling a same-named routine in a BAS module that knows wtf
application it's in and acts accordingly.
--
That Guy
you launching the shared form? the one with the button.
I would launch the shared form and pass into the constructor a
variable that would be the form that called it.
private call_Form as Form
Public Sub New(byref calling_Form as form)
Call_Form = calling_Form
end sub
Private sub Shared_Button_Click()
if call_Form.Name = "frmA" then
frmA.desiredSub()
elseif call_Form.Name = "frmB" then
frmB.desiredSub()
end if
end sub
and when you are going between the two forms then use the GotFocus
event of the shared form to re-assign the Call_Form.
Email me if you want a coded example I will work on one.
Ian
Brian
That shared form is called normally from the different programs -
frmShared.Show.
The issue is if I have a reference to a calling form "frmB" in frmShared
that AppA doesn't need... there is a bunch of additional supporting code
that I have to compile into AppA.
create a project and create three forms and save them to a "shared folder".
Now create two new projects. have each project load two of the newly created
forms with one being the shared form. In the shared form... put an event
that references the both of the other forms... No try to compile the two
projects... the compile will fail because you don't have all three forms in
each project.
The apparent simple fix was to create an event that would be triggered and
then caught by the calling form... I might have been able to use similar
method names to make it all work... but that seemed to be more trouble...
hope that clarifies.
Larry Serflaten
"Brian" <Br...@discussions.microsoft.com> wrote
> The shared form is compiled into two apps seperately. So I have two EXEs.
> That shared form is called normally from the different programs -
> frmShared.Show.
> The apparent simple fix was to create an event that would be triggered and
> then caught by the calling form... I might have been able to use similar
> method names to make it all work... but that seemed to be more trouble...
>
> hope that clarifies.
Excuse my saying so but that design seems a bit too dependant. I can
see using a shared form, the MsgBox, and Common Dialogs are so
common that VB supplies them out of the box. What I don't see them
doing is calling back to the calling form. Callbacks are typically a C (type)
construct.
I would be willing to bet there would be a way to avoid such rigid dependancy.
LFS
Brian
code embedded in them. I realize that I have built my forms incorrectly...
but I had too much time invested in the code as it is and I don't have the
time to repair what I have learned (in the sort term). I am in the planning
process of converting my VB6 to .net... but in the mean time... I need to be
able to work with my "bad" coding practices... which is what this fix has
provided.
Bill McCarthy
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:uONFo1bg...@TK2MSFTNGP02.phx.gbl...
> Bill McCarthy wrote:
>>> So what are the limitations of WithEvents in VB6 ?
>>> Is the only one you can't use control arrays with WithEvents ?
>>
>> To answer my own question, from the help file:
>>
>> Limitations on WithEvents Variables
>> -----------------------------------------------
>>
>> You should be aware of the following limitations on the use of WithEvents
>> variables:
>>
>> + A WithEvents variable cannot be a generic object variable. That is, you
>> cannot declare it As Object — you must specify the class name when you
>> declare the variable.
>>
>> + You cannot declare a WithEvents variable As New. The event source
>> object
>> must be explicitly created and assigned to the WithEvents variable.
>>
>> + You cannot declare WithEvents variables in a standard module. You can
>> declare them only in class modules, form modules, and other modules that
>> define classes.
>>
>> + You cannot create arrays of WithEvents variables.
>
> I don't think those first three are worth the bits it takes to mention
> them, to be honest.
>
I think they've listed them in the help documents for "completeness"
> 1) Generic objects don't expose interfaces you can early-bind to.
>
yep, but generic objects don't expose any properties either yet you can code
those properties. So I guess they are stating that to rule out any option
of implicit wiring of events working with late binding.
> 2) Declaring anything As New is most often just plain stupid.
>
"often" not always ;)
> 3) Standard Modules are for callbacks, silly rabbit.
>
There's nothing wrong with having a Shared object that has events, except
you can't do that in VB6, you have to create an instance of a class to
handle those events and hard wire that to call your shared module.
Bill McCarthy
"Jeff Johnson" <i....@enough.spam> wrote in message
news:%23UWgq1h...@TK2MSFTNGP02.phx.gbl...
yep.
Karl E. Peterson
>> I don't think those first three are worth the bits it takes to mention
>> them, to be honest.
>
> I think they've listed them in the help documents for "completeness"
You seem to have misspelled "anal retentiveness" -- HTH!
>> 1) Generic objects don't expose interfaces you can early-bind to.
>
> yep, but generic objects don't expose any properties either yet you can code
> those properties. So I guess they are stating that to rule out any option
> of implicit wiring of events working with late binding.
Pretty damned hard to write an event handler for a generic event, though.
>> 2) Declaring anything As New is most often just plain stupid.
>
> "often" not always ;)
About as often as it's wet underwater, yeah.
>> 3) Standard Modules are for callbacks, silly rabbit.
>
> There's nothing wrong with having a Shared object that has events, except
> you can't do that in VB6,
Of course you can. That's where I entered this thread, to tell you you were wrong
the first time you said that.
Bill McCarthy
> Bill McCarthy wrote:
>>> I don't think those first three are worth the bits it takes to mention
>>> them, to be honest.
>>
>> I think they've listed them in the help documents for "completeness"
>
> You seem to have misspelled "anal retentiveness" -- HTH!
>
I think that really is an issue of different perspectives. If you view the
documentation as attempting to be complete for those *unfamiliar* with VB6,
which is really what documentation should aim to do, then omitting these
limitations would be wrong.
>>> 1) Generic objects don't expose interfaces you can early-bind to.
>>
>> yep, but generic objects don't expose any properties either yet you can
>> code
>> those properties. So I guess they are stating that to rule out any
>> option
>> of implicit wiring of events working with late binding.
>
> Pretty damned hard to write an event handler for a generic event, though.
>
Really ? Strange, it's a concept I think a lot of dynamic language folks
would expect, as to would those who have the luxury of wiring up handlers.
In Vb6 you have to use a name matching pattern to wire up events. So I
could see people from more flexible languages expecting to be able to
dynamically add a control, give it a name, then have their Foo_Click handler
being called. Doesn't seem that unreasonable to me. I guess this is the
perspectives of different languages versus the already working within the
limitations view ?
>>> 2) Declaring anything As New is most often just plain stupid.
>>
>> "often" not always ;)
>
> About as often as it's wet underwater, yeah.
>
Like it or not, evil auto instantiating objects have their place.
>>> 3) Standard Modules are for callbacks, silly rabbit.
>>
>> There's nothing wrong with having a Shared object that has events, except
>> you can't do that in VB6,
>
> Of course you can. That's where I entered this thread, to tell you you
> were wrong the first time you said that.
> --
I just hate it when people cut sentences in half then portray the opposite
as being said. Here's what I wrote:
>There's nothing wrong with having a Shared object that has events, except
>you can't do that in VB6, you have to create an instance of a class to
>handle those events and hard wire that to call your shared module.
So the point I was making was you can't handle events in a module.
Karl E. Peterson
>> You seem to have misspelled "anal retentiveness" -- HTH!
>
> I think that really is an issue of different perspectives.
Right. <yawn>
>> Pretty damned hard to write an event handler for a generic event, though.
>
> Really ?
Yes. Note the Newsgroup header, if this point is at all confusing.
If you want to play language wars, please play elsewhere.
>>>> 2) Declaring anything As New is most often just plain stupid.
>>>
>>> "often" not always ;)
>>
>> About as often as it's wet underwater, yeah.
>
> Like it or not, evil auto instantiating objects have their place.
In He11. (Agreement noted.)
>>>> 3) Standard Modules are for callbacks, silly rabbit.
>>>
>>> There's nothing wrong with having a Shared object that has events, except
>>> you can't do that in VB6,
>>
>> Of course you can. That's where I entered this thread, to tell you you
>> were wrong the first time you said that.
>
> I just hate it when people cut sentences in half
And I hate outsiders coming in to wage language wars.
As I suggested earlier, take your games elsewhere.
Schmidt
"Karl E. Peterson" <ka...@mvps.org> schrieb im Newsbeitrag
news:%23e88naj...@TK2MSFTNGP04.phx.gbl...
> >> Pretty damned hard to write an event handler for a
> >>generic event, though.
> >
> > Really ?
>
> Yes. Note the Newsgroup header, if this point is at all confusing.
>
> If you want to play language wars, please play elsewhere.
Aside from that - VB6 already has integrated support for
"LateBound-Events" at least for Controls - over the
(withevents declared) vbControlExtender-ObjectType.
And for normal VB-classes there are also codesnippets
out there, which cover that topic pretty well - IMO
Eduardo Morcillo delivered the first working example
of an IConnectionPoint(Container)-Implementation
within his nice EventCollection-example.
In dhRichClient.dll there's a relative easy to use
implementation of that too - (cEventCollection,
based on Eduardos approach with some speedups
and other enhancements) - though that stuff is not
used very often in "real world apps" as it seems -
but it is there.
Olaf
Bill McCarthy
"Schmidt" <s...@online.de> wrote in message
news:OYKqlDmh...@TK2MSFTNGP04.phx.gbl...
>
> Aside from that - VB6 already has integrated support for
> "LateBound-Events" at least for Controls - over the
> (withevents declared) vbControlExtender-ObjectType.
>
That's not late bound, that's more an implied interface and You have to
sepcify the interface
> And for normal VB-classes there are also codesnippets
> out there, which cover that topic pretty well - IMO
> Eduardo Morcillo delivered the first working example
> of an IConnectionPoint(Container)-Implementation
> within his nice EventCollection-example.
>
Is that using an interface model where you have to implement the interface,
or does that work for any type ?
Bill McCarthy
> Bill McCarthy wrote:
>>> You seem to have misspelled "anal retentiveness" -- HTH!
>>
>> I think that really is an issue of different perspectives.
>
> Right. <yawn>
>
>>> Pretty damned hard to write an event handler for a generic event,
>>> though.
>>
>> Really ?
>
> Yes. Note the Newsgroup header, if this point is at all confusing.
>
> If you want to play language wars, please play elsewhere.
>
<geez /> Chill out Karl. The only one trying to pervert this conversation
into a language war is you. I quoted the VB6 help file, how it says :
+ A WithEvents variable cannot be a generic object variable. That is, you
cannot declare it As Object — you must specify the class name when you
declare the variable.
You then attack the VB6 help file, and the basis of that from above is that
you think it's "damned hard to write an event handler for a generic event".
Pause a moment and think about that. For those coming to VB6 for the first
time, especially way back when that help file was written, (note that's
before any language war you are imagining), it seems very reasonable they
should include documenting that limitation. VB6 is very flexible with late
bound method calls, property sets and gets, but it is lacking when it comes
to events. Really I don't see why you are making such an issue of them
informing people of that.
Schmidt
"Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
news:eyZrY4Bi...@TK2MSFTNGP06.phx.gbl...
> Hi Olaf,
>
> "Schmidt" <s...@online.de> wrote in message
> news:OYKqlDmh...@TK2MSFTNGP04.phx.gbl...
> >
> > Aside from that - VB6 already has integrated support for
> > "LateBound-Events" at least for Controls - over the
> > (withevents declared) vbControlExtender-ObjectType.
> >
>
> That's not late bound, that's more an implied interface and
> You have to sepcify the interface
able to declare the Ext-Variable WithEvents), which then
supports "LateBound-Events" - which are received generically
(by Name) within one central Evt-procedure for all types
of the Control-internally raised Events.
> > And for normal VB-classes there are also codesnippets
> > out there, which cover that topic pretty well - IMO
> > Eduardo Morcillo delivered the first working example
> > of an IConnectionPoint(Container)-Implementation
> > within his nice EventCollection-example.
> >
>
> Is that using an interface model where you have to implement
> the interface, or does that work for any type ?
No, this works on all "normal COM-Objects" with "Std-COM-
EventInterfaces" (IConnectionPoint-based).
Here's an example for the usage of the EventCollection -
there's an LateBound-defined Obj-Array with two Demo-
member-instances - and both members are added to
the (withevents declared) EventCollection then later on.
Performance of this event-approach is ca. 5 times slower
than the Std-VBEvent-Handling but nonetheless reaches
ca. 70000-120000 latebound Event-Calls per second on
modern CPUs which should be enough in most cases.
'***Into a small Demo-Class named Class1
Option Explicit
Event MyEvent(ByVal L As Long, ByVal D As Double, Cancel As Boolean)
Public Sub RaiseInternalEventsUntilCancelled()
Dim i&, Cancel As Boolean
Do
i = i + 1
RaiseEvent MyEvent(i, CDbl(i), Cancel)
Loop Until Cancel
End Sub
'****and this into a Form1 - then click the Form
'(VB-Project needs a reference to dhRichClient.dll)
Option Explicit
Private WithEvents C1 As Class1 'earlybound C1 with Events
Private C1Arr(0 To 1) As Object 'latebound Object-Array...
Private WithEvents EC As cEventCollection 'and the Evt-Receiver
Private Const MaxEvents& = 100000
Private Sub Form_Load()
AutoRedraw = True
Set C1 = New Class1 'Events the "normal way" (just for comparison)
Set C1Arr(0) = New Class1 'and here two latebound-objects...
Set C1Arr(1) = New Class1 '...which make use of the EvtColl.
Set EC = New cEventCollection
EC.Add C1Arr(0), "C1Arr_0"
EC.Add C1Arr(1), "C1Arr_1"
End Sub
Private Sub Form_Click()
Dim T!
T = Timer
Print "Std-VB-Events"
C1.RaiseInternalEventsUntilCancelled
Print Timer - T, vbCrLf
T = Timer
Print "Event-Collection-Events for two latebound-instances"
C1Arr(0).RaiseInternalEventsUntilCancelled
C1Arr(1).RaiseInternalEventsUntilCancelled
Print Timer - T, vbCrLf
End Sub
Private Sub C1_MyEvent(ByVal L As Long, ByVal D As Double, _
Cancel As Boolean)
If L = MaxEvents Then Cancel = True: Print , "C1", L
End Sub
Private Sub EC_EventRaised(Key As String, EventName As String, _
ByVal ParamCount As Long, P1 As Variant, P2 As Variant, _
P3 As Variant, P4 As Variant, P5 As Variant, _
P6 As Variant, P7 As Variant, P8 As Variant)
Select Case EventName
Case "MyEvent": If P1 = MaxEvents \ 2 Then P3 = True: Print , Key, P1
End Select
End Sub
Olaf
Karl E. Peterson
>> Yes. Note the Newsgroup header, if this point is at all confusing.
>>
>> If you want to play language wars, please play elsewhere.
>
> <geez /> Chill out Karl. The only one trying to pervert this conversation
> into a language war is you.
Serious Bill, take the language war crap elsewhere. You didn't see me dragging
other languages into the thread. What you call a "limitation" is simply laughable.
Is it also a "limitation" that VB6 can't write 64-bit code, or for that matter that
it can't write 16-bit code, and should those be documented as well? Get real.
Better yet, get a life. Quit the childish crusade here, and go play with others who
share your interests.
Bill McCarthy
Looks interesting. I'll have to download it and see how he does that
(assuming there's source ??)
"Schmidt" <s...@online.de> wrote in message
news:OAbPCOHi...@TK2MSFTNGP06.phx.gbl...
>
> "Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
> news:eyZrY4Bi...@TK2MSFTNGP06.phx.gbl...
>
Bill McCarthy
> Bill McCarthy wrote:
>>> Yes. Note the Newsgroup header, if this point is at all confusing.
>>>
>>> If you want to play language wars, please play elsewhere.
>>
>> <geez /> Chill out Karl. The only one trying to pervert this
>> conversation
>> into a language war is you.
>
> Serious Bill, take the language war crap elsewhere.
Seriously Karl, chill out. *You* are the only one making a language war in
this thread.
> You didn't see me dragging other languages into the thread.
<sigh> What we did see was you say it was pretty hard to handle late bound
events hence VB shouldn't mention that limitation. That's a rediculous
tunnel view with blinders on. The help files were written for people coming
to the language, some of whom would have had experience with other
languages, and some of whom would expect that given you can use late binding
with properyt gets and set and method calls then surely you *should* be able
to use it with events.
> What you call a "limitation" is simply laughable.
LOL.
> Is it also a "limitation" that VB6 can't write 64-bit code, or for that
> matter that it can't write 16-bit code, and should those be documented as
> well? Get real.
Well I would expect the limitation of not being able to write 16 bit code
should be documented as that is a breakign change in VB. Yes. As for 64
bit, you seem to forget this documentation was written in 1998 ?
> Better yet, get a life. Quit the childish crusade here, and go play with
> others who share your interests.
Stop being a jerk Karl.
Karl E. Peterson
> "Karl E. Peterson" <ka...@mvps.org> wrote ...
>> Bill McCarthy wrote:
>>>> Yes. Note the Newsgroup header, if this point is at all confusing.
>>>>
>>>> If you want to play language wars, please play elsewhere.
>>>
>>> <geez /> Chill out Karl. The only one trying to pervert this
>>> conversation into a language war is you.
>>
>> Serious Bill, take the language war crap elsewhere.
>
> Seriously Karl, chill out. *You* are the only one making a language war in
> this thread.
Oh, stop sputtering. You've been dragging it out across the entire group for months
now. It's just ~precious~ that you feel your agenda is somehow hidden, so go ahead
and hold on tight to that little illusion if you find it comforting in some perverse
way.
For reference, you introduced the language war aspect to this particular thread with
this post:
Message-ID: <#6i6ilbg...@TK2MSFTNGP05.phx.gbl>
Date: Thu, 29 Jan 2009 13:29:09 +1100
> Stop being a jerk Karl.
And the name-calling too. You used to be better than this.
Bill McCarthy
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:uVbTunLi...@TK2MSFTNGP02.phx.gbl...
> Bill McCarthy wrote:
>> "Karl E. Peterson" <ka...@mvps.org> wrote ...
>>> Bill McCarthy wrote:
>>>>> Yes. Note the Newsgroup header, if this point is at all confusing.
>>>>>
>>>>> If you want to play language wars, please play elsewhere.
>>>>
>>>> <geez /> Chill out Karl. The only one trying to pervert this
>>>> conversation into a language war is you.
>>>
>>> Serious Bill, take the language war crap elsewhere.
>>
>> Seriously Karl, chill out. *You* are the only one making a language war
>> in
>> this thread.
>
> Oh, stop sputtering. You've been dragging it out across the entire group
> for months now. It's just ~precious~ that you feel your agenda is somehow
> hidden, so go ahead and hold on tight to that little illusion if you find
> it comforting in some perverse way.
>
<yawn /> IOW: it's your extreme prejudices that is what's at play here .
You use to be better than this Karl.
Karl E. Peterson
> Karl E. Peterson wrote:
>>> Bill McCarthy wrote:
>>> Stop being a jerk Karl.
>>
>> And the name-calling too. You used to be better than this.
>
Just like someone else we both know, you always signal defeat when you repeat
exactly what was said to you in the previous post as though it were an original
inspiration of yours. Pathetic...
C Kevin Provance
| Just like someone else we both know, you always signal defeat when you
repeat
| exactly what was said to you in the previous post as though it were an
original
| inspiration of yours. Pathetic...
Careful there Karl, or you might find "Bill McCarthy
<Karl.Plagarizes.My.Posts>" spread across the newsgroup. <eg>
Karl E. Peterson
> "Karl E. Peterson" <ka...@mvps.org> wrote ...
>| Just like someone else we both know, you always signal defeat when you repeat
>| exactly what was said to you in the previous post as though it were an original
>| inspiration of yours. Pathetic...
>
> Careful there Karl, or you might find "Bill McCarthy
> <Karl.Plagarizes.My.Posts>" spread across the newsgroup. <eg>
Heh, you think he'd say I copied him when he copies me? <chuckle>
Isn't it just *so* 2nd grade? Y'know, when you really wanted to piss off someone
back then, how you could just repeat every word they said? Really sad to see a
grown man revert to that.
C Kevin Provance
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:%23tgTK4M...@TK2MSFTNGP03.phx.gbl...
| Heh, you think he'd say I copied him when he copies me? <chuckle>
Yes, absolutely I do. Those who are delusional see only what they want to
see. After all, I'm the one being accused of identity theft by a guy who
using my URL in his mail header. <eg>
| Isn't it just *so* 2nd grade? Y'know, when you really wanted to piss off
someone
| back then, how you could just repeat every word they said? Really sad to
see a
| grown man revert to that.
You see a grown man here? Well, you're a better man that I, Charlie Brown.
;-)
Personally, my favourite way to piss off bullys was to smile in their face
and say nothing. No matter how obnoxious or vulgar, it was that smile that
turned their faces red in rage. Reverse psychology is an amazing tool!
Bill McCarthy
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:%23tgTK4M...@TK2MSFTNGP03.phx.gbl...
>C Kevin Provance wrote:
>> "Karl E. Peterson" <ka...@mvps.org> wrote ...
>>| Just like someone else we both know, you always signal defeat when you
>>repeat
>>| exactly what was said to you in the previous post as though it were an
>>original
>>| inspiration of yours. Pathetic...
>>
>> Careful there Karl, or you might find "Bill McCarthy
>> <Karl.Plagarizes.My.Posts>" spread across the newsgroup. <eg>
>
> Heh, you think he'd say I copied him when he copies me? <chuckle>
>
> Isn't it just *so* 2nd grade?
ROFLMAO ! Look at you two desperately making things up. You really should
chill out Karl. But hey, need the last word ?? Knock yourself out :P
C Kevin Provance
"Bill McCarthy" <Douche Bags R US> wrote in message
news:%23vaO3FO...@TK2MSFTNGP06.phx.gbl...
| ROFLMAO ! Look at you two desperately making things up. You really
should
| chill out Karl. But hey, need the last word ?? Knock yourself out :P
Do you hear something Karl? Sounds like a chihuahua with it's tail stuck in
the door. Give it a good swift kick, will ya? <g>
Frank
wrote:
in <#tgTK4Mi...@TK2MSFTNGP03.phx.gbl>
Interesting observation, but that's how I've seen Microsoft for several
years now and I know I'm not the only professional who has made the same
comment.
Frank
Karl E. Peterson
> "Karl E. Peterson" <ka...@mvps.org> wrote ...
>>C Kevin Provance wrote:
>>> "Karl E. Peterson" <ka...@mvps.org> wrote ...
>>>| Just like someone else we both know, you always signal defeat when you repeat
>>>| exactly what was said to you in the previous post as though it were an original
>>>| inspiration of yours. Pathetic...
>>>
>>> Careful there Karl, or you might find "Bill McCarthy
>>> <Karl.Plagarizes.My.Posts>" spread across the newsgroup. <eg>
>>
>> Heh, you think he'd say I copied him when he copies me? <chuckle>
>>
>> Isn't it just *so* 2nd grade?
>
> ROFLMAO ! Look at you two desperately making things up. You really should
> chill out Karl.
Odd obsession you have with chilling. (Speaking of which, shouldn't you be out
fighting fires or something?) Guess you're just projecting again. <shrug>
> But hey, need the last word ?? Knock yourself out :P
:-)
C Kevin Provance
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:upqblNvi...@TK2MSFTNGP05.phx.gbl...
| > But hey, need the last word ?? Knock yourself out :P
|
| :-)
Well, with half of OZ on fire right now, maybe we won't be hearing of Billy
boy anytime soon. <eg>
Bill McCarthy
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:upqblNvi...@TK2MSFTNGP05.phx.gbl...
>
> Odd obsession you have with chilling. (Speaking of which, shouldn't you
> be out fighting fires or something?)
You're f#cking scum Karl.
Karl E. Peterson
> You're f#cking scum Karl.
Now there's a real Kodak Moment for the group to share. Nice.
Bill McCarthy
>>> be out fighting fires or something?)
>>
>
> Now there's a real Kodak Moment for the group to share. Nice.
> --
Yeh, and no doubt you're really proud of yourself, scumbag.
Karl E. Peterson
> "Karl E. Peterson" <ka...@mvps.org> wrote...
>> Bill McCarthy wrote:
>>> You're f#cking scum Karl.
>>
>> Now there's a real Kodak Moment for the group to share. Nice.
>
If I were tempted to quote an old friend of mine, I might offer, "Chill!"
:-) <-- I'll leave it to you to misinterpret that, now...
Bill McCarthy
>
> :-) <-- I'll leave it to you to misinterpret that, now...
> --
There's no misinterpreting when you say :
>> Odd obsession you have with chilling. (Speaking of which, shouldn't you
>> be out fighting fires or something?)
That's just a complete and utter scum bag thing to say.
Oh and for the record Karl, yes I have been out on the fire line, and yes I
was also in the station on standby as the fire front hit. Over 175
confirmed dead already, and we know the number is going to be a lot worse
than that. Any decent human would hang their head in sorrow. That you
would post an attack like you did is beyond scum.
C Kevin Provance
| Bill McCarthy wrote:
| > You're f#cking scum Karl.
|
| Now there's a real Kodak Moment for the group to share. Nice.
I guess McWillys claim that he does not make personal attacks, and condems
the act is all but null and void.
C Kevin Provance
message. Clever trick.
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:OHtyRryi...@TK2MSFTNGP04.phx.gbl...
Karl E. Peterson
>>>> Odd obsession you have with chilling. (Speaking of which, shouldn't you
>>>> be out fighting fires or something?)
>>>
>>> You're f#cking scum Karl.
>>
>
I think you *clearly* have more important things to be doing, than fanning flames
here.
You should be ashamed that this virtual community is drawing your attention away
from the one that truly needs you.
Bill McCarthy
You really are a jerk Karl.
Karl E. Peterson
>>>>>> Odd obsession you have with chilling. (Speaking of which, shouldn't
>>>>>> you
>>>>>> be out fighting fires or something?)
>>>>>
>>>>> You're f#cking scum Karl.
>>>>
>>>> Now there's a real Kodak Moment for the group to share. Nice.
>>>
>>> That's just a complete and utter scum bag thing to say.
>>
>> I think you *clearly* have more important things to be doing, than fanning
>> flames here.
>>
>> You should be ashamed that this virtual community is drawing your
>> attention away from the one that truly needs you.
>
You really need to start caring about what matters, rather than playing your little
online games!