Announcement

Collapse
No announcement yet.

Run afoul of duplicate IIDs from multiple includes!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • José Roca
    replied
    Judging by this statement

    I also find it a pitty that there is no backward compatibility with the old COM interface calls. Although they might have become obsolete, I now have to go through all my source's to remove all object call, get, set, etc. A bit of a bummer.
    Herman thinks that the new COM support for direct interface calls has replaced the old OBJECT CALL and you have to modify your applications, but he is wrong. What happens is that each one uses different interface definitions.

    BTW you need both, because there are components with dispatch-only interfaces that can't be used with direct interface calls, and there are low-level interfaces that can't be used with OBJECT CALL. Dual interfaces can be used using both techniques, with the appropriate declarations for the one you're going to use.

    Leave a comment:


  • Fred Harris
    replied
    Generate Dispatch interfaces
    That's what I eventually did. I'm surprised to see this old post still going on. I didn't think it was any big deal considering the magnitude of the changes made to PowerBASIC. Once I sort of understood what was going on, I was able to make the necessary changes to a rather large app using search/replace in a half hour or so. That was weeks ago.

    Leave a comment:


  • José Roca
    replied
    Herman,

    The interface definitions for direct interface calls can't be used with OBJECT CALL. If you want to generate interface declarations to be used with OBJECT CALL/GET/LET/SET, check the Generate Dispatch interfaces only option.
    Last edited by José Roca; 20 Sep 2008, 10:10 PM. Reason: Mispelled name

    Leave a comment:


  • Bob Zale
    replied
    Instead of making a broad, unsubstantiated complaint, how about a specific example? Some code? Otherwise, you're just misleading your friends.

    Can we see an OBJECT CALL that won't compile?

    Leave a comment:


  • Herman Kieskamp
    replied
    Originally posted by Bob Zale View Post
    Interface names are created by the author, not by PowerBASIC. If you are displeased with a name, you should contact the author about it.

    "I also find it a pity that there is no backward compatibility with the old COM interface calls."

    The truth is, there is 100% backward compatibility with PB/WIN 8.0. I cannot imagine why you'd say such a thing.
    1. Im not talking about the com interfaces names, but the 'int_' prefix from the pbrow that is not optional to the name, and needs manual adjusting, to be able to load more than 1 'standard' exported com interface.

    2. Compiler complains about every 'object call', and also complains when there is a 'to vvar' statement instead the vvar=, also I had to adjust all the source files to reflect the newly created object include files. I can't really call that backward compatible.

    Don't get me wrong, I like the new approach, but seems to me I need to keep up 2 environments till everyting is adjusted and compiles normally.
    The first(biggest) application adjusting already cost me 4 hours, and I'm still not through with it. Thats just for the com sections, I needed also to remark the define arc and rectangle functions from commctrl.inc as being reserved codewords. And had to rename a few parameters in the provided win32api.inc and commctrl and comdlg32 because they seemed to be defined somewhere else.
    i.e. style to istyle, and a few others.
    Am I the only one ??

    Herman.

    Leave a comment:


  • Richard Angell
    replied
    One of the big additions in the new browser is to generate unique program and class id's. So if you select to only add interface prefixes where a potential conflict exists, then updating existing code can be a little simpler to do ... if you are using a real large number of interfaces in an app.

    It is true that some older code will need update, but all-in-all, the ability to use direct interfaces and Compound Object References, among other new and improved COM features including to create our own classes, etc, etc. extends the COM/OOP capability to allow those needing or wanting to use it to now have a far more complete toolbox.

    One headache is getting more time to use it and learn how to use itt properly, especially if we have been used to VBA/VB offerings in these areas previously.

    Leave a comment:


  • Bob Zale
    replied
    Interface names are created by the author, not by PowerBASIC. If you are displeased with a name, you should contact the author about it.

    "I also find it a pity that there is no backward compatibility with the old COM interface calls."

    The truth is, there is 100% backward compatibility with PB/WIN 8.0. I cannot imagine why you'd say such a thing.

    Leave a comment:


  • Herman Kieskamp
    replied
    Yeh, I noticed in the meantime, and changed the int_ into different (object) related int_, like; int_outlook_, int_word_, int_excel_, etc. a bit shame that this is not an option like the interfacenaming is. You might think that PB considers we never user more than 1 interface per application/library. I can't think of a reason why to use similar interface name definitions in the different includes, except for maybe the fact that there is no naming convention, or some names might become to long or to cryptic to use, so they(pb)decided to leave it up to us.
    I also find it a pitty that there is no backward compatibility with the old COM interface calls. Although they might have become obsolete, I now have to go through all my source's to remove all object call, get, set, etc. A bit of a bummer.

    Herman.

    Leave a comment:


  • Richard Angell
    replied
    Sorry. I removed that post because it is now better to re-generate the includes with the PB COM Browser. See the Options setup and go for it.

    Leave a comment:


  • Herman Kieskamp
    replied
    Originally posted by Richard Angell View Post
    Fred and others with dual equates situation:

    Please see this Source thread

    http://www.powerbasic.com/support/pb...517#post293517
    Hmmm, thread/link is not valid ?

    Herman.

    Leave a comment:


  • Richard Angell
    replied
    Glad you got it Fred.

    Please note that it sparsely uses a few of the new PB BASIC statements where appropriate to save time. E.g. in the last functions second DO -LOOP, the BUILD$ function is employed. I'll suggest that as more user come on line in the coming weeks and get an opportunity to use BUILD$ for multiple concatenation situations ... many will be really pleased with it's performance.

    I've also employed the new DISPLAY OPENFILE function.

    PBWin90 has a plethora of built-in equates for controls and DISPLAY dialogs, among other things. This means one does not need to include the COMDLG32.inc, in this case.

    See ya

    Leave a comment:


  • Fred Harris
    replied
    That Will Make My Mondy!

    Thanks a bunch Richard! I owe you one. I accidentally posted after your source code contribution. Sorry!

    Fred

    Leave a comment:


  • Richard Angell
    replied
    Fred and others with dual equates situation:

    Please see this Source thread

    http://www.powerbasic.com/support/pb...517#post293517

    Leave a comment:


  • Fred Harris
    replied
    Well, here it is about midnight John, and I've been playing with the barnyard animals most of the day - except for my little excursion into real work, that is updating that 'real' program to 9.0. I'll take another look tomorrow and get back here with my findings. I hope your suggestion works!

    Leave a comment:


  • jcfuller
    replied
    Cant you change the prefix in pbrow?

    James

    Leave a comment:


  • Run afoul of duplicate IIDs from multiple includes!

    I've come to grief over duplicate ProgD & IID definitions due to including PB COM Browser *.inc files (oWord.inc and oExcel.inc) for both Word and Excel in the same application. This wasn't a problem with PB 7 & 8 but I hate to say its a problem now. I'm not sure how best to resolve it. Any input would be appreciated.

    Here's the details. If you include all the IIDs, Interfaces, etc for Excel you'll find this in the PBExcel.inc file...

    ' Version Independant ProgID's
    $PROGID_Application = "Excel.Application"

    If you include Word you'll have this...

    ' Version Independant ProgID's
    $PROGID_Application = "Word.Application"

    So the string equate names clash. But that isn't the bad part, because for one thing there aren't that many ProgIDs involved. I can just use this instead...

    ' Version Independant ProgID's
    $PROGID_ExcelApplication = "Excel.Application"

    and...

    ' Version Independant ProgID's
    $PROGID_WordApplication = "Word.Application"

    But Microsoft used the same names for very, very many Interfaces in these two apps, and I'm getting hundreds of Duplicate Name Errors for the IIDs associated with all these interfaces. So for each error I'm thinking I'll have to make alterations both at the point of the IID definition and at the point of the corresponding Interface definition. The process is..

    1) Compile & Error Out;

    2) Go to cursor at line that errors out, e.g,

    $IID_Adjustments = GUID$("{000C0310-0000-0000-C000-000000000046}")

    and prepend 'Excel' tp front of 'Adjustments'

    $IID_ExcelAdjustments = GUID$("{000C0310-0000-0000-C000-000000000046}")

    3) Search through file for any incidences of IID and change there. Its
    fairly brutal.

    Could an identifier from the app name be made a part of the IID equates so as to prevent this? Any ideas on how to fix it now? (easier than what I'm doing)
Working...
X