Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#30 DispatchEvents constructor that supports GUID

open
nobody
None
4
2007-11-21
2007-10-12
Jason Smith
No

Currently, the DispatchEvents 3-param/4-param constructors accept only a prog-id. It appears that not all CoClasses that support events have a prog-id. Case in point, Excel.Workbook. Doesn't exist. Of if it does, I can't find it.

It is pretty easy to find the GUID for the default event interface for a CoClass using tlbinf32.dll.

Would it be possible to have the 3-param constructor accept either a prog-id *or* the GUID to the event interface for the object?

Thanks!

Discussion

  • Jason Smith
    Jason Smith
    2007-10-12

    Logged In: YES
    user_id=1895760
    Originator: YES

    Here is an example. You can tell me if this is useless information or not. :-)

    Private Sub Command1_Click()
    Dim TLI As New TLIApplication
    Dim Info As TypeLibInfo
    Dim CC As CoClassInfo
    Dim TI As TypeInfo

    Set Info = TLI.TypeLibInfoFromFile("C:\Program Files\Microsoft Office\OFFICE11\EXCEL.exe")
    For Each CC In Info.CoClasses
    Debug.Print "CC=" & CC.Name, CC.Guid,
    If Not CC.DefaultEventInterface Is Nothing Then
    Debug.Print CC.DefaultEventInterface.Guid
    End If
    Debug.Print
    Next CC
    End Sub

    If I provide Jacob with this information, can it be used to set up events in lieu of a progid?

     
  • clay_shooter
    clay_shooter
    2007-11-06

    Logged In: YES
    user_id=1189284
    Originator: NO

    Is this how DispatchEvents.cpp works today. getClassInfoFromProgIdTypeLib() calls CLSIDFromProgID to get the CLSID from the registry. It then converts the CLSID to a character string. Then it loads the type lib from a file and gets the type info for the GUID that is the CLSID previously created.
    <p>
    ExcelEventTest.java registers for events with:

    String pid = "Excel.Application";
    String typeLibLocation = "C:\\Program Files\\Microsoft Office\\OFFICE11\\EXCEL.EXE";
    // Grab The Component.
    ActiveXComponent axc = new ActiveXComponent(pid);
    try {
    // Add a listener (doesn't matter what it is).
    DispatchEvents de;
    if (typeLibLocation == null) {
    de = new DispatchEvents(axc, new ExcelEvents());
    } else {
    de = new DispatchEvents(axc, new ExcelEvents(), pid,
    typeLibLocation);
    }
    if (de == null) {

    Of course I may be misunderstanding what you are talking about

     
  • Jason Smith
    Jason Smith
    2007-11-06

    Logged In: YES
    user_id=1895760
    Originator: YES

    Let me restate the problem, because I have confused myself.

    ActiveX controls have a standard event interface. No problem. Jacob finds that just fine with the 1-parameter constructor.

    Office automation objects don't support that standard interface, but they do have an event-handling interface. And if Jacob has the prog-id for the object (i.e. - 'Excel.Sheet'), it can find the associated event-handler. Great!

    But there are a number of Office objects that support events, but no prog-id. I think 'Excel.Sheet' is actually one of those. You'd expect it to have a prog-id, and it DOES support events, but it doesn't have a prog-id.

    ---------------------------------------

    So what I figured out is that if you go look at the type library, you can see all the CoClasses. And guess what? They have GUIDs for the default event handler associated with them. Not a prog-id, but a GUID. See the code sample in VB in the previous post.

    So what I would like to be able to do is specify the GUID for the event handler, the same way I specify the prog-id today.

    Something like:
    de = new DispatchEvents(axc, new ExcelEvents(), "{00ABCDEF-0000-000000000001}");

    If you need me to, I can pull out the event-handler GUIDs for the Excel CoClasses. I'm currently pulling out everything else BUT that. :-)

     
  • Jason Smith
    Jason Smith
    2007-11-06

    Logged In: YES
    user_id=1895760
    Originator: YES

    More info. And a correction.

    Excel supports the following prog-ids:
    Excel.Application
    Excel.Sheet
    Excel.Chart

    It supports the following CoClasses:
    Application
    Chart
    Global
    OLEObject
    QueryTable
    Workbook
    Worksheet

    It would be very useful to be able to trap events on the Workbook, but you can't do that with Jacob today.

    And 'Excel.Sheet' is a prog-id. My mistake.

     
  • clay_shooter
    clay_shooter
    2007-11-06

    Logged In: YES
    user_id=1189284
    Originator: NO

    Someone has to look at the JNI code in DispatchEvents.cpp to figure out what would change if a GUID is passed in instead of a prog-id. It looks to me like it would be a simple change in
    getClassInfoFromProgId(LPOLESTR bsProgId,LPTYPEINFO *pClassInfo). That guy converts a prog id to a CLSID and then finds the associated TypeLib in the registry. It then loads that type lib. It might be a simple fix to disable the progid-->clsid conversion when the passed inparameter starts with a "{" and ends with a "}", or some other hack to make this happen.

     
  • Jason Smith
    Jason Smith
    2007-11-06

    Logged In: YES
    user_id=1895760
    Originator: YES

    Prog-ids have a somewhat distinct signature that should never match a GUID. GUIDs are easily recognizable with a regular expression.

    All you need is a hook into the C++ part that skips the prog-id and TypeLib lookup. I think. I am guessing that this will work. :-)

     
  • Jason Smith
    Jason Smith
    2007-11-21

    • priority: 5 --> 4
     
  • Jason Smith
    Jason Smith
    2007-11-21

    Logged In: YES
    user_id=1895760
    Originator: YES

    This one probably involves a research project, so I set the priority down a notch. No hurry on this one. I hope that helps.