ImageButton Selector XML File not found in Eclipse 3.6.1?

Having some trouble with an ImageButton with a Selector.xml as the drawable source, keep getting the following error when I switch to the Graphical Layout in Eclipse:

Unable to resolve drawable "E:\Programing\Eclipse Workspace\com.commonsware.android.Sandbox\res\drawable-hdpi\keycselector.xml" in attribute "src" Exception details are logged in Window > Show View > Error Log

This is the ImageButton showing the src being set to the keycselector.xml file:

<ImageButton 
  android:layout_width="127px"
  android:layout_height="match_parent" 
  android:id="@+id/BtnC"  
  android:padding="0px" 
  android:src="@drawable/keycselector">
</ImageButton>  

Here's the keycselector.xml file, it's in \res\drawable-hdpi\

<?xml version="1.0" encoding="utf-8"?>
<Selector xmlns:android="http://schemas.android.com/apk/res/android" android:constantSize="true">
    <item android:state_pressed="true" android:drawable="@drawable/keycimagepressed" />
    <item android:state_focused="true" android:drawable="@drawable/keycimagepressed" />
    <item android:drawable="@drawable/keycimage" />
</Selector>

Here's the trace, no idea what this is trying to say "PI must not start with xml (position:unknown @1:7 in java.io.FileReader@172b8dd)":

org.xmlpull.v1.XmlPullParserException: PI must not start with xml (position:unknown @1:7 in java.io.FileReader@172b8dd) at org.kxml2.io.KXmlParser.exception(Unknown Source) at org.kxml2.io.KXmlParser.error(Unknown Source) at org.kxml2.io.KXmlParser.parseLegacy(Unknown Source) at org.kxml2.io.KXmlParser.nextImpl(Unknown Source) at org.kxml2.io.KXmlParser.next(Unknown Source) at com.android.layoutlib.bridge.BridgeXmlBlockParser.next(BridgeXmlBlockParser.java:238) at android.graphics.drawable.Drawable.createFromXml(Drawable.java:721) at com.android.layoutlib.bridge.ResourceHelper.getDrawable(ResourceHelper.java:150) at com.android.layoutlib.bridge.BridgeTypedArray.getDrawable(BridgeTypedArray.java:670) at android.widget.ImageView.(ImageView.java:118) at android.widget.ImageButton.(ImageButton.java:82) at android.widget.ImageButton.(ImageButton.java:78) at sun.reflect.GeneratedConstructorAccessor19.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at android.view.LayoutInflater.createView(LayoutInflater.java:500) at android.view.BridgeInflater.onCreateView(BridgeInflater.java:77) at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:563) at android.view.BridgeInflater.createViewFromTag(BridgeInflater.java:122) at android.view.LayoutInflater.rInflate(LayoutInflater.java:618) at android.view.LayoutInflater.rInflate(LayoutInflater.java:621) at android.view.LayoutInflater.rInflate(LayoutInflater.java:621) at andro开发者_如何学运维id.view.LayoutInflater.inflate(LayoutInflater.java:407) at android.view.LayoutInflater.inflate(LayoutInflater.java:296) at com.android.layoutlib.bridge.Bridge.computeLayout(Bridge.java:397) at com.android.ide.common.rendering.LayoutLibrary.createLegacySession(LayoutLibrary.java:382) at com.android.ide.common.rendering.LayoutLibrary.createSession(LayoutLibrary.java:276) at com.android.ide.eclipse.adt.internal.editors.layout.gle2.GraphicalEditorPart.renderWithBridge(Unknown Source) at com.android.ide.eclipse.adt.internal.editors.layout.gle2.GraphicalEditorPart.renderWithBridge(Unknown Source) at com.android.ide.eclipse.adt.internal.editors.layout.gle2.GraphicalEditorPart.recomputeLayout(Unknown Source) at com.android.ide.eclipse.adt.internal.editors.layout.gle2.GraphicalEditorPart$ReloadListener.reloadLayoutSwt(Unknown Source) at com.android.ide.eclipse.adt.internal.editors.layout.gle2.GraphicalEditorPart$ReloadListener.access$0(Unknown Source) at com.android.ide.eclipse.adt.internal.editors.layout.gle2.GraphicalEditorPart$ReloadListener$1.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407)

---

Try a lowercase s in selector. If that does not help, get rid of the PI line, which looks like:

<?xml version="1.0" encoding="utf-8"?>

It is complaining about that line, though I am not quite certain why.

---

I've beaten my head against this wall a few times and now I have the answer (I hate mysterious behavior, especially when it seems to be random).

I just ran a 4-way test (Unix and DOS, with and without the binary "EF BB BF" BOM header/signature). I found that Eclipse does not put a binary BOM header into XML files it creates, period. If you add a file that has the "<?xml ... ?>" declaration header, it works correctly ONLY if that binary signature is ABSENT. (Whether EOLs are Unix or DOS doesn't matter). If you have both forms of header you get this problem. You can have one, the other, or neither, but never both.

So, if you create a new XML file in Eclipse you can expect (in 3.6 - 3.7.1 anyway) that it has no binary BOM header and you should properly put a "<?xml ... ?>" declaration header in there to identify it as Unicode. If you IMPORT a project that has files with binary BOM header signatures or use an external editor that likes to add them, that's where all this fun begins.

Ideally, ensure XML files with declaration don't have binary BOM header before importing them... otherwise, remove that "<?xml ... ?>" declaration header whenever Eclipse complains... short of removing the binary header that's all you can readily do. (It'd be nice if Eclipse handled this more consistently... or at least gave you a way to identify and fix the problem readily by removing the binary BOM header...)

• If in doubt, examine the file with an external hex editor, preferably one that is NOT Unicode-aware (WinHex worked for me, YMMV). Some text/hex editors will auto-detect Unicode and may auto-add a header when the file didn't really have one.