Run afoul of duplicate IIDs from multiple includes!

[Fred Harris]

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)

[jcfuller]

Cant you change the prefix in pbrow?

James

[Fred Harris]

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!

[Richard Angell]

Fred and others with dual equates situation:

Please see this Source thread

http://www.powerbasic.com/support/pbforums/showthread.php?p=293517#post293517

[Fred Harris]

That Will Make My Mondy!

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

Fred

[Richard Angell]

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

[Herman Kieskamp]

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.

[Richard Angell]

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.

[Herman Kieskamp]

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.

[Bob Zale]

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.

[Richard Angell]

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.

[Herman Kieskamp]

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.

[Bob Zale]

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?

[José Roca]

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.

[Fred Harris]

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.

[José Roca]

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.