Community
Participate
Working Groups
Execute some validation controls before CtabItem switching. it's only possible saving old page index and restoring the selection, it provokes flickering problems. thanks
More information: i've tried to solve it as i've explained in http://dev.eclipse.org/newslists/news.eclipse.platform/msg65483.html
(In reply to comment #1) > i've tried to solve it as i've explained in > http://dev.eclipse.org/newslists/news.eclipse.platform/msg65483.html Hi Mirko, I guess this is the right link for your message --> http://dev.eclipse.org/newslists/news.eclipse.platform/msg65482.html I looked at your code in the message, but didn't find the implementation of canLeaveThePage() of CTabItemPageManager. What are you trying to do in the canLeaveThePage()?
hi, i wanted only provide a mechanism to customize validation controls before tab switching (maybe index parameters passed to canLeavethePage isn't really useful), consider this example (not tested because my goal was use this mechanisn in FormPage class) i hope following example can help you: public class MyComposite extends Composite implements CTabItemPageManager{ private Button agreeLicenseButton=null; public MyCTabItem(CTabFolder parent, int style) { super(parent, style); } public boolean canLeaveThePage(int index) { if (agreeLicenseButton.getSelection()) return true; return false; } ... ... ... ... } CTabItem my = new CTabItem (); Composite myComposite= new MyComposite(); ... ... my.setPageManager(myComposite); my.setControl(myComposite);
(In reply to comment #3) Thank you for the example, I understood the requirement.
Created attachment 130832 [details] patch with code changes I think it will be better to have a common Page Manager for the CTabFolder, instead of having a separate Page Manager for each tab-item. The old and new index values in the canLeaveThePage method can be used to validate the tab-items before leaving a page with old index or before selecting a page with new index.
Created attachment 130834 [details] patch using Page Manager
Created attachment 130838 [details] example to show how to use the page manager Created an example to show the use of the Page Manager for validation before switching tabs.
There is a bug 193453 for requirement of a CTabFolder Pre-Selection Listener. Though the patch doesn't create a listener, I think it can solve the problem of validation before tab-switching which is common in both the bugs.
Hi Silenio, This bug requests for a PageManager for Ctabfolder to do some validation before tab-switching. There is another bug 193453 requesting for a PreSelection listener to do the same thing (also it has few votes). I think fixing any one of them will fix the problem of validation before tab-switiching. Please suggest which way to go. (I have attached patch for the PageManger approach here. It uses the canLeavepage() similar to FormPage.canLeaveThePage())
CTabItem pre-closure already exists (the doit flag of CTabFolderEvent can be set to false in CTabFolderListener.close()). This is how other events are avoided as well (SWT.Traverse, SWT.KeyDown, SWT.Close, etc). I believe the solution for pre-selection should be similar. I personally do not like the manager class, since it is a new concept that SWT does not have so far. Some options: 1) change the selection event for CTabFolder to run before the item is selected and look at the doit flag. This may break current users. 2) add another general untyped event (SWT.PreSelection or SWT.Selecting). We would have to see if we would add the typed event/listener as well. 3) add yet another CTabFolerListener (CTabFolder3Listener). Do we have any other feature requests that require new events? I would hate to add another listener with only one method.
Re: comment 10 Option 1 is best because it matches current SWT API, but as you say it may break people. Do we have any way of determining whether or not it really does? (Other than releasing the change early in 3.7 and waiting for bugs... ;) Option 2 (untyped) isn't bad, and it could possibly be reused if there are ever any other controls that need to allow selection event cancellation. Option 3 is CTabFolder-specific, so I would first ask whether or not we think any other control would ever need this feature (I don't know, like maybe TabFolder? Or a Button "isn't ready to be selected"? <g> Or a single-line Text field wants to prevent defaultSelection for some reason? (instead of using Verify)). Option 3 is also "the most different" from current SWT API, so I don't like this option.
Hi Carolyn & Silenio, I tried out option1 in my workspace. If we use option1, then - we have to add a new field in Event like Event.oldItem to hold the current selection. Event.item contains the new selection. We can't change this since because existing user code uses this field and expects it to be the newly selected tab item. - we would send the Selection event before the tab-item is selected. Only on selecting the tab, its control is set as visible. When the tab-item is not selected, the control's visibility will be set to false. So, if there is existing user code in the selection event handler that depends on the control's visibility then it may break. For eg, I tried a testcase where calling setFocus() on the item's control in the selection listener doesn't work anymore. I like (option2) where we can have a separate event like SWT.PreSelection for Selections that can be canceled. Users can handle the PreSelection event only when they want to or can cancel the Selection on the control. And the existing user code for SWT.Selection event handler can remain as it is.
Created attachment 160744 [details] patch based on option2 details of the patch based on option2: Added a new event SWT.PreSelection. The event.item will hold the item on which the event occurred, i.e, the item about to be selected. event.index holds the index to this item. User can query for the item which is currently selected by calling CTabFolder.getSelectionIndex() and getSelection() in the listener. I'm not sure if we need to store this index value in the detail field. I'll remove it in case it is not required.
snippet using PreSelection event: public class Test { public static void main(String[] args) { Display display = new Display(); final Shell shell = new Shell(); shell.setLayout(new FillLayout()); final CTabFolder cTabFolder = new CTabFolder(shell, SWT.BORDER); for (int i = 0; i <4; i++) { CTabItem cTabItem = new CTabItem(cTabFolder, SWT.CLOSE, i); cTabItem.setText("item&" + i); Text control = new Text(cTabFolder, SWT.MULTI); cTabItem.setControl(control); control.setText("text for item " + i); } final CTabItem specialItem = cTabFolder.getItem(0); cTabFolder.addListener(SWT.PreSelection, new Listener() { public void handleEvent(Event event) { System.out.println("Preselection event " + event); System.out.println("selection index before selection " + cTabFolder.getSelectionIndex()); System.out.println("item to be selected is " + event.index); if (event.item == specialItem) event.doit = false; } }); cTabFolder.addListener(SWT.Selection, new Listener() { public void handleEvent(Event event) { System.out.println("Selection event " + event); System.out.println("selection index after selection " + cTabFolder.getSelectionIndex()); } }); shell.pack(); shell.open(); while(!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } }
Any update on this?
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
