Solved

MSXML confusion

Posted on 2001-08-27
27
2,199 Views
Last Modified: 2012-05-04
Greetings
I am trying to make use of the MSXML dll to do a couple of things in C++/COM with XML. After downloading a couple tutorials and looking for documentation, I am somewhat confused. I am coding on a Win2K system, and here is a little test program:

#include "stdafx.h"
#include <stdio.h>
#include <iostream>

#import "msxml.dll" named_guids


int main(int argc, char* argv[])
{


     MSXML::IXMLDOMDocumentPtr ptrDoc = NULL;
     MSXML::IXMLDOMElementPtr ptrElement = NULL;
     MSXML::IXMLDOMNodePtr ptrNode = NULL;
     _variant_t xmlFile2(L"http://localhost/thsxml/configuration2.xml");
     VARIANT_BOOL vSuccess;
     BSTR xmlstr;



     try {

          CoInitialize(NULL);


          HRESULT hr = CoCreateInstance(MSXML::CLSID_DOMDocument,
                                                  NULL,
                                                  CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER,
                                                  MSXML::IID_IXMLDOMDocument,
                                                  reinterpret_cast<void **> (&ptrDoc));


          if(SUCCEEDED(hr)) std::cout << "Created Instance" << std::endl;
          else std::cout << "Failed to create instance" << std::endl;

          vSuccess = ptrDoc->load(&xmlFile2);
          if(!vSuccess) std::cout << "Failed to load file"<< std::endl;

          ptrElement = ptrDoc->firstChild;

     } catch (_com_error &e) {
          dump_com_error(e); // function not shown
     }

     return 0;
}

////////////// end code /////////////////////

What I am trying to do is load an XML file and then print out some info about it (one step at a time). The assignment to ptrElement does not work and I am not sure why. I am attempting to assign the first element of the XML page to an element pointer. tracing in the debugger shows nonzero values for vSuccess, which means (I think) that the file is loading, but I could be completely wrong about this. Does anyone have any helpful hints about this step? And more importantly, does anyone know of a good place to find up to date docs on this topic?

Thanks
--j
0
Comment
Question by:jmuldrum
  • 10
  • 9
  • 8
27 Comments
 
LVL 4

Expert Comment

by:AssafLavie
ID: 6428600
The default setting for the MSXML parser is to load the file asynchronously.
Do this:
xml.Async = false;
before you do the .load operation.

0
 
LVL 4

Expert Comment

by:AssafLavie
ID: 6428603
btw, this was pseudo code... don't actually call 'xml.Async...'. Async is a member function of the DOMDocument class...
0
 

Author Comment

by:jmuldrum
ID: 6428826
Thanks for your response. I placed the code before the .load statement but the debugger still shows ptrElement as 0x00000000, so I am not accessing this correctly.
0
 

Author Comment

by:jmuldrum
ID: 6429069
Thanks for your response. I placed the code before the .load statement but the debugger still shows ptrElement as 0x00000000, so I am not accessing this correctly.
0
 
LVL 4

Expert Comment

by:jtwine100697
ID: 6429318
Errr...  DOMDocument::load returns an HRESULT, not a VARIANT_BOOL IIRC.  Very few (well designed) interface methods return anything but an HRESULT.

