https://github.com/ivan-the-terrible/bloodsugar-cursor

A cool way to update your cursor to reflect your blood sugar values.
https://github.com/ivan-the-terrible/bloodsugar-cursor

autohotkey cursor powershell type1diabetes

Last synced: 12 months ago
JSON representation

A cool way to update your cursor to reflect your blood sugar values.

• Host: GitHub
• URL: https://github.com/ivan-the-terrible/bloodsugar-cursor
• Owner: ivan-the-terrible
• License: mit
• Created: 2024-08-12T22:59:06.000Z (almost 2 years ago)
• Default Branch: main
• Last Pushed: 2024-09-26T22:04:28.000Z (almost 2 years ago)
• Last Synced: 2024-10-20T04:41:55.351Z (over 1 year ago)
• Topics: autohotkey, cursor, powershell, type1diabetes
• Language: PowerShell
• Homepage:
• Size: 332 KB
• Stars: 3
• Watchers: 1
• Forks: 2
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

          
# bloodsugar-cursor

A cool way to update your cursor to reflect your blood sugar values.

The main idea here is to poll against your Nightscout API every 5 minutes and update the color of your mouse cursor to help indicate your current level.

For right now, the colors are:

- green = in range

- yellow = high

- red = low

Included are the cursor files that will be loaded based on this status.

You can run this via AutoHotkey and PowerShell for right now, and is very Windows centric.

A known issue is how the cursor is rendered when running the PowerShell script. It's currently quite blurry and there seems to be a need to activate something to kick in better rendering. AutoHotkey doesn't have this problem.

I HIGHLY recommend using this with AutoHotkey since PowerShell has so many issues (from the blurry cursor to the inability to have a decent Cron job implementation).

## Technical Details

Windows has certain APIs available to update the cursor. Mainly, `LoadCursorFromFile` and `SetSystemCursor` are leveraged.

Each value below is a DWORD value, which identifies a cursor.

- 32512 = NORMAL

- 32513 = IBEAM

- 32514 = WAIT

- 32515 = CROSS

- 32516 = UP

- 32631 = PEN

- 32642 = SIZENWSE

- 32643 = SIZENESW

- 32644 = SIZEWE

- 32645 = SIZENS

- 32646 = SIZEALL

- 32648 = NO

- 32649 = HAND

- 32650 = APPSTARTING

- 32651 = HELP

- 32671 = PIN

- 32672 = PERSON

### Registry Keys

Within the Registry Editor, a couple places control mouse/cursor settings:

- Computer/HKEY_CURRENT_USER

  - Control Panel

    - Cursors

    - Mouse

  - Software/Microsoft/Accessibility

You can see values corresponding to some defaults, which seem to be linked to the

accessibility settings.

"Cursor Size" in Settings/Accessibility/Mouse pointer and touch is linked to

Control Panel/Cursors -> CursorBaseSize in the Registry:

3 = 64

4 = 80

"Mouse pointer speed" in Settings/Bluetooth & devices/Mouse is linked to

Control Panel/Mouse -> MouseSensitivity. The values are equivalent.

And finally "Mouse pointer style" in Settings/Accessibility/Mouse pointer and touch is linked to

Software/Microsoft/Accessibility

There are four registry keys here:

- CursorColor

- CursorSize

- CursorType

- TextScaleFactor

The color can be seen to change from:

Green = 12582656 (0x00bfff00)

Yellow = 64250      (0x0000fafa)

Back at the Control Panel/Cursors entries, the file path for Arrow is this string:

"C:\\Users\\[YOUR_USERNAME]\\AppData\\Local\\Microsoft\\Windows\\Cursors\\arrow_eoa.cur"

Going to that directory, we can find these cursor files. If we change the color in Settings now, we can see these files get updated.

### AutoHotkey

This topic helped tremendously in doing this in AutoHotkey (v1):

No major changes to the logic, other than updating the script to v2 syntax.

### PowerShell

The PowerShell script is written in a way that is to be leveraged by Task Scheduler.

This doesn't really work well with Task Scheduler because of this issue: .

The stupid PowerShell window keeps appearing and causing whatever window I'm on to lose focus.

The DLL is also called in a little bit of an odd way...

The above reference shows how you can leverage the `Add-Type` utility to add a Microsoft .NET class to a PowerShell session.

Since .NET can make the DLL call, we have this nested logic of a DLL call within a .NET string defined within PowerShell. Yikes.

It's probably worth it to create an actual .NET solution for this instead of scripting it through PowerShell. So much for a PoC for PowerShell.