Addition: Get current cursor type

[driven]

hi, great utility btw...
I'm using it inside app via an embedded ruby api.
I can get a click position from both ruby and cliclick to work out the offset factor to reliably find the window edge for a window drag resize...
that all works, however I can't work out a edge test to ensure I'm not being masked...
I was wondering if 'The resize-left-and-right cursor (resizeLeftRightCursor)' could be tested for and the dd: x,y target modified until true...
e.g. safe = safe + 10 if not left_right_cursor
drag = %Q[dd:#{@edg},#{safe} du:#{sq},+0]

so I guess it's a 'get cursor' function I'm after. e.g. cliclick gc:#{@edg},#{safe}
not convinced i'm making sense, but thought I'd ask...
john

[BlueM]

The Ruby code is not very helpful in understanding the issue, but (as you write yourself), it basically seems to boil down to getting the cursor type – which is not difficult.
The question is if it would be sufficient to implement getting the cursor and writing it to STDOUT (so your code can read it and use that information to judge what would be the appropriate action), or if you’d rather expect cliclick to do something like “if the cursor is the resizeLeftRightCursor, click at 10:20, else click at 10:30”.

[driven]

sorry about the ruby...
I was originally looking for cursor detector code that I could call after calculating the target x,y.
As I still would need cliclick to move the mouse to trigger any cursor event, I thought it may be better if self contained...
I tried to write my thinking as a cliclick command example.
gc[:x,y,a,b,str] GET CURSOR will move the mouse to the point with the given coordinates and query cursor type given in the string. Example: “gc:12,34,-0,+5,resizeLeftRightCursor” will move the mouse to the point with x coordinate 12 and y coordinate 34 and returns true if cursor matches string, else it will move the mouse using values given in a,b and re-test. If a match is not found at any position return returns false.
AS a bonus, I think having it as part of cliclick would make it possible to avoid dragging none edges or clicking misplaced buttons when automating GUI testing.
thanks for your reply
john

[BlueM]

I wouldn’t want to add the logic part to cliclick, as the possible behaviors – and therefore command syntaxes – are endless. (For instance: someone might just want to write to STDERR and exit, if the cursor is not as expected, while somebody else might want to wait 10 seconds and check again, while a third person might want to check the cursor is one of 3 allowed types.)
However, as I wrote before, just reading and returning the cursor isn’t hard, and I think it would make sense to add it.
So, despite your “gc:” example above, I guess that would be something that could help you get the task done?

[driven]

just getting the active cursor would be very useful, and I can add my own logic in the ruby code...
I not a programer, I just write plugins for Sketchup,app to make it run better on a mac...
sometimes I was just over complicating my thoughts...

[BlueM]

As I wrote before, getting the current cursor is not difficult – well, at least theoretically …

The problem is, that as soon as I add [NSCursor currentSystemCursor] to the code, it crashes:

NSLog(@"Supported: %@", [NSCursor respondsToSelector:@selector(currentSystemCursor)] ? @"Y" : @"N");
NSCursor *cursor = [NSCursor currentSystemCursor]; // <-- Causes SIGABRT

The stack suggests that the code tries to get a graphics context (calling [NSGraphicsContext currentContext] returns nil, which is not surprising), but doesn’t get one:

* thread #1: tid = 0xbdce, 0x00007fff91c4b212 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff91c4b212 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff91ecbb24 libsystem_c.dylib`pthread_kill + 90
    frame #2: 0x00007fff91f0ff61 libsystem_c.dylib`abort + 143
    frame #3: 0x00007fff8f65e112 CoreGraphics`CGSConnectionByID + 232
    frame #4: 0x00007fff8f7b8a1c CoreGraphics`CGSGetRegisteredCursorDataSize + 50
    frame #5: 0x00007fff8c1f2d3e AppKit`+[NSCursor currentSystemCursor] + 61
  * frame #6: 0x000000010000a751 cliclick`-[PrintCursorTypeAction performActionWithData:inMode:](self=0x0000000100114e60, _cmd=0x000000010000b829, data=0x0000000100013600, mode=0) + 225 at PrintCursorTypeAction.m:56
    frame #7: 0x000000010000233e cliclick`+[ActionExecutor executeActions:inMode:waitingMilliseconds:](self=0x0000000100012fc8, _cmd=0x000000010000b7f7, actions=0x0000000100112230, mode=0, milliseconds=30) + 1230 at ActionExecutor.m:79
    frame #8: 0x0000000100001769 cliclick`main(argc=2, argv=0x00007fff5fbffa20) + 1705 at cliclick.m:132

Unfortunately, I don’t have a clue about graphics contexts and how to create one without a window. I am now adding this comment, hoping that someone out there might be able to help out with this …

[driven]

does using currentCursor have the same issue?
NSCursor *cursor = [NSCursor currentCursor];

[BlueM]

No, it hasn’t, but it doesn’t help in identifying the global cursor.