(Also, VARIANT_BOOL values are supposed to be either "0" or "-1".  Anything else is a mistake on someone's part.)

Getting and looking up the returned HRESULT value should shed some light here.

I assume that there is a working and running web server on your machine?

-=- James.
0
 

Author Comment

by:jmuldrum
ID: 6429372
In response to JTWINE:

According to the msxml.tli file, DOMDocument::load returns a VARIANT_BOOL, but calls DOMDocument::raw_load() which does return an HRESULT.

Where I am currently on this program:

I have replaced the assigment code with
ptrDoc->get_documentElement(&ptrElement);

which does work. As far as I can tell, importing the DLL has given me access to COM functions
HRESULT hr = ptrDoc->get_documentElement(&ptrElement)
and to wrappers for the COM functions
ptrElement = ptrDoc->docucmentElement();

I suppose it makes no real difference which one works as long as one of them does (I am sure they both do and I am just using them wrong), but I am still unable to find any concise documentation on the MSXML dll. Now I am not an expert on MS tools available with Visual Studio (I am learning), so maybe there is a way to rip all necessary information out of the DLL with tools, but I was kind of hoping for a concise description of what is available from the object (all functions and return values) instead of having to stare at 15-20 specialized tutorials to get the nuggets of information that I need.

Thanks again for your help
--j
0
 
LVL 4

Expert Comment

by:jtwine100697
ID: 6429417
> According to the msxml.tli file, DOMDocument::load returns a VARIANT_BOOL,
> but calls DOMDocument::raw_load() which does return an HRESULT.

Interesting... Few Interface methods should return anything else but an HRESULT...

Just as an aside, do you need to use the DOM model, or just need to read/parse the XML file?  The reason I ask is because MS' DOM model is resource hungry, and you may be able to use the SAX2 interface/parser instead...

-=- James.
0
 

Author Comment

by:jmuldrum
ID: 6429433
In response to JTWINE:

According to the msxml.tli file, DOMDocument::load returns a VARIANT_BOOL, but calls DOMDocument::raw_load() which does return an HRESULT.

Where I am currently on this program:

I have replaced the assigment code with
ptrDoc->get_documentElement(&ptrElement);

which does work. As far as I can tell, importing the DLL has given me access to COM functions
HRESULT hr = ptrDoc->get_documentElement(&ptrElement)
and to wrappers for the COM functions
ptrElement = ptrDoc->docucmentElement();

I suppose it makes no real difference which one works as long as one of them does (I am sure they both do and I am just using them wrong), but I am still unable to find any concise documentation on the MSXML dll. Now I am not an expert on MS tools available with Visual Studio (I am learning), so maybe there is a way to rip all necessary information out of the DLL with tools, but I was kind of hoping for a concise description of what is available from the object (all functions and return values) instead of having to stare at 15-20 specialized tutorials to get the nuggets of information that I need.

Thanks again for your help
--j
0
 

Author Comment

by:jmuldrum
ID: 6429442
My apologies for the double posting, I am not sure why it is happening.

I don't need to use the MS DOM, but being rather ignorant of XML parsing tools and slightly familiar with COM programming, I went with the first thing I stumbled across.

--j
0
 
LVL 4

Expert Comment

by:jtwine100697
ID: 6429459
The SAX stuff is still COM: You basically implement a callback interface, and pass it to the SAX engine.  When the SAX engine starts parsing, it calls methods off of the interface, passing you information on the tags it hits.

The biggest downside to SAX is that it does not allow random access to the document: it basically performs a sequential scan, beginning to end.

You will cause double postings if you refresh the page that comes up right after you post a comment/answer.  Instead, use "Reload Question" at the top right of the page.

-=- James.
0
 

Author Comment

by:jmuldrum
ID: 6429468
My apologies for the double posting, I am not sure why it is happening.

I don't need to use the MS DOM, but being rather ignorant of XML parsing tools and slightly familiar with COM programming, I went with the first thing I stumbled across.

--j
0
 

Author Comment

by:jmuldrum
ID: 6429472
Thanks for the info... on both problems :-)


I will investigate SAX

--j
0
 
LVL 4

Expert Comment

by:jtwine100697
ID: 6429654
I used SAX to read a configuration file for a server-side project that I was architecting.  Much easier (and lighter-weight) than the DOM model.

Have fun!

-=- James.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 4

Expert Comment

by:AssafLavie
ID: 6429662
You can do what you want without SAX.
jtwine, the interface wrappers that VC creates for COM objects _always_ convert out,retval's to return values (and translate the HRESULT into a _com_error exception).

jmuldrum, perhaps it will help you to try to do whatever it is your trying to do in VB first and then port the code to VC. I know that's what I do whenever I need to use XML, or ADO or any other VB oriented API. VB is easier by orders of magnitude and you won't fall on stupid error regarding automation types (VARIANT_BOOL for exmaple) and interface pointer manipulation, etc.

Good luck.

p.s.
SAX will also be alot easier to learn using VB.
0
 
LVL 4

Expert Comment

by:jtwine100697
ID: 6429745
> You can do what you want without SAX.

You can also do it without using MSXML entirely, and parse it by hand. :)

Using the DOM, IMHO, is only really useful if you intend to *manipulate* the XML stream; for just reading it, that is like using a shotgun to kill a fly.  

Compare the resouces used by each method.

> jtwine, the interface wrappers that VC creates for COM objects _always_ convert out,
> retval's to return values (and translate the HRESULT into a _com_error exception).

(Such is life when "#import" and VB-capable interfaces.)  If you are referring to my comments about HRESULTS, that does not change the facts that the HRESULT is returned by the *interface method*, not a VARIANT_BOOL, and all well-designed interface methods return HRESULTs.  

Just because a wrapper is being used, which requires an exception frame to be set up in order to work correctly, does not change that fact.

