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

    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

          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

              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

                  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

                          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

                            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

                            -