The coordinate (@) in context space

On 11/16/2016 9:16 AM, Chuck Huber wrote:

On 11/16/2016 12:08 AM, warrenbrayshaw wrote:

 

...

Maybe it would be possible to snap the cursor position at every right

click. In that way when no object is selected and hence no context

menu appears, the cursor position is saved. This would need careful

consideration of the other right click activities and the optional use

some of the SET commands afford.

 

They're already doing this with the context menu.  Recall that the

cursor position can be restored after selecting an item from a context menu.

 

The programming effort lies in exposing this to a ULP.

 

 

 

In use it may not be good as there is no indication of the point or a

visual break in the workflow as happens with a context menu. Which

brings one back to placing a mark, for the purpose.

 

Very good point.

 

HTH,

    - Chuck

 

This is going to take some work. There are already a few enhancement

requests for having ULPs interact with the mouse.

Once those start getting addressed I think we will definitely run into this.

Thanks guys for the comments.

Best Regards,

Jorge Garcia

On 11/16/2016 12:08 AM, warrenbrayshaw wrote:

...

Maybe it would be possible to snap the cursor position at every right

click. In that way when no object is selected and hence no context

menu appears, the cursor position is saved. This would need careful

consideration of the other right click activities and the optional use

some of the SET commands afford.

They're already doing this with the context menu.  Recall that the

cursor position can be restored after selecting an item from a context menu.

The programming effort lies in exposing this to a ULP.

 

In use it may not be good as there is no indication of the point or a

visual break in the workflow as happens with a context menu. Which

brings one back to placing a mark, for the purpose.

Very good point.

HTH,

    - Chuck

On 16/11/2016 9:54 a.m., Chuck Huber wrote:

On 11/15/2016 12:17 PM, Jorge Garcia wrote:

Jorge, I'll second this request and add one more to it.

 

In addition to cursor.x and cursor.y, could you also request mark.x and

mark.y, which would allow a ULP to generate a script using relative

coordinates?

 

 

Hi Chuck,

 

I would like a little clarification here. Currently you can have a

script act on relative coordinates by including an R in all of the

point locations. For ex.:

 

WIRE (R 0 0) (R 1 1);

 

Those coordinates will be relative to any MARK command set in the

board. Obviously you could place a MARK statement earlier in the

script so I don't know why the mark.x and mark.y objects would be

necessary.

 

Could you clarify please?

 

Hmmm...  I had a scenario in my mind where one would need the mark's

coordinates.  But the need escapes me right now.

 

I believe it had something to do with setting the mark, then restoring

it prior to exiting a script.  So, more of push/pop of the mark coords

to a stack, perhaps elements deep?  Of course, if one has mark.{x,y}

available, then the ULP author could determine how best to save and

restore them.

 

If one wanted to generate an auto-placement script, then related groups

of components would be best placed relative to the mark, such as in a

multi-pole filter.  Then move the mark and place the next filter.

 

Of course, the mark merely represents an x and y offset, which is quite

simple to maintain in a ULP and use absolute coordinates.

 

Well, suffice to say that the scenario escapes this already cluttered

mind.  If I think of it, I'll follow up.

 

    - Chuck

 

 

In the past I wished that mark.x and mark.y was available as this could

have been a way of indicating to a ULP the coordinates of a point of

interest as it was not possible to get the cursor coordinates.

It seems a simple thing to have available.

Even if the cursor coordinates do become available, the coordinates of

the cursor would be saved either by initiating a context menu or at the

commencement of any/every ulp when it is not an object being targeted .

This requires one to position the mouse and then initiate the ulp from

an assigned key.

It's an easily won argument that such a two handed operation is a bit

odd and definitely not 'accessible'.  In this case it would be better to

set the mark and have a ULP read the coordinates from within the ULP.

Maybe it would be possible to snap the cursor position at every right

click. In that way when no object is selected and hence no context menu

appears, the cursor position is saved. This would need careful

consideration of the other right click activities and the optional use

some of the SET commands afford.

In use it may not be good as there is no indication of the point or a

visual break in the workflow as happens with a context menu. Which

brings one back to placing a mark, for the purpose.

HTH

Warren

On 11/15/2016 12:17 PM, Jorge Garcia wrote:

Jorge, I'll second this request and add one more to it.

 

In addition to cursor.x and cursor.y, could you also request mark.x and

mark.y, which would allow a ULP to generate a script using relative

coordinates?

 

 

Hi Chuck,

 

I would like a little clarification here. Currently you can have a

script act on relative coordinates by including an R in all of the

point locations. For ex.:

 

WIRE (R 0 0) (R 1 1);

 