-=- James.
0
 
LVL 4

Expert Comment

by:AssafLavie
ID: 6429778
Well, jtwine, it would seem to me that you should know that interface wrappers are automatically generated by the #import directive and not confuse the OP with comment like:
"Errr...  DOMDocument::load returns an HRESULT, not a VARIANT_BOOL IIRC.  Very few (well designed) interface
methods return anything but an HRESULT"

Besides, turning to SAX just because you can't seem to handle DOM isn't such a bright decision. I think that the DOM is easy enough to manipulate and learn XML with. It's also a good excersize in #importing COM objects into VC.

I still say, do whatever you want to do in VB, then port it. (That goes for SAX too.) It's a lot easier for the uninitiated and it lets the programmer concentrate on the main problem, instead of messing around with tlh/tli's and the other COM related garbage one has to put up with when using VB oriented libraries in VC++.
0
 
LVL 4

Expert Comment

by:jtwine100697
ID: 6429886
> Well, jtwine, it would seem to me that you should know that interface wrappers are automatically generated
> by the #import directive and not confuse the OP with comment like:
> "Errr...  DOMDocument::load returns an HRESULT, not a VARIANT_BOOL IIRC"

The most recent MSDN library and Platform SDK docs confirm that the method returns an HRESULT.  Calling the method directly (not using a wrapper) should confirm, as well.  If the wrapper is incorrectly munging that into a VARIANT_BOOL, then that is not correct.  It should not be, hence my comment was (should be) valid.

> Besides, turning to SAX just because you can't seem to handle DOM isn't such a bright decision.

Well, AssafLavie, re-read my post: I did not say that the OP, nor I, for that matter, could not "handle DOM", I said that the DOM was quite *heavy* (even unnaturally so on larger XML documents).  I even further qualified that by later saying:

   "Compare the resouces used by each method"

Which I would suggest to anyone, using a variety of test data/documents, before choosing a specific solution.  You can also research existing technical documentation, and MSDN magazine has compared the weight and features of both the DOM and SAX which is great (hint) "read before say" material.

> I still say, do whatever you want to do in VB, then port it. (That goes for SAX too.) It's a lot easier
> for the uninitiated and it lets the programmer concentrate on the main problem, instead of messing around
> with tlh/tli's and the other COM related garbage one has to put up with when using VB oriented libraries

To offer a different idea, I would say to not use VB in the first place, and stay away from VB objects as well (which is unavoidable with Microsoft these days): there is nothing more wasteful than to more than double the size of your text data (XML document in this case) in memory (ANSI -> Unicode in BSTRs), and screwing around with VARIANT objects!  (Personal preference/experience talking here: in real projects, performance is king.)

Profiling and seeing how/where SysAllocString/SysFreeString (or other misuses of dynamic allocation) get called is quite educational, which I would suggest, along with the above "read before say" suggestion.  

Also, you can also stay away from typelibraries and #imports, and use the interfaces directly.  That reduces your dependence on something that is compiler-specific, and does not require you to set up exception frames everywhere you might get an error (setting up and tearing down the structure required for exceptions take time).

-=- James.
0
 
LVL 4

Expert Comment

by:AssafLavie
ID: 6429992
".  If the wrapper is incorrectly munging
that into a VARIANT_BOOL, then that is not correct.  It should not be, hence my comment was (should
be) valid."
What are you talking about? It's perfectly valid and indeed usefull. Converting COM's return value policy into rich error info in the form of exception is a GOOD THING. It's not at all unsafe.

"Which I would suggest to anyone, using a variety of test data/documents, before choosing a specific
solution. "
Right. But that doesn't really help the OIP one bit, now does it?
The OP is obviously new to both using COM objects in VC and XML DOM. Trying to learn both at the same time is wasteful. One should learn a master each skill seperately.
That's why he should try using XML in VB first. Once the OP figures out exactly what he wants to do and how he wished to accomplish it, he can try and do the same in VC. The benefit here is the zero overhead in learning time that VB brings.

