Re: [platform-debug-dev] Launch configuration dialog question

[Matt_Lavin@xxxxxxx]

After exploring this a little more I realized that I could overide my ConfigurationTabGroup to do exactly what is described as above, if there was some way to get the current tab from the launch configuration dialog.   Bug 15622

Matt_Lavin@xxxxxxx Sent by: platform-debug-dev-admin@xxxxxxxxxxx 05/07/2002 09:14 AM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-debug-dev] Launch configuration dialog question

The difference between regular tab switching and when the user presses 'Apply' or 'Run/Debug' is that when the 'Apply' button is pressed, each tab does not get updated with the current values first.  Calling performApply without calling initializeFrom can destroy some changes.  Maybe, when 'Apply' is pressed the current tab should get a performApply call and every other tab should get an initilizeFrom and then a performApply call.  I think that it would solve my problem and handle the inter-tab communication cases. 


From: Joe_Szurszewski@xxxxxxx 
Date: Mon, 6 May 2002 11:47:02 -0500 
Delivered-to: platform-debug-dev@xxxxxxxxxxx 

Matt, 

The performApply() method is called on every tab switch because this is the only way to handle inter-tab communication, in other words, situations in which an attribute on one tab depends in some way on an attribute on another tab.  Unfortunately, cases like this also require that performApply() be called on all tabs when the 'Apply' or 'Run/Debug' button is clicked, because even though only the attributes on the current page have not been saved, attributes on other (non-visible) pages may depend on an attribute on the visible page, and it's possible the value saved for the other attribute may change based on a new value in the current page.  Attributes whose value depends on the current project are an example of this.   

In general, having two different UI's for the same attribute on two different pages feels risky.  Unfortunately, I can't think of a work-around you could implement right now, other than creating your own version of the arguments tab.   

Joe

Sent by: platform-debug-dev-admin@xxxxxxxxxxx 05/06/2002 11:11 AM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx        cc:                Subject:        [platform-debug-dev] Launch configuration dialog question

I have been trying to create a launch configuration tab that will help the user modify the program arugments for a certian java application.  I would like to incude my tab, along with the java arguments tab so the user can modify the arguments either through my tab or by hand.    My tab provides text entries for certian known arguments on my java application, and when it initializes and applies it values to the configuration it does not remove or modify any arguments that it does not know about.   

I have run into a small problem while attempting this and I am hoping somebody can help.  My problem is that if my tab is shown before the java arguments tab then when the user clicks Ok any changes that the user has made to my tab do not get saved to the configuration.  After some inspection I noticed what is happening.  My tab does write out the changes correctly, but since the java tab is called afterwards, the program arugments are overwritten with whatever was on the arguments page last.  This problem will occur for any tab trying to update the same attribute as another tab. 

When the Ok button is pressed the launch configuration dialog calls performApply on each of the tabs in order.  However, since performApply is called every time the user moves away from a tab it seems like the tabs that are not visible should never need to be called on the Ok press.  If the launch configuration dialog was changed to only call performApply on the current tab then I don't think that anything would change from the tab point of view, but things like two pages modifying the same attribute would work. 

Any comments?