interfaces with events
Chris Dunaway
Would I need a separate event class? How can this be done with VB6?
Thanks
Chris
--
If you don't like lunchmeat, please remove it from my e-mail address to
send me an e-mail
Ken Halter
Expose events from implemented classes
http://www.vbrad.com/pf.asp?p=source/src_expose_evt.htm
--
Ken Halter - MS-MVP-VB - Please keep it in the groups..
http://www.vbsight.com - http://www.vbsight.com/MultiColumn.htm
http://www.vbsight.com/TBGDialogCTL.htm
"Chris Dunaway" <dunawayc@_lunchmeat_sbcglobal.net> wrote in message
news:Xns92A98A...@207.46.239.39
Matthew Curland
interface cannot raise events. Unless you want to fake the event pattern
without using WithEvents, there is only one to make this happen.
COM events are raised via the IConnectionPointContainer interface, which is
implemented by any VB class that supports events. A VB class can only
support one event set. However, this event set can have multiple guids. The
multiple guid support enables the binary compatibility support for events.
The list of compatible event guids supported by a given public class is
stored as a resource _SRCIID_CLASSNAME in the VB binary. These resources are
a 4-byte byte count followed by a list of guids (oldest to newest) that are
considered compatible and need to be supported by the VB class's
IConnectionPointContainer implementation.
Obviously, editing these guid resources is not officially supported, but it
is a very easy way to support a natural eventing interface. You can do it by
hand using the VC resource editor, or use the binary compatibility editor
from my book (on the CD Updates at http://www.PowerVB.com), which makes this
trivial. Here are the steps:
0) You can only do this with a public class in a project with binary
compatibility set
1) Define a public class with the events/interface you care about (Class1)
2) Define a second public class that implements the Class1 interface, and
lists the Event statements in the same order as Class1.
3) Compile Exe/Dll
4) Make a copy of the compiled file (MyDll.cmp) to use as your compatibility
file and set the compatibility file.
5) Load the 'PowerVB Binary Compatibility Editor' add-in and run the
'Add-Ins/Binary Compatibility Changes/Edit Event Guids'
6) Select Class1 in the dialog and copy the guid value (it's read-only, but
you can copy it)
7) Select Class2, click Insert, and replace the new guid value with the guid
from Class1
8) Choose OK
Class2 can now be assigned to a 'WithEvents As Class1' variable. To support
multiple event sets, simply define them so that the MemberId (also called
DISPID) values do not overlap. You can do this easily with the compatibility
editor. You can also do other manipulations like changing the default
interface of Class2 using other tools in the book.
-Matt
"Chris Dunaway" <dunawayc@_lunchmeat_sbcglobal.net> wrote in message
news:Xns92A98A...@207.46.239.39...
Chris Dunaway
news:uJBxzlUdCHA.1756@tkmsftngp12:
Thanks Matt, I ordered the book. I'm not sure I completely understand
what you are talking about (but I hope to learn).
Let me describe what I wish to accomplish and perhaps you can tell me if
your method would work for me.
I have a main app whose sole function is to process text files in various
formats and convert them to another proprietary format. I envision that
I will have a separate .dll for each input format I wish to support. The
main app will call the appropriate .dll depending on the file to be
imported. For example, if the input file is comma delimited (and that is
identified by its extension) then the main app will call the .dll
responsible for parsing the comma delimited file. If the input file is a
fixed length record format, then a different .dll will be called.
Now, I want the main app to pop up a progress dialog indicating the
progress of the file conversion. I thought that using a interface would
be an ideal solution. If each .dll implemented a certain interface, then
the main app could simply declare an object of that interface and call
the interface methods. I could then add other .dlls and they would
automatically work without changing the main app. I would have a
configuration file that would keep track of which .dll's were registered
with the main app that could be read in at startup.
For simplicity, I thought the interface would have a method called
Process and an event called Progress. The process method would handle
the chore of opening and processing the input file and the progress event
would be used to update the main app as it went along. My goal was that
the .dll would have no UI code at all. That way it could be reused very
easily.
Sorry for the lengthy post, but will your technique be useful for such a
project?
Thanks to all for the replies.
Larry Serflaten
>
> Thanks Matt, I ordered the book. I'm not sure I completely understand
> what you are talking about (but I hope to learn).
If you're talking about his book, you're not the only one in that group!
<g>
LFS
Matthew Curland
coclass, interface, and dispinterface, where the default interface of the
coclass is the interface and the default source interface of the coclass is
the dispinterface (use a VB-generated Ax Dll with one MultiUse class with at
least one event as your typelib model). You can now reference this typelib
in each of your plug-in Dlls, implement the interface, and copy the event
guid (from the dispinterface) to your compatibility file as described below.
Note that you're responsible for making sure the events match (you can
check/enforce this in the compatibility file with the compatibility editor).
One interesting alternative in your situation is to use the dynamic dll
loading described in chapter 7 of the book to load your dlls directly from
the application directory instead of via the registry. This gives you the
option of simply using the same compatibility file for each Dll instead of
doing anything with Implements. Given the extremely targeted scope of the
plugin Dlls you're creating, this might be the easier approach. It certainly
makes adding plugins easier if you don't have to register them. -Matt
"Chris Dunaway" <dunawayc@_lunchmeat_sbcglobal.net> wrote in message
news:Xns92ABA4...@207.46.239.39...
Matthew Curland
Just trust me that you're in much less pain that I went through: It was much
harder to understand starting from scratch than learning it from a book. You
don't have to understand how everything works in order use it. I'm not
expecting most people to invest the time to fully groc how it all works
(especially the VBoost aggregation, threading architectures, and custom
assembly bits), but I do think that any moderately experience VB programmer
can use the material without too much pain. -Matt
"Larry Serflaten" <serf...@usinternet.com> wrote in message
news:egJU0#udCHA.2592@tkmsftngp09...
Larry Serflaten
> Thanks for the plug, Larry:)
>
> Just trust me that you're in much less pain that I went through: It was much
> harder to understand starting from scratch than learning it from a book. You
> don't have to understand how everything works in order use it. I'm not
> expecting most people to invest the time to fully groc how it all works
> (especially the VBoost aggregation, threading architectures, and custom
> assembly bits), but I do think that any moderately experience VB programmer
> can use the material without too much pain. -Matt
I am (possibly like yourself) not a cut & paste programmer. I want to know all
about whatever I plan to add to my programs. Your book covers a lot of detailed
work that fills in that last 10% between acceptable, and polished code (Including
some areas between possible and impossible in VB). No doubt it must have been
a huge effort to make appear less confusing than it already is.
But, even for the tips that can be used in everyday code, I'd still recommend that
every VB programmer get a copy....
Good job, Matt!
(Now _That's_ a plug ;-)
LFS