"there is nothing more wasteful than to more
than double the size of your text data (XML document in this case) in memory (ANSI -> Unicode in BSTRs),
and screwing around with VARIANT objects! "
Again, what are you talking about? Are you impliying that by using the same COM object in VC you get a smaller memroy footprint??
If the XML DOM object model uses variants - then you will have to use them in VC as well. If it doesn't - then VB can handle all the other types just as efficiently. Maybe you're thinking about VBScript...
Points, with VB you have the same amount of overhead (pleade DO profile this and see that 90% of the time is spent inside the DOMDocument - not the VB code), but you have a lot less messy code to write.
Working with bare bones BSTR and interface pointers isn't that smart an idea. It doesn't show you're a better programmer for doing so. On the contrary. These levels of abstraction and encapsulation is what COM and C++ bring to the world of programming. The presence of interface smart pointers causes you're code to be a lot more maintainble, more safe and more exception safe. The presence of BSTR wrappers and variant wrappers prevent you from making groce pointer/memory related errors (which are easy to make with this crappy API).
Why use SysAllocString, when you can use CComBSTR?? It's C++ after all, not C. If you're so crazy about efficiency you should ditch COM all together.


"Also, you can also stay away from typelibraries and #imports, and use the interfaces directly"
Really?? How do you intend to create the tlh/tli files without using the #import directive. Perhaps you're forgetting that there are many switched to this directive that allow you to prevent wrappers from being created.
How do you intend to use standard marshaling without the TLB? Are you saying you have a faster custom marshaller for standard COM interfaces than the universal marshaller? If so, please share.

"That reduces your dependence on something that is compiler-specific"
Not really. It reduces the dependency on C++ as a target language. ARe you saying that everyone's better off sharing headers and libs instead of COM libraries? If so, again, you should ditch COM all together.

"and does not require you to set up exception
frames everywhere you might get an error (setting up and tearing down the structure required for exceptions
take time)."
IMHO, if you're not using exceptions you cannot write large scale robust code. At least not easily. Exception are considered to be acceptable given today's processor speeds even for time critical applications. This consideration, however, is really not relevant when you're talking about your standard COM Windows application (which seems to be what the OP's cooking).
0
 
LVL 4

Expert Comment

by:jtwine100697
ID: 6430080
> What are you talking about? It's perfectly valid and indeed usefull. Converting COM's return value policy
> into rich error info in the form of exception is a GOOD THING. It's not at all unsafe.

Lost sync, I see.  I was talking about the OP's original use of a VARIANT_BOOL instead of an HRESULT.  The V_B only gives you two states of being.  I never said that having the HRESULT wrapped inside the exception object as not value, or not useful.  

> Right. But that doesn't really help the OIP one bit, now does it?

Just because someone is "new" is more of a reason to not have them learn bad habits from the start.  Professional software development is about research.

> The OP is obviously new to both using COM objects in VC and XML DOM.

The OP hinted that (s)he had a bit of COM experience, already.  Using SAX reduces the amount of code that you have to mess with when only doing things like parsing and XML document, and not modifying it.

>> Nothing is more wasteful [...]
>
> Again, what are you talking about? Are you impliying that by using the same COM object in VC you get
> a smaller memroy footprint??

No, I said that I would stay away from "VB-capable" interfaces where possible.

> pleade DO profile this and see that 90% of the
time is spent inside the DOMDocument - not the VB code

As I said: try to stay away from "VB-capable" objects where possible.

> Working with bare bones BSTR and interface pointers isn't that smart an idea. It doesn't show you're
> a better programmer for doing so.

I never said that it did.  It would be quite inappropriate to assume that I did, esp. when what I wrote previously should have been quite clear.

> On the contrary. These levels of abstraction and encapsulation is
>what COM and C++ bring to the world of programming.

I do not consider BSTRs and VARIANTs an idea of encapsulation.  Nor was that part of my comment (focus here).

> The presence of interface smart pointers causes
you're code to be a lot more maintainble, more safe and
> more exception safe.

At what price?  I was commenting on the cost of such things, and besides, when you first am learning about COM, as you mentioned the OP was, do you start with interfaces proper, or jump into wrappers?

> Why use SysAllocString, when you can use CComBSTR??

CComBSTR uses SysAllocString, and I have seen TOO MANY so called "professional developer" misuse CComBSTR objects by using them to build a string by multiple appends to the CComBSTR object.  That demonstrates a lack of understanding on how the CComBSTR object works.  however, IME, if you get used to using SysAllocString directly, you are more likely to build a string in a pre-allocated (likely stack-allocated) buffer somewhere, and THEN make a *single* call to SysAllocString to get your BSTR.

> If you're so crazy about efficiency you should ditch COM all together.

Normally, we did.  We would likely use a custom-designed C/S protocol for out IPC.  Only for client/user-extendable projects did we even consider COM/DCOM.

> > "Also, you can also stay away from typelibraries and #imports, and use the interfaces directly"
>
> Really?? How do you intend to create the tlh/tli files without using the #import directive.

   The idea was to avoid using them via "#import".

