"Doug Turner" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I have landed a new implementation of nsDebug that can be used when > linking directly to XPCOM and when using the XPCOM glue library. > nsDebug now depends on an interface known as nsIDebug. This allows > xpcom glue to use the same version of the code as the xpcom library uses > thus both reducing footprint as well as ensuring that you get all of the > functionaltiy in nsDebug in both glue and non-glue modes. > > In C++ code, you should not directly use nsIDebug, but rather use the > wrapper class nsDebug for your needs. > > nsIDebug is marked as UNDER_REVIEW. I plan to freeze it for the 1.5 > milestone. If we make any changes between now and 1.5, we will change > the IID of the interface. > > Regards, > > Doug Turner >
Hello Doug, You know what would be extremely helpful? Answer: To come up with a Test Control Container - much like the Microsoft ActiveX test container. I know you probably do not care for the "M" word. But I have to tell you after developing a couple zillion OCX's and ATL controls - that little test pad was worth it's weight in gold. As a relatively new person to the XPCOM architecture, most of the problems I have experienced have come as a result of integrating my stuff with the Browser. It is ugly when you install your control within browser tree and it is not functioning correctly. It would be extremely nice to have some sort of a skeleton test pad so-to-speak. It does not have to be fancy - but just something that would tell us all of the methods and properties and if the browser will be able utilize the control properly. It would also would really cool if you could dial in the Mozilla build that you are targeting. As usual, I am probably dreaming. The nsDebug interface will be very helpful and I commend you for implementing such an interface. Thank you, Tom-
