Sunday, September 18, 2005 1:09 AMI'm opening an XML document in the VS editor; in memory, there's no disk file. Everything is working great, except one thing: When I try to open the document in data grid view (by right-clicking on the window and clicking the "View Data Grid" item), I get the error "Error HRESULT E_FAIL has been returned from a call to a COM component".
Anybody have any idea what I'm doing wrong?
Tuesday, September 20, 2005 6:12 PMIs this happening with all Xml documents or a specific instance?
Can you try something simple like the xml below - and see if the "View dataGrid" command successfully shows one entry in the table?
<title>MSDN: Microsoft XML Developer Center</title>
Tuesday, September 20, 2005 8:31 PMSame error with this document.
Saturday, September 24, 2005 11:51 PMSome additional information:
I didn't realize at first, the message box showing the error is titled "Dataset error". Maybe significant.
Tuesday, October 04, 2005 3:57 PM
In lieu of actually getting it working (difficult at best), is there any way I can disable this command while my in-memory document is being edited?
Monday, October 17, 2005 9:43 PMOK, I have some new information:
Using System Internals' FileMon, I was able to catch VS in the act of looking for a file for my in-memory XML document. For example, if my document's moniker is myscheme://xml/abc, the shell will open the document OK, format it OK, infer a schema OK, etc., but when I try to View.ViewDataGrid it looks for the file $PROJECT_DIR$\myscheme://xml/abc, and (of course) fails.
Is this a bug?
Wednesday, October 19, 2005 8:44 AMYes.
Monday, October 24, 2005 9:09 PMModeratorI've run across this same issue myself. Though in a slightly different context. I was actually hosting the VS core text editor as a child control parented to my own managed editor.
Unfortunately, the XML Editor currently isn't designed to be reused in that particular fashion. In actuality, none of the the VS editors or language services actually support that particular type of reuse. In my case, the underlying XML language service has no knowledge of my own custom editor, and isn't aware that the XML code window is actually hosted as a child control, in my own editor. Consequently, it was attempting to load the underlying text buffer into it's own editor when attempting to process that command.
At one point, I was able to get the Data Grid to display by leveraging a temporary file and implementing IVsProject3 on my custom hierarchy (to intercept the OpenItemWithSpecific method), but then I ran into a nasty problem where the underlying XML language service required a valid DTE.ProjectItem automation object to be implemented on the hierarchy item (via the VSHPROPID_BrowseObject property) that I launched the custom editor on. It was this last problem that made us abandon attempting to support this particular command, and we opted to simply disable/hide the View DataGrid command.
To do that you can implement a command filter (an object implementing IOleCommandTarget) and insert into the command routing chain by calling IVsTextView.AddCommandFilter. Because the XML language service's command filter actually enables this command from it's own command filter, you'll need to handle the ECMD_SHOWCONTEXTMENU command, calling IVsUIShell.ShowContextMenu yourself, and passing your command filter's IOleCommandTarget, so that you can actually intercept the IOleCommandTarget.QueryStatus call where you can then hide the View DataGrid command.
I suspect you'll also run into similar problems when attempting to dbl-click items in the Error List toolwindow. The only way I could get that working was to create and associate the VsTextBuffer with an actual file. Meaning I had to create a valid temporary file, then QI the VsTextBuffer object for IVsUserData, and call IVsUserData.SetData(), with the VsBufferMoniker guid (typeof(IVsUserData).GUID), then register the moniker in the Running Document table, by calling IVsRunningDocumentTable.RegisterAndLockDocument.
All in all, it took a lot of experimentation (trial and error) to make it work. The use of a temporary file was a bit of a hack, but it did fix the navigation problem with the Error List dialog. I suspect that if I had a custom project system that actually implemented that ProjectItem automation interface, I might have actually gotten that View DataGrid command to work as well. But that particular feature is a bit beyond what I could realistically invest in the project.
Ed Dore [MSFT]
Microsoft Developer Support
This post is "AS IS" with no warranties, and confers no rights.