← Back to team overview

kicad-developers team mailing list archive

Re: Macro expansion in module text

 

On 10/6/2014 11:42 AM, Brian Sidebotham wrote:
> On 6 October 2014 16:23, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>> Lorenzo,
>>
>> I know it's a pain to do but this really needs to be documented
>> somewhere in the Pcbnew user's manual.  Otherwise, no one will know how
>> to use this excellent feature except those of us on the developers
>> mailing list.  The reason I'm asking you to do this is that yesterday I
>> was attempting use the BOM generator which I haven't used in a long time
>> and discovered that the current documentation is completely different
>> than the actual behavior of Eeschema.  We *all* really need to do a
>> better job of keeping the documentation current.  I'm not singling you
>> out Lorenzo but if we truly want to provide a stable release at some
>> point in the near future then we really should keep the documentation
>> current.  If you add a new feature, change the way a current feature
>> functions, or happen to stumble across an documentation error, please
>> make sure the documentation gets updated.  I know there is work under
>> way to convert to a text based format but we should continue to keep the
>> odt documentation up to date until that actually happens.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 10/4/2014 11:26 AM, Lorenzo Marcantonio wrote:
>>> Sorry about the delay, we had the automechanika fair and related stuff
>>> to handle :P
>>>
>>> In fact the patch is quite simple (I already did the biggest changes...)
>>>
>>> It handles % sequences in user text primitives inside modules
>>> (usefulness already debated); now it recognizes:
>>>
>>> %% for a plain %
>>> %R inserts the reference
>>> %V inserts the value
>>>
>>> Obviously it can be extended to insert other stuff (has to be available
>>> from the module class, however).
>>>
>>> The only issue is repainting, since it insert a dependency between
>>> unrelated fields: when you change reference or value the user fields
>>> using them are not updated until the next redraw. Shouldn't be a big
>>> problem, however.
>>>
>>> Extensive testing is, as usual, appreciated.
>>>
>>> Have fun
>>>
>>
> 
> I know it was only a few lines of code Lorenzo, but you wrote them not
> me, so thank-you! I've had so little time to do anything lately and I
> really wanted to be able to do the assembly layer properly for a long
> time.
> 
> Wayne, I agree and I am about to commit some changes to the EESCHEMA
> options dialog to improve the template field editing and some general
> tidy up with the code class.
> 
> I was wondering if we should document this in the current docs or wait
> until the new docs. I will update the documentation as soon as the
> dialog changes are in place.

I would prefer that you go ahead and update the current docs.  I have
not heard anything from our intrepid documentation conversion folks so
until I have a definitive answer, I think it's a good idea to keep
things documented in a known location to prevent them from falling
through the cracks.  If they have to be pulled forward into the new
document format, so be it.  Thank you for the help.

Cheers,

Wayne

> 
> I still need to add validation to the template field names too, but I
> will do that as a second patch because I'm running out of time and
> I've already had to deal with conflicts in the fbp generated XML once
> (it was a nightmare!) so I'm keen for that not to happen again.
> 
> Best Regards,
> 
> Brian.
> 



References