Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 64588

Summary:	(Plat)No notification received when profiling type tree selection change
Product:	z_Archived	Reporter:	Glenn Weidner <gweidner>
Component:	TPTP	Assignee:	amehrega
Status:	CLOSED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows 2000
Whiteboard:	closed460
Bug Depends on:	90754
Bug Blocks:

Description Glenn Weidner

2004-05-28 12:59:37 EDT

Currently there is no way for an IProfilingType implementation to receive 
notification that a selection change has been made in the profiling type tree 
of the Edit Profiling Set dialog.  With this notification a profiling type 
would be allowed to check if the data entered in its UI is valid and 
potentially notify the user before they leave the UI.  In the case of Probekit, 
the notification would allow filter changes to be saved into the 
ProfilingSetsManagerCopy.

The type of notification I would be looking for is something similar to what is 
done for PreferencePage implementations where an okToLeave() method is called 
on the current page when the user changes selection in the Preferences tree.  
An alternate solution would be to provide a way for a profiling type to 
register a listener for selection change events similar to what the 
TraceProfileOverviewUI.EditWizardPage1 does.  Another possibility would be to 
call the existing IProfilingType.validateConfiguration method on the currently 
displayed control in the EditWizardPage1.updateGui() method and if an error 
message is returned, display the error message keeping the currently displayed 
control visible without showing details for the new profiling type's control 
(essentially blocking the selection change).

Comment 1 Curtis d'Entremont

2004-05-28 17:04:29 EDT

Since there is a workaround, post-3.0. This will be one of the things 
considered when the profiling types are being reworked due to design 
deficiencies.

Comment 2 Valentina Popescu

2004-11-16 12:38:30 EST

Cannot be contained by 3.2 i2 since the fix require design work.
Moving defect to 3.3

Comment 3 Valentina Popescu

2004-11-16 21:01:14 EST

Per discussion with Harm, the defect should be discussed in the committers call 
and decided if it can be moved to 3.3.
Moving defect back to 3.2 i2

Comment 4 Valentina Popescu

2004-11-22 14:28:53 EST

Defect discussed in Hyades committers call and approved to move to a higher 
release

Comment 5 Ruth Lee

2005-07-12 10:55:58 EDT

Deferring from 4.1 as per the official 4.1 enhancement plan.
http://eclipse.org/tptp/home/project_info/featureplans/features.php?source=All&project=All&release=4.1&file=TPTPFeatures_4.1.xml

Comment 6 amehrega

2006-01-25 15:09:51 EST

Setting the target to future since it has not officially been planned, but this feature is being considered as part of the JVMTI refactoring.

Comment 7 amehrega

2006-03-31 18:35:30 EST

This was done as part of 93212
Verification can be done when the user modifies analysis type option or when an analysis type selection changes.

See org.eclipse.hyades.trace.ui.analysisTypes extension point.

Comment 8 Paul Slauenwhite

2009-06-30 08:20:07 EDT

As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.