EAGLE Central Forums
Where the EAGLE community meets. Sponsored by Stratford Digital.

Home » CadSoft Support Forums » eagle.suggest.eng » The coordinate (@) in context space
The coordinate (@) in context space [message #167731] Fri, 11 November 2016 16:30 Go to next message
Morten Leikvoll
Messages: 1340
Registered: November 2007
Senior Member
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.
Re: The coordinate (@) in context space [message #167734 is a reply to message #167731] Fri, 11 November 2016 18:35 Go to previous messageGo to next message
warrenbrayshaw
Messages: 1732
Registered: January 2010
Location: New Zealand
Senior Member
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
Re: The coordinate (@) in context space [message #167735 is a reply to message #167734] Fri, 11 November 2016 19:26 Go to previous messageGo to next message
Jorge Garcia
Messages: 1282
Registered: April 2010
Senior Member
> 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
Re: The coordinate (@) in context space [message #167756 is a reply to message #167735] Mon, 14 November 2016 07:07 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1340
Registered: November 2007
Senior Member
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?
Re: The coordinate (@) in context space [message #167758 is a reply to message #167756] Mon, 14 November 2016 08:51 Go to previous messageGo to next message
warrenbrayshaw
Messages: 1732
Registered: January 2010
Location: New Zealand
Senior Member
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
Re: The coordinate (@) in context space [message #167759 is a reply to message #167758] Mon, 14 November 2016 13:30 Go to previous messageGo to next message
Chuck Huber
Messages: 592
Registered: October 2004
Senior Member
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
Re: The coordinate (@) in context space [message #167777 is a reply to message #167759] Tue, 15 November 2016 17:17 Go to previous messageGo to next message
Jorge Garcia
Messages: 1282
Registered: April 2010
Senior Member
> 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
Re: The coordinate (@) in context space [message #167787 is a reply to message #167777] Tue, 15 November 2016 20:54 Go to previous messageGo to next message
Chuck Huber
Messages: 592
Registered: October 2004
Senior Member
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
Re: The coordinate (@) in context space [message #167790 is a reply to message #167787] Wed, 16 November 2016 05:08 Go to previous messageGo to next message
warrenbrayshaw
Messages: 1732
Registered: January 2010
Location: New Zealand
Senior Member
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
Re: The coordinate (@) in context space [message #167804 is a reply to message #167790] Wed, 16 November 2016 14:16 Go to previous messageGo to next message
Chuck Huber
Messages: 592
Registered: October 2004
Senior Member
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
Re: The coordinate (@) in context space [message #167805 is a reply to message #167804] Wed, 16 November 2016 17:37 Go to previous message
Jorge Garcia
Messages: 1282
Registered: April 2010
Senior Member
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
Previous Topic: Gateswap across schematic sheets
Next Topic: Origin layer at schematic editor
Goto Forum:
  


Current Time: Mon Mar 27 10:40:19 GMT 2017