Those coordinates will be relative to any MARK command set in the

board. Obviously you could place a MARK statement earlier in the

script so I don't know why the mark.x and mark.y objects would be

necessary.

 

Could you clarify please?

Hmmm...  I had a scenario in my mind where one would need the mark's

coordinates.  But the need escapes me right now.

I believe it had something to do with setting the mark, then restoring

it prior to exiting a script.  So, more of push/pop of the mark coords

to a stack, perhaps elements deep?  Of course, if one has mark.{x,y}

available, then the ULP author could determine how best to save and

restore them.

If one wanted to generate an auto-placement script, then related groups

of components would be best placed relative to the mark, such as in a

multi-pole filter.  Then move the mark and place the next filter.

Of course, the mark merely represents an x and y offset, which is quite

simple to maintain in a ULP and use absolute coordinates.

Well, suffice to say that the scenario escapes this already cluttered

mind.  If I think of it, I'll follow up.

    - Chuck

Jorge, I'll second this request and add one more to it.

 

In addition to cursor.x and cursor.y, could you also request mark.x and

mark.y, which would allow a ULP to generate a script using relative

coordinates?

 

Hi Chuck,

I would like a little clarification here. Currently you can have a

script act on relative coordinates by including an R in all of the point

locations. For ex.:

WIRE (R 0 0) (R 1 1);

Those coordinates will be relative to any MARK command set in the board.

Obviously you could place a MARK statement earlier in the script so I

don't know why the mark.x and mark.y objects would be necessary.

Could you clarify please?

Best Regards,

Jorge Garcia

On 11/14/2016 03:51 AM, warrenbrayshaw wrote:

On 14/11/2016 8:07 p.m., Morten Leikvoll wrote:

On 11.11.2016 20:26, Jorge Garcia wrote:

Hi Morten

 

I find it best to set:

 

set Option.RepositionMouseCursorAfterContextMenu 1

 

That gets the mouse back to the correct point before your context ulp

runs.

 

I suspect this will solve your issue.

 

Warren

 

 

Hi Warren,

 

Thanks for teaching me something new today. I was not aware of this

option. Should be very handy for people who like to use context menus.

 

Best Regards,

Jorge Garcia

Autodesk Support

 

Ok, it may be a way around, but I really can't stand the mousepointer

jumping to a different position. My mind seems to always be aware about

the approximate position of the mousepointer, and even if my brain maybe

can be teached to handle this, it's not my preference.

 

Long time ago I used some Linux distros that had this 'issue' and it

really pissed me off and made me loose concentration. Using a large

screen makes this issue even worse, as the mousepointer can jump away

from your main focus area. Not to mention that you constantly have to

lift the mouse to re-calibrate your mouse span area.

 

My suggestion can't possible be that hard to implement?

 

 

 

Sorry Morten, I did not interpret correctly what you were asking for.

 

I agree and support your request and with further enhancements that

makes the (@) far more usable.

 

Currently you cannot discover where the @ is from within a ULP, easily.

 

When the cursor location is saved, when the context menu is opened, it

should be stored such that the coordinates are readable within a ULP.

Well, it sort of is, right now... sort of.

The object on which the right-click occurred is selected.  While the

coordinates of the selected object may not be the coordinates of the

mouse pointer, they are fairly close.  Is it really the mouse pointer

coordinates that are desired, or the object it locates?

I know... it's a stretch to say that the mouse pointer coordinates are

available.  Hence the "sort of".

 

The value at any time could represent the location of the cursor at

the last time a context menu was displayed.

 

There is a second use case that I would like addressed. Sometimes I

position the cursor and run a ULP from assigned key especially when

there is not an object to tie a context menu to.

The "sort of" scenario above doesn't address this.

...

 

That said, it would be far nicer to be able to simply read it directly

as an object value like cursor.x and cursor.y and avoid using cfgget().

Jorge, I'll second this request and add one more to it.

In addition to cursor.x and cursor.y, could you also request mark.x and

mark.y, which would allow a ULP to generate a script using relative

coordinates?

Best regards,

    - Chuck

On 11/14/2016 03:51 AM, warrenbrayshaw wrote:

On 14/11/2016 8:07 p.m., Morten Leikvoll wrote:

On 11.11.2016 20:26, Jorge Garcia wrote:

Hi Morten

 

I find it best to set:

 

set Option.RepositionMouseCursorAfterContextMenu 1

 

That gets the mouse back to the correct point before your context ulp

runs.

 

I suspect this will solve your issue.

 

Warren

 

 

Hi Warren,

 

Thanks for teaching me something new today. I was not aware of this

