10 Replies Latest reply: Apr 26, 2012 10:46 AM by CSWalt RSS

6.1.4: VALUE attribute hidden in Board property box

when this parameter is set to '1' :

Sch.Cmd.Add.AlwaysUseDeviceNameAsValue = "1"

 

In the Board, the Value attribute is hidden in the info (properties) box and also in the Attribute box.

Is it intended?

 

  • 1. Re: 6.1.4: VALUE attribute hidden in Board property box
    CSWalt Level 9

    On 03/29/12 16:09, Christian Bohrer wrote:

    when this parameter is set to '1' :

    Sch.Cmd.Add.AlwaysUseDeviceNameAsValue = "1"

     

    In the Board, the Value attribute is hidden in the info (properties) box

    and also in the Attribute box.

    Is it intended?

     

    We can reproduce it and are looking into this.

     

    Regards,

    Walter Spermann

     

    --

    -


    Walter Spermann

    Softwareentwicklung

    CadSoft Computer GmbH

    Pleidolfweg 15

    84568 Pleiskirchen

    Tel.: 08635/6989-10

    www.cadsoft.de

    -


    Registergericht: Amtsgericht Traunstein HRB 5573

    Geschäftsführer: Thomas Liratsch

    -


     

  • 2. Re: 6.1.4: VALUE attribute hidden in Board property box

     

    "Walter Spermann" <Walter.Spermann@cadsoft.de> a écrit dans le message de news:

    jl44t8$951$1@cheetah.cadsoft.de...

    On 03/29/12 16:09, Christian Bohrer wrote:

    >> when this parameter is set to '1' :

    >> Sch.Cmd.Add.AlwaysUseDeviceNameAsValue = "1"

    >>

    >> In the Board, the Value attribute is hidden in the info (properties) box

    >> and also in the Attribute box.

    >> Is it intended?

    >>

    We can reproduce it and are looking into this.

     

    Regards,

    Walter Spermann

     

    I discovered that it also happens when the parameter is set to "0"

    Christian Bohrer

     

     

     

  • 3. Re: 6.1.4: VALUE attribute hidden in Board property box
    CSWalt Level 9

    On 03/30/12 13:27, Christian Bohrer wrote:

    "Walter Spermann" <Walter.Spermann@cadsoft.de> a écrit dans le message de news:

    jl44t8$951$1@cheetah.cadsoft.de...

    >> On 03/29/12 16:09, Christian Bohrer wrote:

    >>> when this parameter is set to '1' :

    >>> Sch.Cmd.Add.AlwaysUseDeviceNameAsValue = "1"

    >>>

    >>> In the Board, the Value attribute is hidden in the info (properties) box

    >>> and also in the Attribute box.

    >>> Is it intended?

    >>>

    >> We can reproduce it and are looking into this.

    >>

    >> Regards,

    >> Walter Spermann

     

    I discovered that it also happens when the parameter is set to "0"

    Christian Bohrer

     

     

    Yes it's independent from AlwaysUseDeviceNameAsValue setting.

    We thought over the handling of the attribute VALUE.

    What is it actually useful for ? It's necessary to define devices with their own value.

    Once added, the part gets the device's VALUE attribute as value and also

    the device's attribute VALUE. Now it's confusing:

    1. What if the user changes the attribute VALUE ?

    2. What if the part's value is changed by the value command ?

    One could expect that in case 1 the part value and in case 2 the attribute value

    has to be changed also. But this is actually redundant.

    Once the device is added the attribute VALUE is no longer interesting.

    That's why we want to keep out this attribute for the future

    (both schematic and board). Does this make sense to you ?

     

    Regards,

    Walter Spermann

     

    --

    -


    Walter Spermann

    Softwareentwicklung

    CadSoft Computer GmbH

    Pleidolfweg 15

    84568 Pleiskirchen

    Tel.: 08635/6989-10

    www.cadsoft.de

    -


    Registergericht: Amtsgericht Traunstein HRB 5573

    Geschäftsführer: Thomas Liratsch

    -


     

  • 4. Re: 6.1.4: VALUE attribute hidden in Board property box

    Am 19.04.2012 16:58, schrieb Walter Spermann:

    That's why we want to keep out this attribute for the future

    (both schematic and board). Does this make sense to you ?

     

    If with 'want to keep out' you mean 'forbid to use that', that seems to

    be OK. I would even go further and forbid any attribute called 'NAME' or

    any other of the already implemented EAGLE place holders beginning with

    '>'. If a component contains any of those plus an attribute with

    identical name, things can get VERY confusing (for both the programmer

    AND the user)...

     

    Andreas Weidner

     

     

  • 5. Re: 6.1.4: VALUE attribute hidden in Board property box
    CSWalt Level 9

    On 04/19/12 17:50, Andreas Weidner wrote:

    Am 19.04.2012 16:58, schrieb Walter Spermann:

    >> That's why we want to keep out this attribute for the future

    >> (both schematic and board). Does this make sense to you ?

     

    If with 'want to keep out' you mean 'forbid to use that', that seems to

    be OK.

    I would even go further and forbid any attribute called 'NAME' or

    any other of the already implemented EAGLE place holders beginning with

    '>'.

     

    I fully agree with the only exception VALUE attribute in library editor

    in order to define the value () . The VALUE attribute will handle the

    value to the part during ADD and disappear. Same for change package/technology

    or replace as discussed. We implemented it this way now (for 6.2.1).

     

    If a component contains any of those plus an attribute with

    identical name, things can get VERY confusing (for both the programmer

    AND the user)...

    Yes. It's difficult to make things like that simple again...

     

    Regards,

    Walter Spermann

     

     

    Andreas Weidner

     

     

    --

    -


    Walter Spermann

    Softwareentwicklung

    CadSoft Computer GmbH

    Pleidolfweg 15

    84568 Pleiskirchen

    Tel.: 08635/6989-10

    www.cadsoft.de

    -


    Registergericht: Amtsgericht Traunstein HRB 5573

    Geschäftsführer: Thomas Liratsch

    -


     

  • 6. Re: 6.1.4: VALUE attribute hidden in Board property box

     

    "Walter Spermann" <Walter.Spermann@cadsoft.de> a écrit dans le message de news:

    jmp975$34i$1@cheetah.cadsoft.de...

    On 03/30/12 13:27, Christian Bohrer wrote:

    >> "Walter Spermann" <Walter.Spermann@cadsoft.de> a écrit dans le message de news:

    >> jl44t8$951$1@cheetah.cadsoft.de...

    >>> On 03/29/12 16:09, Christian Bohrer wrote:

    >>>> when this parameter is set to '1' :

    >>>> Sch.Cmd.Add.AlwaysUseDeviceNameAsValue = "1"

    >>>>

    >>>> In the Board, the Value attribute is hidden in the info (properties) box

    >>>> and also in the Attribute box.

    >>>> Is it intended?

    >>>>

    >>> We can reproduce it and are looking into this.

     

    We thought over the handling of the attribute VALUE.

    What is it actually useful for ? It's necessary to define devices with their own value.

     

    You just have to consider the attribute VALUE (if exist) as an alias of the device_name

    If an attribute VALUE exist and if it is not empty, then, it's value is used instead the

    device_name

     

    Once added, the part gets the device's VALUE attribute as value and also

    the device's attribute VALUE. Now it's confusing:

     

    No! It's confusing because we are not talking about the same use

    Two cases to consider:

    1) The user add a generic resistor (without attribute VALUE) in a schematic, the part_value is

    initialized with the device_name: "RESISTOR-0805", the user edit the part_value and replace

    "RESISTOR-0805" by "4k7".

    Now, if the user replace the generic resistor by a 0603 or a 1206, the part_value keeps "4k7" (all

    works as expected).

     

    2) The user add a defined resistor (pre-filled), chosen from thousands in his library, the

    component has many attributes pre filled (PARTNUMBER, REFERENCE, MANUFACTURER, VALUE ...) that

    appear in the BOM.

    The full device_name is: "Resistor-0805-49.9R-0.1%", but as an attribute VALUE exist, the

    part_value is initialized with the attribute VALUE : "49.9R"  (as expected).

    Now, if the user replace the "Resistor-0805-49.9R-0.1%" by a "Resistor-0603-2K2-1%", all attributes

    are updated but the part_value is not updated with the new value "2K2", the part_value keeps "4k7"

    (iznogood) :o(

     

    Attached a library to see the problem. Thanks in advance to play with it.

     

    1. What if the user changes the attribute VALUE ?

     

    The same as for others attributes: the part value will be updated by the attribute VALUE at the

    next "update from library"

    Maybe with a warning before to update.

     

    2. What if the part's value is changed by the value command ?

     

    The same rules apply regardless of the origin of content: device_name or attribute VALUE

    Else, why initialise a VALUE attribute in a device whose value should be changed later with the

    value command ??

     

    One could expect that in case 1 the part value and in case 2 the attribute value

    has to be changed also. But this is actually redundant.

    Once the device is added the attribute VALUE is no longer interesting.

     

    At the contrary, the attribute VALUE is very interesting for the replacement of parts.

    If you don't want to replace the part_value with the device_name because you find it too ugly,

    If you don't want to edit and modifiy manually the part_value each time you replace a part because

    you find it fastidious,

    If you are afraid to forget to change manually the part_value after a replace, then, you will find

    very interesting to use the attribute VALUE instead the device_name.

     

    That's why we want to keep out this attribute for the future

    (both schematic and board). Does this make sense to you ?

     

    Regards,

    Walter Spermann

     

     

    begin 666 Resistors.lbr

    M/#]X;6P@=F5R<VEO;CTB,2XP(B!E;F-O9&EN9STB=71F+3@B/SX*/"%$3T-4

    M65!%(&5A9VQE(%-94U1%32 B96%G;&4N9'1D(CX*/&5A9VQE('9E<G-I;VX]

    M(C8N,B("CQD<F%W:6YG/@H\<V5T=&EN9W,"CQS971T:6YG(&%L=V%Y65R/2(R-R(O/@H\=VER

    M92!X,3TB,"XU(B!Y,3TB3 N,C4B('@R/2(M,"XU(B!Y,CTB3 N,C4B('=I

    M9'1H/2(P(B!L87EE<CTB,C<BSX*/'=I<F4@>#$](BTPC4B('DQ/2(M,"XR

    M-2(@>#(](BTPC4B('DR/2(PC(U(B!W:61T:#TB,"(@;&%Y97(](C(W(B\^

    M"CQS;60@;F%M93TB,2(@>#TB+3 N-2(@>3TB,"(@9'@](C N-2(@9'D](C N

    M-2(@;&%Y97(](C$BSX*/'-M9"!N86UE/2(R(B!X/2(PC4B('D](C B(&1X

    M/2(PC4B(&1Y/2(PC4B(&QA>65R/2(Q(B\^"CQT97AT('@](BTP+C0U(B!Y

    M/2(M,"XR(B!S:7IE/2(P+C0B(&QA>65R/2(R-R(@<F%T:6\](C B/B9G=#M6

    M04Q513PO=&5X=#X*/')E8W1A;F=L92!X,3TB3 N-2(@>3$](BTPC(U(B!X

    M,CTB,"XU(B!Y,CTB,"XR-2(@;&%Y97(](C,Y(B\^"CQT97AT('@](BTP+C0U

    M(B!Y/2(M,"XR(B!S:7IE/2(P+C0B(&QA>65R/2(R-2(@<F%T:6\](C$T(CXF

    M9W0[3D%-13PO=&5X=#X*/"]P86-K86=E/@H\<&%C:V%G92!N86UE/2)2,#8P

    M,R(^"CQD97-C<FEP=&EO;CXF;'0[0B9G=#LP-C S)FQT.R]")F=T.SPO9&5S

    M8W)I<'1I;VX^"CQW:7)E('@Q/2(M,"XX(B!Y,3TB,"XT(B!X,CTB,"XX(B!Y

    M,CTB,"XT(B!W:61T:#TB,"(@;&%Y97(](C(W(B\^"CQW:7)E('@Q/2(P+C@B

    M('DQ/2(PC0B('@R/2(PC@B('DR/2(M,"XT(B!W:61T:#TB,"(@;&%Y97(]

    M(C(W(B\^"CQW:7)E('@Q/2(PC@B('DQ/2(M,"XT(B!X,CTB3 N."(@>3(]

    M(BTPC0B('=I9'1H/2(P(B!L87EE<CTB,C<BSX*/'=I<F4@>#$](BTP+C@B

    M('DQ/2(M,"XT(B!X,CTB+3 N."(@>3(](C N-"(@=VED=&@](C B(&QA>65R

    M/2(R-R(O/@H\<VUD(&YA;64](C$B('@](BTP+C<V,B(@>3TB,"(@9'@](C N

    M.3$T-"(@9'D](C N.38U,B(@;&%Y97(](C$B+SX*/'-M9"!N86UE/2(R(B!X

    M/2(P+C<V,B(@>3TB,"(@9'@](C N.3$T-"(@9'D](C N.38U,B(@;&%Y97(]

    M(C$BSX*/'1E>'0@>#TB3 N-R(@>3TB+3 N,R(@<VEZ93TB,"XV(B!L87EE

    M<CTB,C<B(')A=&EO/2(P(CXF9W0[5D%,544\+W1E>'0^"CQR96-T86YG;&4@

    M>#$](BTP+C@B('DQ/2(M,"XT(B!X,CTB,"XX(B!Y,CTB,"XT(B!L87EE<CTB

    M,SDBSX*/'1E>'0@>#TB3 N-R(@>3TB+3 N,R(@<VEZ93TB,"XV(B!L87EE

    M<CTB,C4B/B9G=#M.04U%/"]T97AT/@H\+W!A8VMA9V4^"CQP86-K86=E(&YA

    M;64](E(P.# U(CX*/&1E<V-R:7!T:6]N/B9L=#M")F=T.S X,#4F;'0[+T(F

    M9W0[/"]D97-C<FEP=&EO;CX*/'=I<F4@>#$](BTQ(B!Y,3TB,"XV(B!X,CTB

    M,2(@>3(](C N-B(@=VED=&@](C B(&QA>65R/2(R-R(O/@H\=VER92!X,3TB

    M,2(@>3$](C N-B(@>#(](C$B('DR/2(M,"XV(B!W:61T:#TB,"(@;&%Y97(]

    M(C(W(B\^"CQW:7)E('@Q/2(Q(B!Y,3TB3 N-B(@>#(](BTQ(B!Y,CTB3 N

    M-B(@=VED=&@](C B(&QA>65R/2(R-R(O/@H\=VER92!X,3TB+3$B('DQ/2(M

    M,"XV(B!X,CTB3$B('DR/2(PC8B('=I9'1H/2(P(B!L87EE<CTB,C<B+SX*

    M/'-M9"!N86UE/2(Q(B!X/2(M,2XP,38B('D](C B(&1X/2(Q+C Q-B(@9'D]

    M(C$N,SDW(B!L87EE<CTB,2(O/@H\<VUD(&YA;64](C(B('@](C$N,#$V(B!Y

    M/2(P(B!D>#TB,2XP,38B(&1Y/2(QC,Y-R(@;&%Y97(](C$BSX*/'1E>'0@

    M>#TB3 N.2(@>3TB3 N-"(@<VEZ93TB,"XX(B!L87EE<CTB,C4B(')A=&EO

    M/2(Q-"(^)F=T.TY!344\+W1E>'0^"CQT97AT('@](BTPCDB('D](BTPC0B

    M('-I>F4](C N."(@;&%Y97(](C(W(B!R871I;STB,"(^)F=T.U9!3%5%/"]T

    M97AT/@H\<F5C=&%N9VQE('@Q/2(M,2(@>3$](BTP+C8B('@R/2(Q(B!Y,CTB

    M,"XV(B!L87EE<CTB,SDBSX*/"]P86-K86=E/@H\W!A8VMA9V5S/@H\<WEM

    M8F]L<SX*/'-Y;6)O;"!N86UE/2)215,B/@H\=VER92!X,3TB+3$N,#$V(B!Y

    M,3TB3,N,3<U(B!X,CTB3$N,#$V(B!Y,CTB,RXQ-S4B('=I9'1H/2(P+C(P

    M,S(B(&QA>65R/2(Y-"(O/@H\=VER92!X,3TB+3$N,#$V(B!Y,3TB,RXQ-S4B

    M('@R/2(P(B!Y,CTB,RXQ-S4B('=I9'1H/2(P+C(P,S(B(&QA>65R/2(Y-"(O

    M/@H\=VER92!X,3TB,"(@>3$](C,N,3'0^"CQT97AT('@](C$N.3 U(B!Y/2(P(B!S:7IE

    M/2(QC4R-"(@;&%Y97(](CDV(CXF9W0[5D%,544\W1E>'0^"CQT97AT('@]

    M(C$N.3 U(B!Y/2(M,RXX,2(@<VEZ93TB,2XU,C0B(&QA>65R/2(Y."(^)F=T

    M.U!!0TL\+W1E>'0^"CQP:6X@;F%M93TB,2(@>#TB,"(@>3TB+34N,#@B('9I

    M<VEB;&4](F]F9B(@;&5N9W1H/2)P;VEN="(@9&ER96-T:6]N/2)P87,B('-W

    M87!L979E;#TB,2(@<F]T/2)2.3 B+SX*/'!I;B!N86UE/2(R(B!X/2(P(B!Y

    M/2(U+C X(B!V:7-I8FQE/2)O9F8B(&QE;F=T:#TB<&]I;G0B(&1I<F5C=&EO

    M;CTB<&%S(B!S=V%P;&5V96P](C$B(')O=#TB4C(W,"(O/@H\=&5X="!X/2(Q

    MCDP-2(@>3TB3$N.3 U(B!S:7IE/2(Q+C4R-"(@;&%Y97(](CDW(CXF9W0[

    M5$],/"]T97AT/@H\+W-Y;6)O;#X/"]S>6UB;VQS/@H\9&5V:6-E<V5T<SX

    M/&1E=FEC97-E="!N86UE/2)215,_(B!P<F5F:7@](E(B/@H\9&5S8W)I<'1I

    M;VX^4F5S:7-T;W(\+V1E<V-R:7!T:6]N/@H\9V%T97,^"CQG871E(&YA;64]

    M(D<D,2(@<WEM8F]L/2)215,B('@](C B('D](C B+SX/"]G871E<SX/&1E

    M=FEC97,^"CQD979I8V4@;F%M93TB+3 T,#(B('!A8VMA9V4](E(P-# R(CX*

    M/&-O;FYE8W1S/@H\8V]N;F5C="!G871E/2)')#$B('!I;CTB,2(@<&%D/2(Q

    M(B\^"CQC;VYN96-T(&=A=&4](D<D,2(@<&EN/2(R(B!P860](C(B+SX*/"]C

    M;VYN96-T<SX/'1E8VAN;VQO9VEE<SX/'1E8VAN;VQO9WD@;F%M93TB(CX*

    M/&%T=')I8G5T92!N86UE/2)#3T1%(B!V86QU93TB(B!C;VYS=&%N=#TB;F\B

    MSX*/&%T=')I8G5T92!N86UE/2)004-(B!V86QU93TB,#0P,B(O/@H\871T

    M<FEB=71E(&YA;64](E1/3"(@=F%L=64](B(@8V]N<W1A;G0](FYO(B\^"CQA

    M='1R:6)U=&4@;F%M93TB5D%,544B('9A;'5E/2(B(&-O;G-T86YT/2)N;R(O

    M/@H\+W1E8VAN;VQO9WD"CQT96-H;F]L;V=Y(&YA;64](BTQ2RTU)2("CQA

    M='1R:6)U=&4@;F%M93TB0T]$12(@=F%L=64](C$P,# R(B\^"CQA='1R:6)U

    M=&4@;F%M93TB4$%#2R(@=F%L=64](C T,#(B+SX*/&%T=')I8G5T92!N86UE

    M/2)43TPB('9A;'5E/2(U)2(O/@H\871T<FEB=71E(&YA;64](E9!3%5%(B!V

    M86QU93TB,4LB(&-O;G-T86YT/2)N;R(O/@H\+W1E8VAN;VQO9WD^"CQT96-H

    M;F]L;V=Y(&YA;64](BTR,E(M,24B/@H\871T<FEB=71E(&YA;64](D-/1$4B

    M('9A;'5E/2(Q,# P-"(O/@H\871T<FEB=71E(&YA;64](E!!0TLB('9A;'5E

    M/2(P-# R(B\^"CQA='1R:6)U=&4@;F%M93TB5$],(B!V86QU93TB,24B+SX*

    M/&%T=')I8G5T92!N86UE/2)604Q512(@=F%L=64](C(R4B(@8V]N<W1A;G0]

    M(FYO(B\^"CPO=&5C:&YO;&]G>3X*/'1E8VAN;VQO9WD@;F%M93TB+3,N,TLM

    M-24B/@H\871T<FEB=71E(&YA;64](D-/1$4B('9A;'5E/2(Q,# P,2(O/@H\

    M871T<FEB=71E(&YA;64](E!!0TLB('9A;'5E/2(P-# R(B\^"CQA='1R:6)U

    M=&4@;F%M93TB5$],(B!V86QU93TB-24B+SX*/&%T=')I8G5T92!N86UE/2)6

    M04Q512(@=F%L=64](C,N,TLB(&-O;G-T86YT/2)N;R(O/@H\+W1E8VAN;VQO

    M9WD^"CQT96-H;F]L;V=Y(&YA;64](BTT.2XY4BTP+C$E(CX*/&%T=')I8G5T

    M92!N86UE/2)#3T1%(B!V86QU93TB,3 P,#,B+SX*/&%T=')I8G5T92!N86UE

    M/2)004-+(B!V86QU93TB,#0P,B(O/@H\871T<FEB=71E(&YA;64](E1/3"(@

    M=F%L=64](C N,24B+SX*/&%T=')I8G5T92!N86UE/2)604Q512(@=F%L=64]

    M(C0YCE2(B!C;VYS=&%N=#TB;F\BSX*/"]T96-H;F]L;V=Y/@H\+W1E8VAN

    M;VQO9VEE<SX*/"]D979I8V4^"CQD979I8V4@;F%M93TB+3 V,#,B('!A8VMA

    M9V4](E(P-C S(CX*/&-O;FYE8W1S/@H\8V]N;F5C="!G871E/2)')#$B('!I

    M;CTB,2(@<&%D/2(Q(B\^"CQC;VYN96-T(&=A=&4](D<D,2(@<&EN/2(R(B!P

    M860](C(B+SX/"]C;VYN96-T<SX/'1E8VAN;VQO9VEE<SX*/'1E8VAN;VQO

    M9WD@;F%M93TB(CX*/&%T=')I8G5T92!N86UE/2)#3T1%(B!V86QU93TB(B!C

    M;VYS=&%N=#TB;F\BSX*/&%T=')I8G5T92!N86UE/2)004-(B!V86QU93TB

    M,#8P,R(O/@H\871T2!N86UE/2(M,C)2+3$E(CX*/&%T=')I8G5T92!N86UE/2)#3T1%(B!V

    M86QU93TB,3$P,#0BSX*/&%T=')I8G5T92!N86UE/2)004-(B!V86QU93TB

    M,#8P,R(O/@H\871T<FEB=71E(&YA;64](E1/3"(@=F%L=64](C$E(B\^"CQA

    M='1R:6)U=&4@;F%M93TB5D%,544B('9A;'5E/2(R,E(B+SX*/"]T96-H;F]L

    M;V=Y/@H\=&5C:&YO;&]G>2!N86UE/2(M,RXS2RTU)2(^"CQA='1R:6)U=&4@

    M;F%M93TB0T]$12(@=F%L=64](C$Q,# Q(B\^"CQA='1R:6)U=&4@;F%M93TB

    M4$%#2R(@=F%L=64](C V,#,B+SX*/&%T=')I8G5T92!N86UE/2)43TPB('9A

    M;'5E/2(U)2(O/@H\871T<FEB=71E(&YA;64](E9!3%5%(B!V86QU93TB,RXS

    M2R(O/@H\+W1E8VAN;VQO9WD^"CQT96-H;F]L;V=Y(&YA;64](BTT.2XY4BTP

    MC$E(CX*/&%T=')I8G5T92!N86UE/2)#3T1%(B!V86QU93TB,3$P,#,BSX*

    M/&%T=')I8G5T92!N86UE/2)004-+(B!V86QU93TB,#8P,R(O/@H\871T3X*/"]T96-H

    M;F]L;V=I97,^"CPO9&5V:6-E/@H\9&5V:6-E(&YA;64](BTP.# U(B!P86-K

    M86=E/2)2,#@P-2(^"CQC;VYN96-T<SX*/&-O;FYE8W0@9V%T93TB1R0Q(B!P

    M:6X](C$B('!A9#TB,2(O/@H\8V]N;F5C="!G871E/2)')#$B('!I;CTB,B(@

    M<&%D/2(R(B\^"CPO8V]N;F5C=',"CQT96-H;F]L;V=I97,"CQT96-H;F]L

    M;V=Y(&YA;64](B(^"CQA='1R:6)U=&4@;F%M93TB0T]$12(@=F%L=64](B(@

    M8V]N<W1A;G0](FYO(B\^"CQA='1R:6)U=&4@;F%M93TB4$%#2R(@=F%L=64]

    M(C X,#4B+SX*/&%T=')I8G5T92!N86UE/2)43TPB('9A;'5E/2(B(&-O;G-T

    M86YT/2)N;R(O/@H\871T<FEB=71E(&YA;64](E9!3%5%(B!V86QU93TB(B!C

    M;VYS=&%N=#TB;F\B+SX*/"]T96-H;F]L;V=Y/@H\=&5C:&YO;&]G>2!N86UE

    M/2(M,4LM-24B/@H\871T<FEB=71E(&YA;64](D-/1$4B('9A;'5E/2(Q,C P

    M,B(O/@H\871T<FEB=71E(&YA;64](E!!0TLB('9A;'5E/2(P.# U(B\^"CQA

    M='1R:6)U=&4@;F%M93TB5$],(B!V86QU93TB-24B+SX*/&%T=')I8G5T92!N

    M86UE/2)604Q512(@=F%L=64](C%+(B\^"CPO=&5C:&YO;&]G>3X*/'1E8VAN

    M;VQO9WD@;F%M93TB+3(R4BTQ)2(^"CQA='1R:6)U=&4@;F%M93TB0T]$12(@

    M=F%L=64](C$R,# T(B\^"CQA='1R:6)U=&4@;F%M93TB4$%#2R(@=F%L=64]

    M(C X,#4B+SX*/&%T=')I8G5T92!N86UE/2)43TPB('9A;'5E/2(Q)2(O/@H\

    M871T<FEB=71E(&YA;64](E9!3%5%(B!V86QU93TB,C)2(B\^"CPO=&5C:&YO

    M;&]G>3X*/'1E8VAN;VQO9WD@;F%M93TB+3,N,TLM-24B/@H\871T<FEB=71E

    M(&YA;64](D-/1$4B('9A;'5E/2(Q,C P,2(O/@H\871T<FEB=71E(&YA;64]

    M(E!!0TLB('9A;'5E/2(P.# U(B\^"CQA='1R:6)U=&4@;F%M93TB5$],(B!V

    M86QU93TB-24B+SX*/&%T=')I8G5T92!N86UE/2)604Q512(@=F%L=64](C,N

    M,TLB+SX*/"]T96-H;F]L;V=Y/@H\=&5C:&YO;&]G>2!N86UE/2(M-#DN.5(M

    M,"XQ)2("CQA='1R:6)U=&4@;F%M93TB0T]$12(@=F%L=64](C$R,# S(B\

    M"CQA='1R:6)U=&4@;F%M93TB4$%#2R(@=F%L=64](C X,#4B+SX*/&%T=')I

    M8G5T92!N86UE/2)43TPB('9A;'5E/2(P+C$E(B\^"CQA='1R:6)U=&4@;F%M

    M93TB5D%,544B('9A;'5E/2(T.2XY4B(O/@H\+W1E8VAN;VQO9WD^"CPO=&5C

    M:&YO;&]G:65S/@H\+V1E=FEC93X/"]D979I8V5S/@H\+V1E=FEC97-E=#X

    M/"]D979I8V5S971S/@H\+VQI8G)A<GD^"CPO9')A=VEN9SX/"]E86=L93X

    `

    end

     

     

  • 7. Re: 6.1.4: VALUE attribute hidden in Board property box

    Am 25.04.2012 13:03, schrieb Christian Bohrer:

    >> Once added, the part gets the device's VALUE attribute as value and also

    >> the device's attribute VALUE. Now it's confusing:

     

    I'm a bit unfair now, but I still mean it: The whole 'that is confusing'

    story is due to CadSoft's improper use of the English and/or German

    language: In the schematics/board, every part/element should have a

    decent VALUE. In the library, NOBODY needs a value. Not EVER! Therefore,

    having a VERY USEFUL attribute in a library and call it VALUE is prone

    to misunderstandings. The library's VALUE attribute does NOT have the

    same meaning as the VALUE in schematics or board, so it should NOT have

    the same name. ALL misunderstandings would vanish if the library's

    attribute would be called DEFAULTVALUE.

     

    EVERYBODY will then IMMEDIATELY understand the function of this

    attribute, because it has a DESCRIPTIVE name, which can NOT be mixed up

    with VALUE.

     

    Proposal:

      1. Rename the VALUE attribute in libraries DEFAULTVALUE.

      2. Do NOT allow the creation of any attribute that is called

         VALUE or NAME in libraries any more.

      3. For backwards compatibility (there might be libraries that

         already make use of VALUE), on the opening of a library,

         immediately convert VALUE to DEFAULTVALUE.

     

    CadSoft: Please consider thinking as a user would, and NOT a programmer

    (yes, I know that I keep repeating myself). For a programmer, it is

    perhaps a good idea to call two different functions by the same name

    (saves six string bytes), but from a user perspective, that's a very BAD

    idea (and yes, it CAN become quite confusing). Your idea for the above

    FUNCTIONALITY was a REALLY good one - it just lacks a) a descriptive

    name and b) support from the GUI. Renaming the thing at least clears up a).

     

    Andreas Weidner

     

  • 8. Re: 6.1.4: VALUE attribute hidden in Board   property box

    Andreas Weidner wrote on Wed, 25 April 2012 08:49

    Am 25.04.2012 13:03, schrieb Christian Bohrer:

    >> Once added, the part gets the device's VALUE attribute as value and

    also

    >> the device's attribute VALUE. Now it's confusing:

     

    I'm a bit unfair now, but I still mean it: The whole 'that is

    confusing'

    story is due to CadSoft's improper use of the English and/or German

    language: In the schematics/board, every part/element should have a

    decent VALUE. In the library, NOBODY needs a value. Not EVER!

    Therefore,

    having a VERY USEFUL attribute in a library and call it VALUE is prone

     

    to misunderstandings. The library's VALUE attribute does NOT have the

    same meaning as the VALUE in schematics or board, so it should NOT have

     

    the same name. ALL misunderstandings would vanish if the library's

    attribute would be called DEFAULTVALUE.

     

    EVERYBODY will then IMMEDIATELY understand the function of this

    attribute, because it has a DESCRIPTIVE name, which can NOT be mixed up

     

    with VALUE.

     

    Proposal:

      1. Rename the VALUE attribute in libraries DEFAULTVALUE.

      2. Do NOT allow the creation of any attribute that is called

         VALUE or NAME in libraries any more.

      3. For backwards compatibility (there might be libraries that

         already make use of VALUE), on the opening of a library,

         immediately convert VALUE to DEFAULTVALUE.

     

     

    I agree with this Andreas.  That would be a good start.

     

    I'm not sure this completely addresses my needs.  I have a default value in

    the library for every device.  Let's talk resistors since it is easy to

    see:  I have a R_ device with technology "10K-1%" and package -0402 and

    this combo has a default value of "10K".  Another technology of "33R-1%"

    has a value of "33R".

     

    So I plop down a 10K resistor and then I change the value to "10K DNP" (our

    way of not populating the device).  So when I do a library update I don't

    want that value to change.  However, if I change technology or replace with

    another device then I DO want the value to change to the default value in

    the library--currently this is what doesn't happen.

     

    This needs to be changed too and I think it might be addressed by what

    Walter posted earlier.  But I want to make sure.

     

    And please, if you're changing the update algorithm then please, please,

    please come up with an error/warning/log/status/report of devices that are

    in the design but not found in the libraries!  That is a huge whole in the

    current scheme.  If I make a change to a library and then "update all" I

    have no idea if the change I just made actually made it into the design

    without going to explore the exact details.  Not having the library in the

    correct location is the prime reason this could happen.  At the very least

    create a report stating which devices were updated and from what libraries,

    even better would indicate the differences.

     

    The next higher step would be to create a list of changes that will occur

    like Altium does and then allow the user to select which to apply.

     

    I've had to use Altium for a few projects with a particular customer and I

    must say that there are some really nice features that save huge amounts of

    time.  There are others that I think EAGLE gets it done better but a few

    additions to EAGLE would make a big difference in closing the gap.

     

    Quote:

    CadSoft: Please consider thinking as a user would, and NOT a programmer

     

     

    Always good advice!

     

    James.

     

    --

    James Morrison  ~~~  Stratford Digital

     

    Specializing in CadSoft EAGLE

    • Online Sales to North America

    • Electronic Design Services

    • EAGLE Enterprise Toolkit

    --

    Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

     

  • 9. Re: 6.1.4: VALUE attribute hidden in Board property box
    CSWalt Level 9

    Hi,

     

     

    On 04/25/12 13:03, Christian Bohrer wrote:

    "Walter Spermann" <Walter.Spermann@cadsoft.de> a écrit dans le message de news:

    jmp975$34i$1@cheetah.cadsoft.de...

    >> On 03/30/12 13:27, Christian Bohrer wrote:

    >>> "Walter Spermann" <Walter.Spermann@cadsoft.de> a écrit dans le message de news:

    >>> jl44t8$951$1@cheetah.cadsoft.de...

    >>>> On 03/29/12 16:09, Christian Bohrer wrote:

    >>>>> when this parameter is set to '1' :

    >>>>> Sch.Cmd.Add.AlwaysUseDeviceNameAsValue = "1"

    >>>>>

    >>>>> In the Board, the Value attribute is hidden in the info (properties) box

    >>>>> and also in the Attribute box.

    >>>>> Is it intended?

    >>>>>

    >>>> We can reproduce it and are looking into this.

    >> We thought over the handling of the attribute VALUE.

    >> What is it actually useful for ? It's necessary to define devices with their own value.

     

    You just have to consider the attribute VALUE (if exist) as an alias of the device_name

    If an attribute VALUE exist and if it is not empty, then, it's value is used instead the

    device_name

     

    >> Once added, the part gets the device's VALUE attribute as value and also

    >> the device's attribute VALUE. Now it's confusing:

     

    No! It's confusing because we are not talking about the same use

    Two cases to consider:

    1) The user add a generic resistor (without attribute VALUE) in a schematic, the part_value is

    initialized with the device_name: "RESISTOR-0805", the user edit the part_value and replace

    "RESISTOR-0805" by "4k7".

    Now, if the user replace the generic resistor by a 0603 or a 1206, the part_value keeps "4k7" (all

    works as expected).

     

    2) The user add a defined resistor (pre-filled), chosen from thousands in his library, the

    component has many attributes pre filled (PARTNUMBER, REFERENCE, MANUFACTURER, VALUE ...) that

    appear in the BOM.

    The full device_name is: "Resistor-0805-49.9R-0.1%", but as an attribute VALUE exist, the

    part_value is initialized with the attribute VALUE : "49.9R"  (as expected).

    Now, if the user replace the "Resistor-0805-49.9R-0.1%" by a "Resistor-0603-2K2-1%", all attributes

    are updated but the part_value is not updated with the new value "2K2", the part_value keeps "4k7"

    (iznogood) :o(

     

    Attached a library to see the problem. Thanks in advance to play with it.

     

    >> 1. What if the user changes the attribute VALUE ?

     

    The same as for others attributes: the part value will be updated by the attribute VALUE at the

    next "update from library"

    Maybe with a warning before to update.

     

    >> 2. What if the part's value is changed by the value command ?

     

    The same rules apply regardless of the origin of content: device_name or attribute VALUE

    Else, why initialise a VALUE attribute in a device whose value should be changed later with the

    value command ??

     

    >> One could expect that in case 1 the part value and in case 2 the attribute value

    >> has to be changed also. But this is actually redundant.

    >> Once the device is added the attribute VALUE is no longer interesting.

     

    At the contrary, the attribute VALUE is very interesting for the replacement of parts.

    If you don't want to replace the part_value with the device_name because you find it too ugly,

    If you don't want to edit and modifiy manually the part_value each time you replace a part because

    you find it fastidious,

    If you are afraid to forget to change manually the part_value after a replace, then, you will find

    very interesting to use the attribute VALUE instead the device_name.

    I tested with your sample library. Now after a change of the package/technology

    or replace the value is updated with new device's VALUE attribute if it exists.

    The attribute VALUE itself is not available to the user. He can change the value

    only with the value command.

     

    Regards,

    Walter Spermann

    >> That's why we want to keep out this attribute for the future

    >> (both schematic and board). Does this make sense to you ?

    >>

    >> Regards,

    >> Walter Spermann

     

     

     

     

    --

    -


    Walter Spermann

    Softwareentwicklung

    CadSoft Computer GmbH

    Pleidolfweg 15

    84568 Pleiskirchen

    Tel.: 08635/6989-10

    www.cadsoft.de

    -


    Registergericht: Amtsgericht Traunstein HRB 5573

    Geschäftsführer: Thomas Liratsch

    -


     

  • 10. Re: 6.1.4: VALUE attribute hidden in Board property box
    CSWalt Level 9

    On 04/25/12 23:08, James Morrison wrote:

    Andreas Weidner wrote on Wed, 25 April 2012 08:49

    >> Am 25.04.2012 13:03, schrieb Christian Bohrer:

    >>>> Once added, the part gets the device's VALUE attribute as value and

    >> also

    >>>> the device's attribute VALUE. Now it's confusing:

    >>

    >> I'm a bit unfair now, but I still mean it: The whole 'that is

    >> confusing'

    >> story is due to CadSoft's improper use of the English and/or German

    >> language: In the schematics/board, every part/element should have a

    >> decent VALUE. In the library, NOBODY needs a value. Not EVER!

    >> Therefore,

    >> having a VERY USEFUL attribute in a library and call it VALUE is prone

    >>

    >> to misunderstandings. The library's VALUE attribute does NOT have the

    >> same meaning as the VALUE in schematics or board, so it should NOT have

    >>

    >> the same name. ALL misunderstandings would vanish if the library's

    >> attribute would be called DEFAULTVALUE.

    >>

    >> EVERYBODY will then IMMEDIATELY understand the function of this

    >> attribute, because it has a DESCRIPTIVE name, which can NOT be mixed up

    >>

    >> with VALUE.

    >>

    >> Proposal:

    >>   1. Rename the VALUE attribute in libraries DEFAULTVALUE.

    >>   2. Do NOT allow the creation of any attribute that is called

    >>      VALUE or NAME in libraries any more.

    >>   3. For backwards compatibility (there might be libraries that

    >>      already make use of VALUE), on the opening of a library,

    >>      immediately convert VALUE to DEFAULTVALUE.

    Well, the attribute 'VALUE' was a compromise to meet some user's need to assign a value

    (or default or predefined value) to library devices. The original idea was that

    library devices should not have a value.

    As we know it's still not common practice that people need that in the libraries.

    Ideally this should be an additional device property, not an attribute.

    But if we put this into the GUI right now, the majority will ask

    "Ah, a (default) value. What is this good for ?" and have to learn this.

    We think it's better to keep the convention we have right now,

    but make this work consistently.

     

     

    I agree with this Andreas.  That would be a good start.

     

    I'm not sure this completely addresses my needs.  I have a default value in

    the library for every device.  Let's talk resistors since it is easy to

    see:  I have a R_ device with technology "10K-1%" and package -0402 and

    this combo has a default value of "10K".  Another technology of "33R-1%"

    has a value of "33R".

     

    So I plop down a 10K resistor and then I change the value to "10K DNP" (our

    way of not populating the device).  So when I do a library update I don't

    want that value to change.  However, if I change technology or replace with

    another device then I DO want the value to change to the default value in

    the library--currently this is what doesn't happen.

    Yes, that's exactly how it will behave in coming 6.2.1:

    The value is updated in change package/technology and replace,

    not in the library update.

     

     

    This needs to be changed too and I think it might be addressed by what

    Walter posted earlier.  But I want to make sure.

     

    And please, if you're changing the update algorithm then please, please,

    please come up with an error/warning/log/status/report of devices that are

    in the design but not found in the libraries!  That is a huge whole in the

    current scheme.  If I make a change to a library and then "update all" I

    have no idea if the change I just made actually made it into the design

    without going to explore the exact details.  Not having the library in the

    correct location is the prime reason this could happen.  At the very least

    create a report stating which devices were updated and from what libraries,

    even better would indicate the differences.

    That's another topic. We have this on our list for the next minor releases,

    where we plan a number of UI improvements.

     

     

    The next higher step would be to create a list of changes that will occur

    like Altium does and then allow the user to select which to apply.

     

    I've had to use Altium for a few projects with a particular customer and I

    must say that there are some really nice features that save huge amounts of

    time.  There are others that I think EAGLE gets it done better but a few

    additions to EAGLE would make a big difference in closing the gap.

     

    Quote:

    >> CadSoft: Please consider thinking as a user would, and NOT a programmer

     

    Always good advice!

    I understand. To be exact, it's not A user it's MANY users and that

    makes it more difficult...:-)

     

    Regards,

    Walter Spermann

     

     

    James.

     

     

     

    --

    -


    Walter Spermann

    Softwareentwicklung

    CadSoft Computer GmbH

    Pleidolfweg 15

    84568 Pleiskirchen

    Tel.: 08635/6989-10

    www.cadsoft.de

    -


    Registergericht: Amtsgericht Traunstein HRB 5573

    Geschäftsführer: Thomas Liratsch

    -