Community
Participate
Working Groups
I am trying to do a textual compare of two binary files, but I need to be able to run these files through my own "binary parser" to basically get an ASCII dump of what is in the file. I have found there really is no easy way to do this without a huge pile of code. I posted to the eclipse.platform newsgroup here and didn't find a solution so I am adding this enhancement request: http://www.eclipsezone.com/eclipse/forums/m92177321.html I think it would be relatively easy to provide support for this in the platform. I think the existing binary compare viewer could be extended to get textual representations of a file from contributed binary parsers. This seems like a fairly common thing to do and a good spot for extensibility. Of course, I could be missing something. Is there an easy way to transform a binary file into text on its way to a compare editor and take advantage of the existing TextMergeViewer? I can't see how without declaring my own viewers and essentially re-implementing TextMergeViewer from scratch.
Further investigation shows that the binary file compare viewer does this: protected void handleShowAsText(CompareConfiguration cc) { ICompareAsText comparer = (ICompareAsText)Utilities.getAdapter(cc.getContainer(), ICompareAsText.class); comparer.compareAsText(getInput()); } For a remote CVS revision, for instance, this ultimately ends up in CompareEditorInput#getAdapter() and always returns an instance of org.eclipse.compare.CompareEditorInput$CompareAsText, which then basically flips a property and causes the merge viewer to "tranform" into a TextMergeViewer. Magic. It seems that there is a mechanism sort of in place here that should be easy to plug into, but I can't figure it out. I would be fine with simply overriding the behaviour of this "Compare As Text" button - even if it meant opening a completely new compare editor. But what I can't figure out is how to create my own CompareEditorInputs and have them be used instead of the default org.eclipse.compare.CompareEditorInput. Is there something I can do with adapters here or am I basically out of luck? My next approach is to re-implement the BinaryCompareViewer with my own class and just override the behaviour of that button. This seems like the least amount of code. I'm not afraid of writing code - it is just that there are so many levels of indirection here by the time you get into handling local history items, remote CVS revisions *and* local workspace files that the little nuances kill you. I could be spinning my wheels for weeks.
I think you are going down the wrong path. If I understand you correctly, you have a binary file that you want to provide a compare merge viewer for. It turns out that you want to show the contents of the binary file in a text form. Since the TextMergeViewer already supports the comparison of text, you were hoping to subclass it in order to save yourself some work. The problem is that TextMergeViewer reads the input streams directly and does not allow subclasses to filter the content. If my understanding is corrent, it seem to me that there are two possible solutions: 1) Write your own viewer, which would be a fair bit of work. 2) Try and modify TextMergeViewer so that it allows subclasses to translate the incoming streams into a text form. Given the complexity of TextMergeViewer and it's integration with Text file buffers (i.e. IDocumentManager) this may not be trivial.
Thanks again for the response Michael. I spent the day on this and I have what I think is a workable solution without feeling like a hack. I looked at what was done in the BinaryCompareViewer and basically rolled my own version of that editor. I replaced the "CompareAsText" button with some hyperlinks that allow me view textual diffs at various detail levels. This is accomplished by embedding a CompareViewerSwitchingPane in my viewer, and basically sticking a TextMergeViewer in there. I then feed it input after running the binary file input through binary parsers (and I made this sort of extensible). I think this is a good way to handle it - and it works quite well. You could refuse this ER, but I still think there is room for this in the platform. I think you could extend the existing BinaryCompareViewer to query the input for an implementation of ICompareAsText that was exposed to all users (this is basically what I am doing now with my own made-up interface). I exposed it through a special property on the CompareConfiguration object that is set by the compareViewerCreators themselves. I'd be happy to look at contributing a patch for this if I have the time.
CQ:WIND00166371
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
