NAME command in ULP

Apologies for testing in the "live" forum. Please disregard. Just checking

to see if this reply appends correctly to the right thread on element14's

side. Carry on.

--

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

Apologies for testing in the "live" forum. Please disregard. Just checking

to see if this reply appends correctly to the right thread on element14's

side. Carry on.

--

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

Morten Leikvoll wrote on Thu, 19 May 2016 14:33

Surely there must be some reserved character that can be used to avoid

 

mixup with any names? Like the character ':', so you could define

commands like:

 

NAME :allsheets: <oldname> <newname>;

 

But maybe allsheets should be explicit on this syntax. Also,

 

NAME :thissheets: <newname> (x y);

 

Would work. The position of :<flag>: is kinda relaxed on this syntax,

so

even

 

NAME <oldname> (x y) :thisseg:;

will be consistant.

 

Even using multiple independantly placed keywords could work here,

like

 

NAME <oldname> :thisseg: (x y) :includepolygons:;

 

 

This is very easy to interpret for the commant interpreter.

As shown, I do prefer having some name instead of single character or

numbers for the selections. They will also work for future added

keywords.

Yep this all seems completely sensible to me

--

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

CadSoft Support wrote on Thu, 19 May 2016 13:30

To add such options as Rachael suggested is possible, but IMHO not

so elegant. Think also of signal polygons in the board? There we would

need additional options like P for Polygon only , or W for whole signal

 

or something like that....

We get a number of letters that have to be distinguisable from the

names.

My suggestion of T E and A as the options was only because that is

consistent with what is stated in the help for the keys to press to select

these options. I'd much prefer a much more descriptive switch. So I'd vote

for something like:

NAME --this  (x y)

Omitting the --switch would produce the same behaviour as currently so it

would not break exisiting functionality.

This syntax would work consistently across all commands regardless of what

the dialog options were.

CadSoft Support wrote on Thu, 19 May 2016 13:30

On the other hand for SET CONFIRM we could add some options like

OPT1, OPT2, OPT3 and preselect/address/confirm the wanted option

of the dialog. This would work for all dialogs that offer more options

to choose. It fits better in the current structure of EAGLE.

Having to "wrap" every NAME (or any other) command in a pair of "SET

CONFIRM YES/NO/OFF" commands to get the desired behaviour is IMHO an overly

verbose cludge

Best Regards,

Rachael

--

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

On 19.05.2016 14:30, Richard Hammerl wrote:

Am 19.05.2016 um 11:16 schrieb Morten Leikvoll:

On 19.05.2016 10:55, Richard Hammerl wrote:

I think this could be an enhancement of the SET CONFIRM command.

We will check this....

 

Now, THAT you have to explain. I think the rest of us would say no. The

inline option is much better. It does not need to be backward compatible

as long as no explicit selection opens the requester as before.

 

 

 

The inline option with the NAME command? It's a bit tricky there

because of the current syntax.

You can for example use  NAME oldname newname   or   NAME name (x y)

 

To add such options as Rachael suggested is possible, but IMHO not

so elegant. Think also of signal polygons in the board? There we would

need additional options like P for Polygon only , or W for whole signal

or something like that....

We get a number of letters that have to be distinguisable from the

names.

 

On the other hand for SET CONFIRM we could add some options like

OPT1, OPT2, OPT3 and preselect/address/confirm the wanted option

of the dialog. This would work for all dialogs that offer more options

to choose. It fits better in the current structure of EAGLE.

 

For example:

NAME net

OPT1  this segment               set confirm opt1; name GND (0 1);

OPT2  all segments on sheet      set confirm opt2; name GND (0 1);

OPT3  all segments on all sheets set confirm opt3; name GND (0 1);

 

NAME polygon

OPT1 polygon only         set confirm opt1; name GND (0 1);

OPT2 whole signal         set confirm opt2; name GND (0 1);

 

And we would be prepared for future dialogs as well. 

Surely there must be some reserved character that can be used to avoid

mixup with any names? Like the character ':', so you could define

commands like:

NAME :allsheets:  :thisseg: (x y) :includepolygons:;

This is very easy to interpret for the commant interpreter.

As shown, I do prefer having some name instead of single character or

numbers for the selections. They will also work for future added keywords.

Am 19.05.2016 um 11:16 schrieb Morten Leikvoll:

On 19.05.2016 10:55, Richard Hammerl wrote:

I think this could be an enhancement of the SET CONFIRM command.

We will check this....

 

