> On 10/21/2010 4:32 PM, Dunne, Donald G wrote: >> Great to meet you and glad you like the Viewer. >> >> 1) The id is meant to be a unique identifier and is used for storing/loading >> the table >> customizations between instances of an application. It also provides for >> the column name to be >> the same, like "Description", but the values shown different. >> >> In these cases, you would want to know the full id of the column (if there >> is one). However, in >> the simplest case, you are correct, it shouldn't show. I made a code fix >> such that if the name >> and id are the same, it doesn't show in the Header or Customization dialog. >> Hope that helps.
Donald, Excellent, thanks! I've integrated the latest and can confirm that is working for us. Also, I've checked out the fix for Bug 328248 (which I reported) and can also confirm that one...thanks! >> 3) We have subclassed the XViewerTextFilter to provide extra capabilities. >> Here's an example. >> You should just be able to implement "select" to do whatever you want. This is where my comment about XViewerTextFilter not being designed to be subclassed came from - everything is private with no getters :( If I want to implement something from scratch, I could do that. If that is the intention, then perhaps there should be an interface for us to implement instead? In our case, we want children that match the filter to be displayed, even when the parents would not pass the filter - which means the parents must be visible if any children are visible. Unless I'm missing something, the default filter doesn't allow that. So rather than starting from scratch, I just want to override select(). But without access to the members (xViewer, textPattern, matcher, and colIdToPattern), that isn't really possible. Well, not without either (a) changing the needed members to protected or (b) copying the update method to update variables I can access (at which point I'm not really inheriting ANY behavior - I'm only subclassing because I have to) For me, making the members protected was enough, but still requires me to update the core nebula source in our tree...which will be a continuing maintenance issue each time XViewer is updated with something we want. I'm just getting started with XViewer and don't know much about the overall problem space, so I won't presume to suggest how you should deal with this, if at all. Thanks again! Chris p.s. I have not yet tried to reproduce problem #2 (disappearing background colors for search hit cells), but I will get to it soon(ish). -- ------------------------------------------------------------------------ - Chris Merrill | Web Performance, Inc. [email protected] | http://webperformance.com 919-433-1762 | 919-845-7601 Web Performance: Website Load Testing Software & Services ------------------------------------------------------------------------ - _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