> Perhaps you're forgetting that there are many switched to this directive that allow you to prevent wrappers
> from being created.

I think you are referring to "attributes".  And yes, I know what they are (raw_interfaces_only is the one I believe you are referring to).

>How do you intend to use standard marshaling without the TLB?

"You can also stay away from type libraries", referring again to the use of #import.

> Are you saying you have a faster custom marshaller for standard COM interfaces than the universal marshaller?
> If so, please share.

There is a reason you can implement your own IMarshal interface.  And cross-machine marshalling can be improved (or certain projects) by using a replacement protocol that does not include the security-specific information.  There are also certain other reasons that you might want to or have to implement IMarshal yourself.  But if you have to, you might want to re-think your use of COM in that case.

> >"That reduces your dependence on something that is compiler-specific"
>
> Not really. It reduces the dependency on C++ [...]

"Once again the communication process has broken down..."  Actually, if you re-read my post, I was talking about the use of "#import", and it is compiler-specific, not C++ specific.

> IMHO, if you're not using exceptions you cannot write large scale robust code. At least not easily.

Not for some.

> Exception are considered to be acceptable given today's
> processor speeds even for time critical applications.

That depends on your target platform.

Back OT: My first few posts pointed out only two things:
   o The method in question should return an HRESULT, not a VARIANT_BOOL.  An HRESULT gives much better error details, in light of not having an IErrorInfo interface exposed.
   o SAX might be better than the DOM depending on the functionality required, and the resource requirements of the target system.

Carefully note the *absence* of a solicitation for a debate.  Entropy abounds.

Have a nice day.

-=- James.
0
 
LVL 4

Expert Comment

by:AssafLavie
ID: 6431010
"Just because someone is "new" is more of a reason to not have them learn bad habits from the start. "
What bad habit? Learning how to use the best tool for th job?? (Like using VB to learn about DOM without having to manage the VC automation hasle at the same time).

"I do not consider BSTRs and VARIANTs an idea of encapsulation"
I did say they were! I said that the VC wrapper for them are!

", IME, if you get used to using SysAllocString
directly, you are more likely to build a string in a pre-allocated (likely stack-allocated) buffer somewhere,
and THEN make a *single* call to SysAllocString to get your BSTR."
Right.. Tell me, do you also suggest that people ditch them heavey weight std::strings and learn how to use char pointers "Like Real Men!"?

"  The idea was to avoid using them via "#import"."
Ok. Then how will you use them if not by calling #import? Explain.

""You can also stay away from type libraries", referring again to the use of #import."
How?? Explain. Explain to me how you are going to use standard marshalling without the tlb.

"Actually, if you re-read my post, I was talking
about the use of "#import", and it is compiler-specific, not C++ specific."
Well duh. COM isn't standard C++ and it requires extension to your IDE (or compiler). Point is that every IDE that supports COM has the equivalent. So using #import isn't wrong at all. It's just what you do in VC. There's no other way (at least no reasonable way). In Delphi you do it differently, same for VB and BC, etc.

"The method in question should return an HRESULT, not a VARIANT_BOOL.  An HRESULT gives much better
error details, in light of not having an IErrorInfo interface exposed."
Wrong. Exceptions in the style of _com_error offer you the same amount of rich error data. The difference is you don't have to use API's to retrieve it. It's right there in the _com_error object!
Besides, what do you mean by "should return an HRESULT"? Are you saying that the way VC wraps the the interfaces and converts HRESULTs into exceptions is wrong in some way? Is it bad style?? what?
Why do I get the feeling that you simply didn't know/forget about the fact that VC wraps the interface pointer with _com_ptr_t and jump right away shouting about errors in the interface... and now you don't want to admit that.
0
 
LVL 4

Expert Comment

by:AssafLavie
ID: 6431026
>> Exception are considered to be acceptable given today's
>> processor speeds even for time critical applications.
>That depends on your target platform.
AND?? The target platform is obviousely windows. It's obviousely a standard non-real-time application. (I've yet to see kernel mode XML manipulation...). This makes exceptions a viable and reasonable method of error handling. The method of choise for most C++ (not C!) developer.

What basically happened here is that you've gone on and on about efficiency and a bunch of other stuff that's totaly unrelated to the OPs problem and don't help him at all. (Some of it was also plain wrong). You've also attacked everything that C++ has to offer over C. Abstraction and exceptions, for example. Care to explain why?
0
 
LVL 4

Expert Comment

