Results 1 to 6 of 6

Thread: RC6 possible bug

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    380

    RC6 possible bug

    Hi Olaf, as you know I generate (in VO) class wrappers for COM libraries to allow early bounding from my side.
    While generating them for RC6 I found these strange things
    Code:
    METHOD Init(ObjID, fROTCHECK) CLASS cHashD
    
        self:cIID := "{562A7F89-3698-4645-9471-5C4B1E2FE2C8}"
        self:cProgId := "RC6.cHashD"
        self:cClsId :=  "{3155D01B-C852-4EBE-8260-E6384DB4B69B}"
    
    
        IF (ObjID=NIL)
            ObjId := "RC6.cHashD"
        ENDIF
        SUPER:Init(ObjID, 0, .T., fRotCheck)
        SELF:_dwFuncs    := 31
        SELF:_dwVars     := 0
        RETURN SELF
    Code:
    METHOD Init(ObjID, fROTCHECK) CLASS vbIEnumerable
    
        self:cIID := "{86598E06-B6F6-41EE-903A-9FE7A546E5A5}"
        self:cProgId := "RC6.cHashD"
        self:cClsId :=  "{3155D01B-C852-4EBE-8260-E6384DB4B69B}"
    
    
        IF (ObjID=NIL)
            ObjId := "RC6.cHashD"
        ENDIF
        SUPER:Init(ObjID, 0, .T., fRotCheck)
        SELF:_dwFuncs    := 8
        SELF:_dwVars     := 0
        RETURN SELF
    Code:
    METHOD Init(ObjID, fROTCHECK) CLASS vbIDispatch
    
        self:cIID := "{B52B4835-84B4-4B57-AE6B-E1402E3B7518}"
        self:cProgId := "RC6.vbIEnumerable"
        self:cClsId :=  "{C1FF775B-FF93-4446-9B3D-28FCB7F75A58}"
    
    
        IF (ObjID=NIL)
            ObjId := "RC6.vbIEnumerable"
        ENDIF
        SUPER:Init(ObjID, 0, .T., fRotCheck)
        SELF:_dwFuncs    := 9
        SELF:_dwVars     := 0
        RETURN SELF
    Probably not a problem but I thought I should report.
    Carlos

  2. #2
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,685

    Re: RC6 possible bug

    Do you mean the self:cProgID? ... (in the 2 cases below cHashD)?

    FWIW...
    All 3 Classes are marked as "Public Not Creatable"...

    The first (cHashD) is implementing: vbIEnumerable (and can be instantiated on the outside via cConstructor)

    The other two are (mainly) just interface-defs, which can be implemented on the outside -
    (though vbIEnumerable implements also vbIDispatch).

    HTH

    Olaf

  3. #3

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    380

    Re: RC6 possible bug

    Quote Originally Posted by Schmidt View Post
    Do you mean the self:cProgID? ... (in the 2 cases below cHashD)?
    Olaf
    Yes, I mean ProgID.
    So I can safely remove those vb* classes from my code.
    Thanks
    Carlos

  4. #4

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    380

    Re: RC6 possible bug

    Olaf, sorry to bother you again

    I still have issues with RC6, this time related with cWidgetBase. VO generates the following:
    Code:
    METHOD Init(ObjID, fROTCHECK) CLASS cWidgetRoot
    
        self:cIID := "{F16B18FB-E07F-4278-88DA-B291D235BB00}"
        self:cProgId := "RC6.cWidgetRoot"
        self:cClsId :=  "{42979366-2AAD-4876-96E4-A786D5A3305B}"
    
    
        IF (ObjID=NIL)
            ObjId := "RC6.cWidgetRoot"
        ENDIF
        SUPER:Init(ObjID, 0, .T., fRotCheck)
        SELF:_dwFuncs    := 66
        SELF:_dwVars     := 0
        RETURN SELF
    Code:
    METHOD Init(ObjID, fROTCHECK) CLASS cWidgetBase    
        self:cIID := "{678B1972-85B5-4994-82AD-9CE10AECCE0D}"
        self:cProgId := "RC6.cWidgetRoot"
        self:cClsId :=  "{42979366-2AAD-4876-96E4-A786D5A3305B}"
    
    
        IF (ObjID=NIL)
            ObjId := "RC6.cWidgetRoot"
        ENDIF
        SUPER:Init(ObjID, 0, .T., fRotCheck)
        SELF:_dwFuncs    := 163
        SELF:_dwVars     := 0
        RETURN SELF
    Please note the same RC6.cWidgetRoot in both classes.

    When executing something like this to use a self made widget:
    Code:
    oPanelOpen := cwImagesPanel{}
    oSB := cwSlimScrollBar{}
    oListOpen:Widgets:Add(oPanelOpen,"PanelOpen")
    oListOpen:Widgets:Add(oSB,"ScrollBar")
    oSB:DockTo(oPanelOpen:Widget) //--> it crashes bad in this line
    I believe I can try to pass only oPanelOpen to DockTo and access Widget from inside the function, but I wonder if this something not intentional in RC6 as wqweto's Ummm doesn't generate comClasses to both WidgetBase and WidgetRoot either.
    It used to work fine with vbRichClient5
    Carlos

  5. #5
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,685

    Re: RC6 possible bug

    Quote Originally Posted by Carlos Rocha View Post
    Olaf, sorry to bother you again

    I still have issues with RC6, this time related with cWidgetBase. VO generates the following:
    Code:
    METHOD Init(ObjID, fROTCHECK) CLASS cWidgetRoot
    
        self:cIID := "{F16B18FB-E07F-4278-88DA-B291D235BB00}"
        self:cProgId := "RC6.cWidgetRoot"
        self:cClsId :=  "{42979366-2AAD-4876-96E4-A786D5A3305B}"
    
    
        IF (ObjID=NIL)
            ObjId := "RC6.cWidgetRoot"
        ENDIF
        SUPER:Init(ObjID, 0, .T., fRotCheck)
        SELF:_dwFuncs    := 66
        SELF:_dwVars     := 0
        RETURN SELF
    Code:
    METHOD Init(ObjID, fROTCHECK) CLASS cWidgetBase    
        self:cIID := "{678B1972-85B5-4994-82AD-9CE10AECCE0D}"
        self:cProgId := "RC6.cWidgetRoot"
        self:cClsId :=  "{42979366-2AAD-4876-96E4-A786D5A3305B}"
    
    
        IF (ObjID=NIL)
            ObjId := "RC6.cWidgetRoot"
        ENDIF
        SUPER:Init(ObjID, 0, .T., fRotCheck)
        SELF:_dwFuncs    := 163
        SELF:_dwVars     := 0
        RETURN SELF
    Please note the same RC6.cWidgetRoot in both classes.
    Seems to me, that the recent implementation of VO (or the tool which produces these "wrapper-descriptions") -
    kind of "broke" the way TypeLibs are parsed (cWidgetRoot seems to be Ok though, only cWidgetBase is "messed up").

    When I use OleView, I can see cWidgetBase and cWidgetRoot defined this way:
    Code:
    [
      uuid(6325FBC4-F431-4EE6-8514-311B1FFB93E7),
      version(1.0),
      noncreatable
    ]
    coclass cWidgetBase {
        [default] interface _cWidgetBase;
        [default, source] dispinterface __cWidgetBase;
    };
    
    [
      uuid(678B1972-85B5-4994-82AD-9CE10AECCE0D),
      version(1.0),
      hidden,
      dual,
      nonextensible
    ]
    dispinterface _cWidgetBase {
        properties:
        methods:
    ... a.s.o.
    and...

    Code:
    [
      uuid(42979366-2AAD-4876-96E4-A786D5A3305B),
      version(1.0),
      noncreatable
    ]
    coclass cWidgetRoot {
        [default] interface _cWidgetRoot;
        interface _cWidgetBase;
        [default, source] dispinterface __cWidgetRoot;
    };
    
    [
      uuid(F16B18FB-E07F-4278-88DA-B291D235BB00),
      version(1.0),
      hidden,
      dual,
      nonextensible
    ]
    dispinterface _cWidgetRoot {
        properties:
        methods:
    ... a.s.o
    Both class-types are flagged as "noncreatable" (which probably explains, why UMMM does not list them),
    so the VO-tool normally does not need to create any "constructor-init"-code for them -
    only the self:cIID is important for VO (to map to the correct "early-binding"-interface -
    and the Values in that field are correct in both cases)...

    Quote Originally Posted by Carlos Rocha View Post
    I believe I can try to pass only oPanelOpen to DockTo ...
    Are you sure, your DockTo-method has a proper cWidgetBase-typed argument defined?

    Quote Originally Posted by Carlos Rocha View Post
    It used to work fine with vbRichClient5
    I compile RC6 on a Win10 VM now (whereas RC5 is still compiled from within an old XP-VM) -
    but as said, I'd think that some "VO-Upgrade" changed the typelib-parsing-behaviour.

    Perhaps you have access to an earlier version of the VO-COMBridge-Generator-Tool?

    Or maybe you can fix these wrong entries "by hand" (in the "COM-lib-connector" sections your VO-tool has produced)?

    I'm talking about the defs for cWidgetBase:
    Code:
        self:cProgId := "RC6.cWidgetRoot"
        self:cClsId :=  "{42979366-2AAD-4876-96E4-A786D5A3305B}"
    
    
        IF (ObjID=NIL)
            ObjId := "RC6.cWidgetRoot"
        ENDIF
    which should be (according to my lookup via OleView):
    Code:
        self:cProgId := "RC6.cWidgetBase"
        self:cClsId :=  "{6325FBC4-F431-4EE6-8514-311B1FFB93E7}"
    
    
        IF (ObjID=NIL)
            ObjId := "RC6.cWidgetBase"
        ENDIF
    In any case, I'm about to upload a new RC6-version (still without "switched on bincomp") -
    so you might wait with these "adapting by hand"-efforts for this new version.

    HTH

    Olaf

  6. #6

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    380

    Re: RC6 possible bug

    Nothing has changed in my side. The same W10, the same old VO from 2012, but you are right about ummm, it doesn't generate these comClasses for vbRichClient5 either.
    And in fact the generated class for vbRichClient5.WidgetBase also assigns "vbRichClient5.WidgetRoot" to ProgID, and it works fine.

    I'm not excluding some fault on my side while moving from RC5 to RC6, so I'll investigate it further.

    Thanks for your time and your tremendous good work in this tool
    Carlos

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width