option. Should be very handy for people who like to use context menus.

 

Best Regards,

Jorge Garcia

Autodesk Support

 

Ok, it may be a way around, but I really can't stand the mousepointer

jumping to a different position. My mind seems to always be aware about

the approximate position of the mousepointer, and even if my brain maybe

can be teached to handle this, it's not my preference.

 

Long time ago I used some Linux distros that had this 'issue' and it

really pissed me off and made me loose concentration. Using a large

screen makes this issue even worse, as the mousepointer can jump away

from your main focus area. Not to mention that you constantly have to

lift the mouse to re-calibrate your mouse span area.

 

My suggestion can't possible be that hard to implement?

 

 

 

Sorry Morten, I did not interpret correctly what you were asking for.

 

I agree and support your request and with further enhancements that

makes the (@) far more usable.

 

Currently you cannot discover where the @ is from within a ULP, easily.

 

When the cursor location is saved, when the context menu is opened, it

should be stored such that the coordinates are readable within a ULP.

Well, it sort of is, right now... sort of.

The object on which the right-click occurred is selected.  While the

coordinates of the selected object may not be the coordinates of the

mouse pointer, they are fairly close.  Is it really the mouse pointer

coordinates that are desired, or the object it locates?

I know... it's a stretch to say that the mouse pointer coordinates are

available.  Hence the "sort of".

 

The value at any time could represent the location of the cursor at

the last time a context menu was displayed.

 

There is a second use case that I would like addressed. Sometimes I

position the cursor and run a ULP from assigned key especially when

there is not an object to tie a context menu to.

The "sort of" scenario above doesn't address this.

...

 

That said, it would be far nicer to be able to simply read it directly

as an object value like cursor.x and cursor.y and avoid using cfgget().

Jorge, I'll second this request and add one more to it.

In addition to cursor.x and cursor.y, could you also request mark.x and

mark.y, which would allow a ULP to generate a script using relative

coordinates?

Best regards,

    - Chuck

On 14/11/2016 8:07 p.m., Morten Leikvoll wrote:

On 11.11.2016 20:26, Jorge Garcia wrote:

Hi Morten

 

I find it best to set:

 

set Option.RepositionMouseCursorAfterContextMenu 1

 

That gets the mouse back to the correct point before your context ulp

runs.

 

I suspect this will solve your issue.

 

Warren

 

 

Hi Warren,

 

Thanks for teaching me something new today. I was not aware of this

option. Should be very handy for people who like to use context menus.

 

Best Regards,

Jorge Garcia

Autodesk Support

 

Ok, it may be a way around, but I really can't stand the mousepointer

jumping to a different position. My mind seems to always be aware about

the approximate position of the mousepointer, and even if my brain maybe

can be teached to handle this, it's not my preference.

 

Long time ago I used some Linux distros that had this 'issue' and it

really pissed me off and made me loose concentration. Using a large

screen makes this issue even worse, as the mousepointer can jump away

from your main focus area. Not to mention that you constantly have to

lift the mouse to re-calibrate your mouse span area.

 

My suggestion can't possible be that hard to implement?

 

Sorry Morten, I did not interpret correctly what you were asking for.

I agree and support your request and with further enhancements that

makes the (@) far more usable.

Currently you cannot discover where the @ is from within a ULP, easily.

When the cursor location is saved, when the context menu is opened, it

should be stored such that the coordinates are readable within a ULP.

The value at any time could represent the location of the cursor at the

last time a context menu was displayed.

There is a second use case that I would like addressed. Sometimes I

position the cursor and run a ULP from assigned key especially when

there is not an object to tie a context menu to. Being able to ascertain

the cursor position from within the ULP in this situation would be

valuable. This would mean snapping the location of (@) at 'run

myulp.ulp' time. This should only be done if you have not initiated a

context menu ulp. These are both very similar actions. In both cases the

editor can be considered frozen as you start into the ulp.

I currently use an entanglement of script and ULP (gets really ugly)  to

ascertain the position and store it using cfgset. The cursor X Y is

stored in internal units looking like ULP:cursorpoint = "3449538 7133021"

So something similar as an Eagle:value should be usable.

I thought a separate value for X and Y would be of value but its simple

enough to split out the text values and convert to integers.

That said, it would be far nicer to be able to simply read it directly

as an object value like cursor.x and cursor.y and avoid using cfgget().

Regards

Warren

On 14/11/2016 8:07 p.m., Morten Leikvoll wrote:

On 11.11.2016 20:26, Jorge Garcia wrote:

Hi Morten

 

I find it best to set:

 