by:jtwine100697
ID: 6431978
>> "IME, if you get used to using SysAllocString
directly, you are more likely to build a string in a pre-
>> allocated (likely stack-allocated) buffer somewhere, and THEN make a *single* call to SysAllocString to get your
>>  BSTR."
>
> Right..

   I know.

> Tell me, do you also suggest that people ditch them heavey weight std::strings and learn how to use char
> pointers "Like Real Men!"?

I am not saying not to use higher level stuff where appropriate, but merely not to *mis*-use them, which, IME, many developers do, because they do not know any better.  Also, please get off this whole "better developer" and "real men" track.  No need to compensate.

>>"The idea was to avoid using them via "#import"."
>
> Ok. Then how will you use them if not by calling #import? Explain.

"Avoid them" referring to the wrappers.  If you require further explaining, it might be best for you to discontinue this, and re-read the last few lines of my last post.

> Well duh. COM isn't standard C++ and it requires extension to your IDE [...]

That is what I said the first time, you missed it then, and it was a "duh" even then.

>> "The method in question should return an HRESULT, not a VARIANT_BOOL.  An HRESULT gives much better
>> error details, in light of not having an IErrorInfo interface exposed."
>
> Wrong. Exceptions in the style of _com_error offer you the same amount of rich error data.

Once again, a simple concept became to complex for some to correctly "grok": My text reads that the method should return an HRESULT because it gives much better error details than the VARIANT_BOOL.  (There is another "duh", just in case it gets missed again this time.)

The _com_error object does accept a pointer to an IErrorInfo interface, but this pointer defaults to NULL, nor does it create one on it's own (it does copy an existing one, however).  Since it really only wraps an HRESULT (its ONLY required parameter in the parameterized constructor), it really only can be guaranteed to expose the information that can be obtained from the HRESULT.  So in reality, it cannot be guaranteed to expose the same rich error information as an IErrorInfo object (which can return customized error messages).

Hence, "An HRESULT gives much better error details [than a VARIANT_BOOL], in light of not having an IErrorInfo interface exposed."  This remains true, and does *not* warrant further discussion.

> Besides, what do you mean by "should return an HRESULT"?

Re-read what I posted previously.  It seems to have been missed that I was referring to the *Interface*, not *wrapper*.  Since re-reading seems to NOT be occurring, here is some help: "Few Interface methods should return anything else but an HRESULT."  (Do you see "wrapper" anywhere in there?)

>Why do I get the feeling that you [...]

Because simple, earlier concepts were misunderstood for some reason.  I did not forget about the #import, and it resulting wrappers: whenever I have had a problem with using anything via #import and its wrappers, I try again using the raw interface to see if different behavior occurs.  

Since I (wrongly) assume that others would have the experience to try these things, misunderstandings often occur.

>>> Exception are considered to be acceptable given today's
>>> processor speeds even for time critical applications.
>>
>>That depends on your target platform.
>
> AND??

Problems understanding?  It was one blanket statement followed by another; no shouting required.  Control yourself.

> What basically happened here is that you've gone on and on about [...blah...]

We both have, in reality.  Hence the statement "Carefully note the *absence* of a solicitation for a debate" should have provided a strong hint.  If not, keep reading it.

[Trying to get OT again, lets hope it is paid attention to this time (although hope is fading FAST!)]

Some simple points remain (and *should not* cause further discussion):
   o Using SAX may be a better choice (faster and lighter, though less featured), depending on your needs (you do not need to use a shotgun to kill a fly)
   o The OP still needs to tell me if (s)he has a web server running on his/her local machine.

-=- James.

0
 
LVL 4

Expert Comment

by:AssafLavie
ID: 6432210
"Since it really only wraps an HRESULT (its ONLY required parameter in the parameterized constructor), it really only can be guaranteed to expose the information that can be obtained from the HRESULT.  So in reality, it cannot
be guaranteed to expose the same rich error information as an IErrorInfo object (which can return customized
error messages)."
That's plain wrong. Whenever an interface implements ISupportErrorInfo the IErrorInfo pointer will be available. Guaranteed.

I see you have brought the art of miss-quoting to new levels... You had a bunch of COM related errors in your comments becuase of the simple fact that you didn't know that VC wraps interface pointers. The OP clearly wrote:
MSXML::IXMLDOMDocumentPt
(notice the suffix) which tells any experienced VC COM guy that he's dealing with wrappers - not interfacces.
Therefor all your remarks about the validity of the XML interface (not returning HRESULT), and your later attempts to cover it up by rambling on about efficiency and the downsides of exception are complete bull and cannot be taken seriously.

