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). 2. 3. 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.

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).

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.

This one is blocking Bryan Garaventa on the mozilla.dev.accessibility mailing list.

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 someplace. 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).

Could you check if the patch addressed the issue?

Comment on attachment 330739 [details] [diff] [review] patch What does the Makefile.in change do?

(In reply to comment #15) > (From update of attachment 330739 [details] [diff] [review]) > What does the Makefile.in 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.

https://developer.mozilla.org/en-US/docs/Accessibility/AT-APIs/ImplementationFeatures/MSAA links to old IDL files which don't have this fix. These links should probably be updated. I eventually found http://hg.mozilla.org/mozilla-central/raw-file/2520866d5874/accessible/public/msaa/ISimpleDOMNode.idl

(In reply to James Teh [:Jamie] from comment #19) > https://developer.mozilla.org/en-US/docs/Accessibility/AT-APIs/ > ImplementationFeatures/MSAA links to old IDL files which don't have this > fix. These links should probably be updated. I eventually found > http://hg.mozilla.org/mozilla-central/raw-file/2520866d5874/accessible/ > public/msaa/ISimpleDOMNode.idl done