| constant name defined in an interface "... is too complicated" [message #113434] |
Fri, 16 December 2005 15:03  |
Eclipse User |
|
|
|
Originally posted by: i.hate.spam
This is a multi-part message in MIME format.
--------------090308030307060003020509
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
I know there are a lot of threads about "Expression ... is too
complicated", but I couldn't find an answer to my specific question.
(btw. the source code for this sample scenario is attached as zip)
First I have a very simple custom bean "MyTextField" which is just a
subclass of JTextField with an additional property named "myProperty".
Second there is an interface "IDemo" with a String constant named
DEMO_PROPERTY.
Now I create a new JPanel "Demo" in VE that implements IDemo. I add an
instance of MyTextField to the panel. In the getMyTextField() method I
add a the following line of code:
myTextField.setMyProperty(DEMO_PROPERTY);
After doing that, VE 1.0.1 shows DEMO_PROPERTY in the property sheet for
myProperty, which is perfect for us. I know, when I enter DEMO_PROPERTY
in the propert sheet, this will be inserted into the source code as
setMyProperty("DEMO_PROPERTY") with quotes around the constant name.
That's not what we want, but we can handle this in a custom property
editor, so that's not a problem.
But VE 1.1.0.1 doesn't show any value for myProperty in the property
sheet, but the "too complicated" warning for the MyTextField bean.
Will this be fixed in a future release of VE, so that it will work again
like in VE 1.0? I don't think I can handle that myself with a custom
property editor. It seems that the java code parser no longer returns
the property value if it cannot successfully parse it.
Thanks
Werner
--------------090308030307060003020509
Content-Type: application/x-zip-compressed;
name="vedemo.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="vedemo.zip"
UEsDBAoAAAAAAPKedjMAAAAAAAAAAAAAAAAMAAAAdmUvYnVnNjk0NjYvUEsD BAoAAAAAAPKe
djMAAAAAAAAAAAAAAAAQAAAAdmUvYnVnNjk0NjYvQ1ZTL1BLAwQKAAAAAADy nnYzAAAAAAAA
AAAAAAAABwAAAHZlL0NWUy9QSwMECgAAAAAAEXKQMwAAAAAAAAAAAAAAAAgA AAB2ZS9kZW1v
L1BLAwQKAAAAAAAJc5AzAAAAAAAAAAAAAAAAEwAAAHZlL2RlbW8vbXlwcm9w ZXJ0eS9QSwME
FAACAAgASHqQMypX0XQ4AQAANwIAABwAAAB2ZS9kZW1vL215cHJvcGVydHkv RGVtby5qYXZh
ZVHBasJAED1H8B8GTwloTHoRDEIP2tKCGGwvPZVtdmrHbjZhdxNNi//ebDaH aC/LMO+9efNm
S5Z9swNCjSHHvAjzplRFico0yXg0HlFeFsrAkdXsHOoTyUP4nDKJokPL6kNQ BplgWsO6lQOe
DUquwZGglQvMURoNTx3+a2VeqahmBmHbvLaCB0LBIR/UK5CVcBZe72HVfmD1 nqerdkE/SGxN
kgwxQT/oGpcrA6gL4jDkuAnmi3So0bzY3t0imkIcL9zADmKc+wc0g/38YNot FSQA8zk8okTV
OvB/lsNMtyOcOX2Cf5XWxe1R7+YQeIKrGcktyebYNmn/a/56s929p/tdutm/ vjn2xT4KTaXk
8Mz9ueDSJYL7Y41LjpmYkeR4XkXLmnTFxCwrpDaKkTSrSRxN42gyHv0BUEsD BBQAAgAIAAt1
kDMlxQHlegAAAI8AAAAdAAAAdmUvZGVtby9teXByb3BlcnR5L0lEZW1vLmph dmErSEzOTkxP
VShL1UtJzc3Xy60sKMovSC0qqbTm5eLlKihNyslMVsjMK0ktSktMTlXwdAGq Uqjm5eKEShWX
JJYAqbTMvMQcheCSosy8dAUXV1//+IAg/wDXoJBIBVsFpZKMzGIFICrJANqU mFOaqpCfhqpK
CWhdLS8XAFBLAwQUAAIACACjc5Az/o33FrAAAABFAQAAIwAAAHZlL2RlbW8v bXlwcm9wZXJ0
eS9NeVRleHRGaWVsZC5qYXZhVY09C8IwFEXnFPof3tguQWdxdRAKguIem0eJ Jm1I0tog/ndT
m37BGx7ce87VrHyxCqFDylE1VHltGo3G+UOapIlQujEOnqxjPbVvUVf0fMPe nQRK/m/o9iFF
CaVk1kLh5xDCgzW3sPThMwBEG9Exh3B1JvhA+cu0CGM+GleuLB9QQmwbetl+ l4dl8l2q0VSh
K2bZxBh0ranXK1u2awQHuyGjjt2ZbDFqFh6OMYmicD9QSwMECgAAAAAA8p52 MwAAAAAAAAAA
AAAAABAAAAB2ZS9wcm9wZXJ0eW5hbWUvUEsDBAoAAAAAAM1wkDMAAAAAAAAA AAAAAAAVAAAA
dmUvcHJvcGVydHluYW1lL2Jhc2UvUEsDBAoAAAAAAPKedjMAAAAAAAAAAAAA AAAZAAAAdmUv
cHJvcGVydHluYW1lL2Jhc2UvQ1ZTL1BLAwQKAAAAAADynnYzAAAAAAAAAAAA AAAAFAAAAHZl
L3Byb3BlcnR5bmFtZS9DVlMvUEsDBAoAAAAAAPKedjMAAAAAAAAAAAAAAAAV AAAAdmUvcHJv
cGVydHluYW1lL2RlbW8vUEsDBAoAAAAAAPKedjMAAAAAAAAAAAAAAAAZAAAA dmUvcHJvcGVy
dHluYW1lL2RlbW8vQ1ZTL1BLAwQKAAAAAAARcpAzAAAAAAAAAAAAAAAAAwAA AHZlL1BLAQIU
AAoAAAAAAPKedjMAAAAAAAAAAAAAAAAMAAAAAAAAAAAAEAD/QQAAAAB2ZS9i dWc2OTQ2Ni9Q
SwECFAAKAAAAAADynnYzAAAAAAAAAAAAAAAAEAAAAAAAAAAAABAA/0EqAAAA dmUvYnVnNjk0
NjYvQ1ZTL1BLAQIUAAoAAAAAAPKedjMAAAAAAAAAAAAAAAAHAAAAAAAAAAAA EAD/QVgAAAB2
ZS9DVlMvUEsBAhQACgAAAAAAEXKQMwAAAAAAAAAAAAAAAAgAAAAAAAAAAAAQ AP9BfQAAAHZl
L2RlbW8vUEsBAhQACgAAAAAACXOQMwAAAAAAAAAAAAAAABMAAAAAAAAAAAAQ AP9BowAAAHZl
L2RlbW8vbXlwcm9wZXJ0eS9QSwECFAAUAAIACABIepAzKlfRdDgBAAA3AgAA HAAAAAAAAAAB
ACAAtoHUAAAAdmUvZGVtby9teXByb3BlcnR5L0RlbW8uamF2YVBLAQIUABQA AgAIAAt1kDMl
xQHlegAAAI8AAAAdAAAAAAAAAAEAIAC2gUYCAAB2ZS9kZW1vL215cHJvcGVy dHkvSURlbW8u
amF2YVBLAQIUABQAAgAIAKNzkDP+jfcWsAAAAEUBAAAjAAAAAAAAAAEAIAC2 gfsCAAB2ZS9k
ZW1vL215cHJvcGVydHkvTXlUZXh0RmllbGQuamF2YVBLAQIUAAoAAAAAAPKe djMAAAAAAAAA
AAAAAAAQAAAAAAAAAAAAEAD/QewDAAB2ZS9wcm9wZXJ0eW5hbWUvUEsBAhQA CgAAAAAAzXCQ
MwAAAAAAAAAAAAAAABUAAAAAAAAAAAAQAP9BGgQAAHZlL3Byb3BlcnR5bmFt ZS9iYXNlL1BL
AQIUAAoAAAAAAPKedjMAAAAAAAAAAAAAAAAZAAAAAAAAAAAAEAD/QU0EAAB2 ZS9wcm9wZXJ0
eW5hbWUvYmFzZS9DVlMvUEsBAhQACgAAAAAA8p52MwAAAAAAAAAAAAAAABQA AAAAAAAAAAAQ
AP9BhAQAAHZlL3Byb3BlcnR5bmFtZS9DVlMvUEsBAhQACgAAAAAA8p52MwAA AAAAAAAAAAAA
ABUAAAAAAAAAAAAQAP9BtgQAAHZlL3Byb3BlcnR5bmFtZS9kZW1vL1BLAQIU AAoAAAAAAPKe
djMAAAAAAAAAAAAAAAAZAAAAAAAAAAAAEAD/QekEAAB2ZS9wcm9wZXJ0eW5h bWUvZGVtby9D
VlMvUEsBAhQACgAAAAAAEXKQMwAAAAAAAAAAAAAAAAMAAAAAAAAAAAAQAP9B IAUAAHZlL1BL
BQYAAAAADwAPAM8DAABBBQAAAAA=
--------------090308030307060003020509--
|
|
|
| Re: constant name defined in an interface "... is too complicated" [message #113448 is a reply to message #113434] |
Fri, 16 December 2005 16:06  |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
In 1.2 we show that actual value of DEMO_PROPERTY, not the word
DEMO_PROPERTY. You could still get too complicated but we've cleaned up
many of these. String constants should work.
Werner Huber wrote:
> Hi,
>
> I know there are a lot of threads about "Expression ... is too
> complicated", but I couldn't find an answer to my specific question.
>
> (btw. the source code for this sample scenario is attached as zip)
>
> First I have a very simple custom bean "MyTextField" which is just a
> subclass of JTextField with an additional property named "myProperty".
>
> Second there is an interface "IDemo" with a String constant named
> DEMO_PROPERTY.
>
> Now I create a new JPanel "Demo" in VE that implements IDemo. I add an
> instance of MyTextField to the panel. In the getMyTextField() method I
> add a the following line of code:
> myTextField.setMyProperty(DEMO_PROPERTY);
>
> After doing that, VE 1.0.1 shows DEMO_PROPERTY in the property sheet for
> myProperty, which is perfect for us. I know, when I enter DEMO_PROPERTY
> in the propert sheet, this will be inserted into the source code as
> setMyProperty("DEMO_PROPERTY") with quotes around the constant name.
> That's not what we want, but we can handle this in a custom property
> editor, so that's not a problem.
>
> But VE 1.1.0.1 doesn't show any value for myProperty in the property
> sheet, but the "too complicated" warning for the MyTextField bean.
>
> Will this be fixed in a future release of VE, so that it will work again
> like in VE 1.0? I don't think I can handle that myself with a custom
> property editor. It seems that the java code parser no longer returns
> the property value if it cannot successfully parse it.
>
> Thanks
> Werner
>
--
Thanks,
Rich Kulp
|
|
|
| Re: constant name defined in an interface "... is too complicated" [message #611637 is a reply to message #113434] |
Fri, 16 December 2005 16:06 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
In 1.2 we show that actual value of DEMO_PROPERTY, not the word
DEMO_PROPERTY. You could still get too complicated but we've cleaned up
many of these. String constants should work.
Werner Huber wrote:
> Hi,
>
> I know there are a lot of threads about "Expression ... is too
> complicated", but I couldn't find an answer to my specific question.
>
> (btw. the source code for this sample scenario is attached as zip)
>
> First I have a very simple custom bean "MyTextField" which is just a
> subclass of JTextField with an additional property named "myProperty".
>
> Second there is an interface "IDemo" with a String constant named
> DEMO_PROPERTY.
>
> Now I create a new JPanel "Demo" in VE that implements IDemo. I add an
> instance of MyTextField to the panel. In the getMyTextField() method I
> add a the following line of code:
> myTextField.setMyProperty(DEMO_PROPERTY);
>
> After doing that, VE 1.0.1 shows DEMO_PROPERTY in the property sheet for
> myProperty, which is perfect for us. I know, when I enter DEMO_PROPERTY
> in the propert sheet, this will be inserted into the source code as
> setMyProperty("DEMO_PROPERTY") with quotes around the constant name.
> That's not what we want, but we can handle this in a custom property
> editor, so that's not a problem.
>
> But VE 1.1.0.1 doesn't show any value for myProperty in the property
> sheet, but the "too complicated" warning for the MyTextField bean.
>
> Will this be fixed in a future release of VE, so that it will work again
> like in VE 1.0? I don't think I can handle that myself with a custom
> property editor. It seems that the java code parser no longer returns
> the property value if it cannot successfully parse it.
>
> Thanks
> Werner
>
--
Thanks,
Rich Kulp
|
|
|
Powered by
FUDForum. Page generated in 0.02553 seconds
] 
Search
Help
Register
Login
Home
