The coordinate (@) in context space

On 12/11/2016 5:30 a.m., Morten Leikvoll wrote:

From the help:

"(@) can be used to reference the current position of the mouse cursor

within the draw window."

 

When using @ from a context menu driven ULP, the @ refers to the

position where the cursor was when the menu item was executed.

 

I suggest this is changed to represent the point where the mousepointer

was when the context menu was opened. It should not conflict with normal

non context use.

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 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

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?

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?

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

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

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