The OP asked a simple question about XMLDOM and instead of helping him you decided to discuss interface pointers, COM error handling and SAX. If you don't know how to solve ihs problem, don't waste everybody else's time.
0
 
LVL 4

Expert Comment

by:jtwine100697
ID: 6432325
> That's plain wrong. Whenever an interface implements ISupportErrorInfo the IErrorInfo pointer will be
> available. Guaranteed.

No, as you said: "Whenever an interface implements ISupportErrorInfo [...]", which *cannot* be guaranteed, and you are (or should be) more likely to have an Interface method return an HRESULT, than expose an IErrorInfo, correct?

> You had a bunch of COM related errors [...] didn't know that VC wraps interface pointers. The OP clearly wrote:
> [...] and your later attempts to cover it up [...]

VC only wraps interface pointers (automagically) when using #import.  It does not wrap them unless instructed to do so.  And as said in my last post (which seems to not have been read or understood, let alone re-read):

   I did not forget about the #import, and its resulting wrappers: whenever I have had a problem with using anything via #import and its wrappers, I try again using the raw interface to see if different behavior occurs.

(Note the words: "did not forget about".  Try not to miss them this time...)

Also, there are *documented* scenarios where the #import wrapper methods can cause Access Violation exceptions and memory leaks (look it up BEFORE asking where).  Hence, the behavior I mention above (about trying without the wrappers) is fine.

> [...] complete bull and cannot be taken seriously

Well!  Thank God I did not ask your opinion, or that might have meant something, eh?

> The OP asked a simple question about XMLDOM [...]

The OP said: "I am trying to make use of the MSXML dll to do a couple of things in C++/COM with XML."  

I offered the idea of using SAX, instead of the DOM, if the "couple of things" could be done with it.  Why?  Think about it for a minute (a full 60 seconds).  If still lost: because as you mentioned: "The OP is obviously new to both using COM objects in VC and XML DOM".  So why would a simplier, lighter approach (SAX) be automatically incorrect over a more complex, heavier one (DOM)?  

(Since evidence of confusion continues to exist, note that the last sentence actually solicits a response this time.)

-=- James.
0
 
LVL 4

Expert Comment

by:AssafLavie
ID: 6432372
DOM is not more complex. It may require more resources, but it's ALOT easier to understand and master. All the ASP developers in the world can tell you that. SAX is more complex to learn. It's not as intuitive as DOM and is harder to learn.

"Also, there are *documented* scenarios where the #import wrapper methods can cause Access Violation
exceptions and memory leaks (look it up BEFORE asking where).  Hence, the behavior I mention above (about
trying without the wrappers) is fine."
When you claim something - **you** have to bring the proof. Not the other side! This BS is juvenile...
Now #import is buggy and causes access violations?? So nobody should use it - right?
Also, telling newbies to deal with raw interfaces - expesically VB-oriented-automation-heavey intrefaces is bad advise. It's hard enough to learn hot to pass a variant correctly the first time; same for safe arrays or even managing ref-counting. By using wrappers the programmer can get the job done without learning the gory details of the COM plumbing. It's called abstraction, and you seem to have something against it. I'm not saying that one should always prefer to use the wrappers for the COM types, but beginners should. definately. In fact you really need a good reason not to use them IMO. performance is hardly a consideration in these applications. Buggy code regarding pointers and ref-counting IS a major consideration on the other hand.
So again, i'ts bad advise.
0
 
LVL 4

Accepted Solution

by:
jtwine100697 earned 100 total points
ID: 6432513
> When you claim something - **you** have to bring the proof. Not the other side!

Not when it should be common knowledge in a particular domain!  As "professional" and "expert" developers, I believe we *should* know the benefits and problems of the technologies we use.

> Now #import is buggy and causes access violations?? So nobody should use it - right?

No, you have taken what I wrote and ran with it (*too* far and *without* being told to, I might add).  I am not asking anyone to "read in-between the lines" here.  As such, anyone trying to do so is quickly moving out of their league.  If I think that someone should not use something, then that is what I will say.

> Also, telling newbies to deal with raw interfaces - [...]

That is how most of the people that have been using it long enough to call themselves "experts" have learned it.  And again, I believe that you should know the ins and outs of the technologies you are using.  You should know about IUnknown and reference counting *before* making your first call to CoCreateInstance(...).  If not, you are messing with technologies you do not understand, and that is the fastest way, IME, to cause problems.

> It's hard enough to learn hot to pass a variant correctly the first time; same for safe arrays or even
> managing ref-counting.

