I can't do this: typedef long nsMsgRuleActionType; and then put in an interface: const nsMsgRuleActionType nsMsgFilterActionNone=0; even though nsMsgRuleActionType is a long. I get: nsIMsgFilter.idl:42: Warning: const decl 'nsMsgFilterActionNone' was not of type short or long, ignored That's kind of lame... (if I can't have enums, at least give me this)
I know jband will want to have input on this
I think that this is a limitation we can live with. The way some of the code is structured (esp. the xpidl_typelib.c) this looks like a pain to support. If it gets fixed then it has to get fixed for all code generators. *And* it has to be limited to the types that resolve down to the useful types that we can support on all mappings - int16, uint16, int32, and uint32. FWIW... alecf, I don't think that you really do your users a service by trying to make it look like a C++ enum type when it isn't. You're not getting C++ enum type safely here , so why try to make it look like you are? These are xpcom interfaces and the implementations need to do runtime bounds checking anyway for continued safety as the code matures. I think there are more inmportant things to fix, but I've been overruled before :) It is worth noting that shaver has code in the xpidl_typlib.c to try to supports *lots* of types for constants. But most don't map into useful types for C++ class static constants that we can generate into .H files. I foolishly '#if 0'ed the code out rather than deleting it. Please no one try to revive it.
heh, well I'm making one more pass at the enum argument on mozilla.xpcom... I was hoping this was a cheap solution.. I was hoping it was as simple as changing some code that might look like if (typeof(ident) != long && typeof(ident) != short) then... to if (resolved_typeof(ident) != long && resolved_typeof(ident) != short) then... and then storing it in the typelib as the resolved type. Again, I'm not trying to change the behavior of XPConnect at runtime, just the generated C++ headers.
*** Bug 8992 has been marked as a duplicate of this bug. ***
*** Bug 12601 has been marked as a duplicate of this bug. ***
Marking as assigned.
This is an enhancement, and doesn't need to be on dogfood or m12 radar; shifting to m14.
Enhancement. Kicking out a few milestones.
Target Milestone: M14 → M16
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
oh thanks! I forgot about this and had gotten in the habit of just working around it.
You need to log in before you can comment on or make changes to this bug.