Now, THAT you have to explain. I think the rest of us would say no. The

inline option is much better. It does not need to be backward compatible

as long as no explicit selection opens the requester as before.

 

 

The inline option with the NAME command? It's a bit tricky there

because of the current syntax.

You can for example use  NAME oldname newname   or   NAME name (x y)

To add such options as Rachael suggested is possible, but IMHO not

so elegant. Think also of signal polygons in the board? There we would

need additional options like P for Polygon only , or W for whole signal

or something like that....

We get a number of letters that have to be distinguisable from the

names.

On the other hand for SET CONFIRM we could add some options like

OPT1, OPT2, OPT3 and preselect/address/confirm the wanted option

of the dialog. This would work for all dialogs that offer more options

to choose. It fits better in the current structure of EAGLE.

For example:

NAME net

  OPT1  this segment               set confirm opt1; name GND (0 1);

  OPT2  all segments on sheet      set confirm opt2; name GND (0 1);

  OPT3  all segments on all sheets set confirm opt3; name GND (0 1);

NAME polygon

  OPT1 polygon only         set confirm opt1; name GND (0 1);

  OPT2 whole signal         set confirm opt2; name GND (0 1);

And we would be prepared for future dialogs as well. 

--

Mit freundlichen Gruessen / Best regards

Richard Hammerl

  CadSoft Support -- hotline@cadsoft.de

  FAQ: http://www.cadsoft.de/training/faq/

On 19.05.2016 10:55, Richard Hammerl wrote:

I think this could be an enhancement of the SET CONFIRM command.

We will check this....

Now, THAT you have to explain. I think the rest of us would say no. The

inline option is much better. It does not need to be backward compatible

as long as no explicit selection opens the requester as before.

Am 18.05.2016 um 16:20 schrieb Rachael:

rachaelp wrote on Wed, 18 May 2016 13:48

However..... I just installed 7.6.0 and something has changed and what

used to work perfectly now erroneously puts net names all over my busses

in some cases..... I'll tidy up my script and generate a simple test

schematic and pop it over to CadSoft as I think this must be a newly

introduced bug.

 

Okay just a quick update, so it wasn't 7.6.0 that changed things, i found

that with my ULP script when I had busses / nets across multiple pages,

once I do:

 

set Cmd.Name.RenameEntireNetByDefault 1

 

then randomly things go a bit bonkers.... My ULP script is looping through

lots of objects and hierarchy to build up the final command which changes a

bunch of names so it must be some conflict with this setting and what I am

trying to achieve screwing everything up.... I need to investigate

further....

 

Following this thread I agree that there are missing options that

allow to choose exactly what to rename.

I think this could be an enhancement of the SET CONFIRM command.

We will check this....

--

Mit freundlichen Gruessen / Best regards

Richard Hammerl

  CadSoft Support -- hotline@cadsoft.de

  FAQ: http://www.cadsoft.de/training/faq/

rachaelp wrote on Wed, 18 May 2016 13:48

However..... I just installed 7.6.0 and something has changed and what

used to work perfectly now erroneously puts net names all over my busses

in some cases..... I'll tidy up my script and generate a simple test

schematic and pop it over to CadSoft as I think this must be a newly

introduced bug.

Okay just a quick update, so it wasn't 7.6.0 that changed things, i found

that with my ULP script when I had busses / nets across multiple pages,

once I do:

set Cmd.Name.RenameEntireNetByDefault 1

then randomly things go a bit bonkers.... My ULP script is looping through

lots of objects and hierarchy to build up the final command which changes a

bunch of names so it must be some conflict with this setting and what I am

trying to achieve screwing everything up.... I need to investigate

further....

--

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

Hi Warren/Lorenz,

Thanks both for pointing me in the direction of:

set Cmd.Name.RenameEntireNetByDefault 1

This does enable me to do most of what I would like now. I'd gone ahead and

wrapped my individual name commands within SET CONFIRM YES/OFF commands

already and this seemed to work generally okay so combined with this extra

command I think I can do what I need. I still think it's a bit of a clumsy

approach to be having to wrap these commands up with additional directives

to modify their behaviour. Having a consistent option available for

commands to specify the option to choose would lead to much cleaner scripts

in my opinion.

However..... I just installed 7.6.0 and something has changed and what used

to work perfectly now erroneously puts net names all over my busses in some

cases..... I'll tidy up my script and generate a simple test schematic and

pop it over to CadSoft as I think this must be a newly introduced bug.

Many thanks,

Rachael

--

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