For some, maybe.  I would like to believe that other developers out there can understand these concepts without too much difficulty.  I find it better to assume that others are capable, rathern than incapable.  I am sorry if your experience with others has jaded you the other way.

> By using wrappers the programmer can get the job done without learning the gory details of the COM plumbing.
> It's called abstraction, and you seem to have something
against it.

Once again, someone took the ball and ran without permission.  I never said that I had anything aganist abstraction, it is one of the basic tenets of COM (and well-designed C++ code, for that matter): The separation between Interface and Implementation.

> [...] Buggy code regarding pointers and ref-counting IS a major consideration on the other hand.

Which is why I believe that people should learn how to write good code, before relying on a wrapper class to fix their mistakes for them.  But this has nothing to do with the topic at hand.

Note that I never said that my word is to be treated as doctrine: these are my beliefs, based on my experience.  Noone should be treating them as anything other than suggestions (no reading between the lines, remember).  To do so demonstrates a complete lack of understanding about them, and I cannot be responsible for the inabilities of others.

So once again, I ask the OP to respond to my questions (and noone else).

-=- James.
0
 

Author Comment

by:jmuldrum
ID: 6432978
Sorry for the delay, I have been reading with great interest everything that has been posted the last two days. First I would like to say that I am not BRAND NEW to COM. I have developed one or two large applications and have been playing with COM to learn the ins and outs of raw interfaces for some time. I have been reticent to respond as I am self taught and to a large degree am still learning the vocabulary pertinent to this discussion.

I feel that learning the "guts" of COM is essential, not only for this case, but for me to understand the best approach to the problem. As such, I prefer to "reinvent the wheel" in many of these instances in order to learn the technology the correct way. Unfortunately (and this is why I posted a seemingly "newbie" question), I continually run into these problems with MS technology where I simply do not know the right sources to give me the breakdown of what is available through these objects. Developing in a UNIX ennvironment, I have found it much easier to find simple HOW-TO or man page docs that tell me concisely what a given library/interface/techonolgy provide. In this case (COM in general and MSXML specifically) I have only been able to find tutorials that are partial pictures at best. I do develop in VB sometimes (when I don't know the ins and outs of the object nuts and bolts), but I am also not afraid (and am somewhat adept, but not an expert) at IUnknown, IQueryInterface, reference counters, etc. In this case I am in a bit of a crunch and do not have the time to develop in VB then port. The crux of my problem was - something that I felt should work (taken from a tutorial) did not work and sent me to the quickest place for an answer as to why (here at the Exchange).

So as for SAX v MSXML, I am looking into it. I still have reading to do and greatly appreciate the breakdown.

In answer to James questions -
  SAX is an option, but the required functionality is a moving target, so I have to pin some things down and read more on SAX to determine if it is a better tool for the job.

and
   Yes I do have a web server (IIS 5.0 running on Win2k laptop) on my machine for development. But this will be a working application for a company when I am done (don't be afraid of the newbie writing it :-) ... this portion is not mission critical, just have been given some play time to prove C++/COM is a better way to go than the other options).

The current status of the "test bed" I am writing is that it works well(?) through the raw interfaces
hr = <function call>
and I am still not sure why the wrapper bombed.
I am still looking for good documentation on MSXML. I have about 60 pages of tutorial and am limping along in this way - and for what I need to do this is probably enough - but I have run into the crippling problem enough times with COM that I thought I should ask experts what sources they go to when the following is presented...
"After having analyzed the company resources, i.e. programmer skills and availability,  and the problem definition, we have decided C++/COM is the way to go. We know MS has ObjectX (in this case MSXML.dll) now we need to implement..."

Now what?

Again thanks for all of your comments, reading the debate has been instructive, and I am all for that :-)

Cheers
--jeff
0

Featured Post

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Suggested Solutions

  Included as part of the C++ Standard Template Library (STL) is a collection of generic containers. Each of these containers serves a different purpose and has different pros and cons. It is often difficult to decide which container to use and …
IntroductionThis article is the second in a three part article series on the Visual Studio 2008 Debugger.  It provides tips in setting and using breakpoints. If not familiar with this debugger, you can find a basic introduction in the EE article loc…
The viewer will learn how to pass data into a function in C++. This is one step further in using functions. Instead of only printing text onto the console, the function will be able to perform calculations with argumentents given by the user.
The viewer will learn additional member functions of the vector class. Specifically, the capacity and swap member functions will be introduced.

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

15 Experts available now in Live!

Get 1:1 Help Now