set Option.RepositionMouseCursorAfterContextMenu 1

 

That gets the mouse back to the correct point before your context ulp

runs.

 

I suspect this will solve your issue.

 

Warren

 

 

Hi Warren,

 

Thanks for teaching me something new today. I was not aware of this

option. Should be very handy for people who like to use context menus.

 

Best Regards,

Jorge Garcia

Autodesk Support

 

Ok, it may be a way around, but I really can't stand the mousepointer

jumping to a different position. My mind seems to always be aware about

the approximate position of the mousepointer, and even if my brain maybe

can be teached to handle this, it's not my preference.

 

Long time ago I used some Linux distros that had this 'issue' and it

really pissed me off and made me loose concentration. Using a large

screen makes this issue even worse, as the mousepointer can jump away

from your main focus area. Not to mention that you constantly have to

lift the mouse to re-calibrate your mouse span area.

 

My suggestion can't possible be that hard to implement?

 

Sorry Morten, I did not interpret correctly what you were asking for.

I agree and support your request and with further enhancements that

makes the (@) far more usable.

Currently you cannot discover where the @ is from within a ULP, easily.

When the cursor location is saved, when the context menu is opened, it

should be stored such that the coordinates are readable within a ULP.

The value at any time could represent the location of the cursor at the

last time a context menu was displayed.

There is a second use case that I would like addressed. Sometimes I

position the cursor and run a ULP from assigned key especially when

there is not an object to tie a context menu to. Being able to ascertain

the cursor position from within the ULP in this situation would be

valuable. This would mean snapping the location of (@) at 'run

myulp.ulp' time. This should only be done if you have not initiated a

context menu ulp. These are both very similar actions. In both cases the

editor can be considered frozen as you start into the ulp.

I currently use an entanglement of script and ULP (gets really ugly)  to

ascertain the position and store it using cfgset. The cursor X Y is

stored in internal units looking like ULP:cursorpoint = "3449538 7133021"

So something similar as an Eagle:value should be usable.

I thought a separate value for X and Y would be of value but its simple

enough to split out the text values and convert to integers.

That said, it would be far nicer to be able to simply read it directly

as an object value like cursor.x and cursor.y and avoid using cfgget().

Regards

Warren

On 14/11/2016 8:07 p.m., Morten Leikvoll wrote:

On 11.11.2016 20:26, Jorge Garcia wrote:

Hi Morten

 

I find it best to set:

 

set Option.RepositionMouseCursorAfterContextMenu 1

 

That gets the mouse back to the correct point before your context ulp

runs.

 

I suspect this will solve your issue.

 

Warren

 

 

Hi Warren,

 

Thanks for teaching me something new today. I was not aware of this

option. Should be very handy for people who like to use context menus.

 

Best Regards,

Jorge Garcia

Autodesk Support

 

Ok, it may be a way around, but I really can't stand the mousepointer

jumping to a different position. My mind seems to always be aware about

the approximate position of the mousepointer, and even if my brain maybe

can be teached to handle this, it's not my preference.

 

Long time ago I used some Linux distros that had this 'issue' and it

really pissed me off and made me loose concentration. Using a large

screen makes this issue even worse, as the mousepointer can jump away

from your main focus area. Not to mention that you constantly have to

lift the mouse to re-calibrate your mouse span area.

 

My suggestion can't possible be that hard to implement?

 

Sorry Morten, I did not interpret correctly what you were asking for.

I agree and support your request and with further enhancements that

makes the (@) far more usable.

Currently you cannot discover where the @ is from within a ULP, easily.

When the cursor location is saved, when the context menu is opened, it

should be stored such that the coordinates are readable within a ULP.

The value at any time could represent the location of the cursor at the

last time a context menu was displayed.

There is a second use case that I would like addressed. Sometimes I

position the cursor and run a ULP from assigned key especially when

there is not an object to tie a context menu to. Being able to ascertain

the cursor position from within the ULP in this situation would be

valuable. This would mean snapping the location of (@) at 'run

myulp.ulp' time. This should only be done if you have not initiated a

context menu ulp. These are both very similar actions. In both cases the

editor can be considered frozen as you start into the ulp.

I currently use an entanglement of script and ULP (gets really ugly)  to

ascertain the position and store it using cfgset. The cursor X Y is

stored in internal units looking like ULP:cursorpoint = "3449538 7133021"

So something similar as an Eagle:value should be usable.

I thought a separate value for X and Y would be of value but its simple

enough to split out the text values and convert to integers.

That said, it would be far nicer to be able to simply read it directly

as an object value like cursor.x and cursor.y and avoid using cfgget().

Regards

Warren