Closed Bug 363230 Opened 14 years ago Closed 13 years ago

Adding a library definition (with a new UUID) around the ISimpleDomNode interface in ISimpleDomNode.idl and then compiling with midl to make a tlb causes a compile error with get_domNode.


(Core :: Disability Access APIs, defect)

Windows XP
Not set





(Reporter: mick, Assigned: surkov)


(Blocks 1 open bug)


(Keywords: access)


(2 files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
Build Identifier: 

If languages such as python are to be able to use the interface, they will need an actual compiled typelib to use the interface, rather than just an IDL or C header files.

Reproducible: Always

Steps to Reproduce:
1. run midl ISimpleDomNode.idl
(See ISimpleDomNode.idl atached to this bug, it contains the library definition wrapping the interface).

Actual Results:  
midl\oleaut32.dll : error MIDL2020 : error generating type library :
AddFuncDesc failed : get_nodeInfo (0x80070057)

Expected Results:  
Should compile a .tlb file.

I am using the Microsoft Platform SDK, and MS Visual Studio 2003 express adition to compile the IDL file. I am using Windows XP service pack 2.
I am not sure if I have wrapped the interface correctly so that midl can create a typelib.
Blocks: keya11y
Keywords: access
Does it really require a new UUID? AT vendors are already using ISimpleDOMNode, ISimpleDOMDocument and ISimpleDOMText. If we change the UUID it will break them.
The new UUID is for the library itself, not for the interfaces. The interface UUIDs have been left as they were. But, if there is to be a library wrapping all the interfaces, it needs its own UUID also. I would assume this won't change  the way that others use these interfaces (but not being an expert, I can't be sure).
I'm not up on how the library aspect of this works. Do we use the same UUID when we wrap the ISimpleDOMText and ISimpleDOMDocument, since they're part of the same DLL? Or, do we not need to wrap those? (We probably do).
Ever confirmed: true
Good point. This would mean that all of the interfaces (ISimpleDomNode, ITextDom etc) will have to be in the one idl file, wrapped in one library definition. If this is anoying, I guess they could be in separate files, but each would have to be wrapped in its own library, with its own unique UUID. I don't believe that they could all share the same library UUID as surely this would cause conflicts when using more than one of the libraries.  
I believe there will be a similar issue for IA2 support. Not sure if the IA2 .idl has been modified for this yet.
Blocks: ia2
No longer blocks: keya11y
This one is blocking Bryan Garaventa on the mailing list.
Assignee: aaronleventhal → surkov.alexander
If I understand right then we should somehow to change ISimple* interfaces but we can't if we don't want to broke compatibility. Do I get correctly?
Surkov, I think it depends on what the change is. Apparently adding IDispatch support or the library definition won't break compatibility. And we'll make sure to test that.

What is necessary to change to make it compile?
(In reply to comment #9)
> Surkov, I think it depends on what the change is. Apparently adding IDispatch
> support or the library definition won't break compatibility. And we'll make
> sure to test that.

So the bug is we should include library definition into our idl files, right?
If so then should we declare one library definition for all ISimple* interfaces?
and should we generate type library additionally?

(In reply to comment #9)

> What is necessary to change to make it compile?

(In reply to comment #9)
> What is necessary to change to make it compile?

Ok I've tried to remind my self all this stuff and got the following

1) make those disp ID constants +ve integers. usually 1, 2, ,3 etc. that stop
the error you see (the COMM error is a parameter error which is not much help
in this case!) 

2) you then have a problem with the local function but I'm not sure what you
are trying to do.

3) if this is supposed to be a disp interface then you want
  interface ISimpleDOMNode : IDispatch
you have it inheriting from IUnknown

4) the first line in a library should be
   importlib("stdole32.tlb"); and sometime "stdole.tlb";
can't remember quite why

Notes: you aught to add version, helpstrings and I personally would not nest
the definitions of the library and interface but but the library after the
iface. I deed if you already have the iface IDL then I pretty sure you can
reference it (include) rather than repeat it all here.

I'm not sure but you might want to declare an object in the librery IDL that
can be created using coclass, however I think in case there si a factory

Hope that helps a little

Removing the id(foo) items from the *.idl allows it to compile a *.tlb (midl.exe no longer crashes when those are removed).
Attached patch patchSplinter Review
Attachment #330739 - Flags: review?(aaronleventhal)
Could you check if the patch addressed the issue?
Comment on attachment 330739 [details] [diff] [review]

What does the change do?
(In reply to comment #15)
> (From update of attachment 330739 [details] [diff] [review])
> What does the change do?

-I means include directory. I added import ISimpleDOMDocument and ISimpleDOMText into ISimpleDOMNode to keep them into one library.
Found no regressions with JAWS using this patch in a build.
Attachment #330739 - Flags: review?(aaronleventhal) → review+
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to James Teh [:Jamie] from comment #19)
> ImplementationFeatures/MSAA links to old IDL files which don't have this
> fix. These links should probably be updated. I eventually found
> public/msaa/ISimpleDOMNode.idl

You need to log in before you can comment on or make changes to this bug.