Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: It is extremely difficult for developers to customize the look and feel of mulitpage editors because of the design of the MultiPageEditorPart class. The following issues contribute to this difficulty: 1) The container for the MPEP is a CTabFolder, which cannot be extended 2) Methods that access/modify the container all use specific CTabFolder functions 3) Many of the methods that access/modify the container are private and cannot be overwritten in subclasses of MPEP It appears that the designer did intend to allow the user to specify a different container because the getContainer() method returns the more generic type Composite instead of a CTabFolder. However, in this implementation only a CTabFolder will ever be returned. Our solution - In order to work around these constrictions, we created a subclass on MPEP. This subclass defines a new method createContainer() that disposes of the CTabFolder and assigns our own custom tab folder to the container field. Then all private methods that access the tab folder (createItem(), getItem(), disposePart(), etc.) and any public or protected methods that call these methods essentially were copied into our MPEP subclass to ensure the correct container was being used. This results in over 300 lines of essentially duplicate code between the MPEP class and our subclass. Long term solution - In order to make it easier for users to customize the look and feel of the MultiPage editors, the following changes could be made: 1) Allow CTabFolder to be extended, or create an interface for tab folder objects that specify required functionality 2) Allow the user to pass in their own tab folder object to the MPEP constructor to be used as a container for the MPEP This way the user's custom container can be used without having to duplicate the methods the try to access or modify it. More information:
Care to provide a patch as a proof of concept of some of your ideas?
Yes. We're working to pack up the prototype code that we used to re-skin the tabs and attach it to the issue. From there, we will work to produce a patch. Thank you.
Would it then be better for the MPEP to manage the pages and editors in its own datastructure (its model, if you will :-) and simply allow the container class to represent it to the user (storing our datastructures in the CTabFolder isn't exactly MVC) PW
This class is a nightmare for a person that wants to customize container being created (e.g. by changing style bits - see bug 149719). * style bits cannot be changed easily * createContainer is private * container is private * createPartControl is final There's absolutely no way around other than copying most of the implementation code. Couldn't we start by at least making createContainer protected?
(In reply to comment #4) > This class is a nightmare for a person that wants to customize container being > created (e.g. by changing style bits - see bug 149719). That's because the class was written assuming it is in a CTabFolder (even if there's no explicit casts). I'd consider a working enhancement submission, though. PW
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.
