Community
Participate
Working Groups
in a target editor (or target editing dialog) if you set the window system to Carbon and then save and exit the editor/dialog and go back, the value is still blank. This makes it real hard to develop for carbon while using cocoa. Note that I am using snow leopard but have backported 1.5 and 1.4 JREs installed that should support 32 bit and carbon.
BTW, this is a regression from 3.5.0 I started my 3.5.0 on the same workspace and was able to set the target envrionemnt. Switched back to 3.5.0, set the ws to carbon and it saved fine. Switched to 3.5.1 and the setting was still there but then I set the OS to macosx and saved and it did not stick. I did notice that changing the Environment settings did not seems to cause the editor to be dirty so I changed an env setting AND the name of the target, saved and reopened. That also did NOT persist the env setting. Would be great to consider a fix in for 3.5.2 if it is not risky.
Not reproducible in Windows. Dirty state is updated correctly and the setting is saved correctly.
I just hit this problem this morning. The problem occurs when you select an item from the combo box rather than type in a definition. Both org.eclipse.pde.internal.ui.wizards.target.TargetDefinitionContentPage and org.eclipse.pde.internal.ui.editor.targetdefinition.EnvironmentSection have appropriate listeners for only the Modify case of the combo boxes. They both need similar listeners for the combo box selection cases. Perhaps combo boxes trigger modify on win32? They don't on macosx-cocoa.
Created attachment 150117 [details] Add selection listeners to environment combo boxes
Yes, the combo boxes trigger the listeners in windows. Thanks for the patch, I'll try things out on MacOS this week.
So on I20091020 things work for me on cocoa. I can't reproduce. Kevin, is there something funky with selection listeners that was fixed recently in Cocoa?
Kevin, ping?
bug 285750
This is fixed in 3.5.1 *** This bug has been marked as a duplicate of bug 285750 ***
Thanks Kevin, you guys rock!
This isn't working properly. We aren't getting a selection event, looks like an SWT issue still.
I can confirm that this bug is still there in 3.5.1 on OSX. As someone mentioned, the value persists if the user types it in, but not if it is selected from the drop down menu.
I see the selection event getting sent from Combo. Where is the code that's not receiving it?
In the target editor on the environment tab, first section where you can set the target's OS/WS/etc. The code is in EnvironmentSection in org.eclipse.pde.ui. We create the combos: fOSCombo = new ComboPart(); fOSCombo.createControl(left, toolkit, SWT.SINGLE | SWT.BORDER); fOSCombo.getControl().setLayoutData(new GridData(GridData.FILL_HORIZONTAL)); fOSCombo.setItems((String[]) fOSChoices.toArray(new String[fOSChoices.size()])); fOSCombo.setVisibleItemCount(30); We add a modification listener: fOSCombo.addModifyListener(new ModifyListener() { public void modifyText(ModifyEvent e) { markDirty(); getTarget().setOS(getText(fOSCombo)); } }); Works for me on linux as well as Windows XP.
I found the code. It uses a modify listener instead of a Selection listener. We did not fix modify listeners in 3.5.1 because the changes were too scary. Instead we put a smaller patch into 3.5.1 that only fixed selection events. Can you change TargetDefinitionContentPage to listen for Selection events on the combos? Note that it's fine to leave the moify listener there... it does work if someone types in the combo, it just isn't called when the selection changes.
We can add a selection listener for 3.5.2. So we won't need to change anything to have it work in 3.6?
3.6 worksforme... You could check/set the values when the apply button is clicked so I'm not sure why listeners are necessary at all.
Created attachment 155884 [details] org.eclipse.pde.ui.patch
Created attachment 155885 [details] mylyn/context/zip
done. > 20100112 Thanks for your contribution Brian.
