Flashing Cursor Position

[dilwyn]

To save me reinventing the wheel, anyone know how to detect the absolute co-ordinates of the flashing cursor on the screen?

I presume I need to find the current job then its cursor position added to the window origin, but I'm blowed if I can remember how.

(Needed for a small utility program I'm writing for someone).

Dilwyn

[tofro]

Dilwyn,
the cursor position (relative in the window in character coordinates) is in $22 and $24.w of the channel definition block of the channel owning the keyboard.
Note the "current job" isn't necessarily the one that owns the keyboard, but typically yours....
You can pick one job in front, find it's channels, find out which ones are consoles and find the cursor position. Without the pointer environment (here you can find the topmost primary window by searching through the window pile), I don't see an easy method to find the job owning the cursor.

Tobias

[EmmBee]

Hi Dilwyn and Tobias,

I believe the current queue is recorded in the long word at SYS_VARS+76, and the address of the window’s base is 104 bytes back. So that base = PEEK_L(SYS_VARS+76)-104. From there, the cursor position on the screen can be found with

curs_x = PEEK_W(base+$18) + PEEK_W(base+$22)
curs_y = PEEK_W(base+$1A) + PEEK_W(base+$24)

You might also be interested in the size of the cursor ...

curs_width = PEEK_W(base+$26)
curs_height= PEEK_W(base+$28)

The above seems to work for me on the simple systems I use, perhaps you can correct me if I’m wrong.

By the way, Dilwyn, that’s a highly interesting ALCHP odd address bug you have. Have you managed to find out the reason, yet? I would love to know what has caused this. Could you possibly provide an example of this bug? – or are you still trying to solve this problem?

Kind regards,

Michael

[dilwyn]

Hi Dilwyn and Tobias,

I believe the current queue is recorded in the long word at SYS_VARS+76, and the address of the window’s base is 104 bytes back. So that base = PEEK_L(SYS_VARS+76)-104. From there, the cursor position on the screen can be found with

curs_x = PEEK_W(base+$18) + PEEK_W(base+$22)
curs_y = PEEK_W(base+$1A) + PEEK_W(base+$24)

You might also be interested in the size of the cursor ...

curs_width = PEEK_W(base+$26)
curs_height= PEEK_W(base+$28)

The above seems to work for me on the simple systems I use, perhaps you can correct me if I’m wrong.

By the way, Dilwyn, that’s a highly interesting ALCHP odd address bug you have. Have you managed to find out the reason, yet? I would love to know what has caused this. Could you possibly provide an example of this bug? – or are you still trying to solve this problem?

Kind regards,

Michael

The method only seems to work without pointer environment, probably because the channel definition block varies in length on modern systems. It doesn't work on QPC2 anyway, not looked into why at all, not had time this weekend (where does time go on days off???)

The program being written is a screen magnifier for those with restricted eyesight who find CSIZE 0,0 text on modern high resolution QL screens on PCs hard to read. Written in response to a request from a user. The pointer version worked first time and works well, but it would be nice to detect when text is being written and the magnifier to follow the flashing cursor position. So the routine has to work on a system with high resolution and pointer environment (even if the user has to click on Text/Pointer in the magnifier to choose which way it works).

It's easy enough finding the current keyboard queue but not so easy reliably working back to the screen definitions for the screen channels associated with the keyboard queue.

Once I've done a config block for the Magnifier, I'll put it on my website in case it proves useful for anyone else, plus it'll give you an idea of how and why I want to do this.

ALCHP odd address: don't think it's a bug since it only seems to happen with Q-Dock and when using compressed bitmapped sprites converted with Marcel's PNGconv but I am not sufficiently sure of the source of the problem to pester Marcel about it since I'm 99% sure it'll be something in my code or misinterpreting the sprite RLE compression mechanism.

[dilwyn]

Actually, I was only half right in my answer, I did find a way of getting it to work on my QPC2.

Not quite sure what I did wrong first time, but with a little tweak to check window origin and limits it works well enough for my program, so thanks Michael. I still have the issue of working out whether the cursor is actually active in a window, and this won't work in the Psion programs due to the fact there is no flashing cursor following text. Something else to look into - I also need to check if the cursor is active and flashing as sometimes backing up from the queue leads me into a channel with a cursor but not flashing, or the Psion programs where if there is a cursor at all it is just flashing in the top left of the corner, so the keyboard focus is not followed int he way I'd like. However, thanks to Michael, I'm getting somewhere now.

The tech documents do warn that the channel block length can change in the future. Pointer environment introduces negative offsets and so luckily addressing back from the key queue to the start of the screen definition block at offset $18 just happens to work unless the block length changes in some future OS update.

[tofro]

Dilwyn,
maybe the following sentence on IO.PEND from the Technical Manual can help here:

This trap is used to check for pending input on a channel. It does not read
any data or modify the input channel in any way. This only works on the
console device if D3=0 and the keyboard queue is already connected to the
console.

This implies that if you use this trap on a channel that is not connected to the keyboard queue it will come back with an error.

Tobias

[dilwyn]

Dilwyn,
maybe the following sentence on IO.PEND from the Technical Manual can help here:

This trap is used to check for pending input on a channel. It does not read
any data or modify the input channel in any way. This only works on the
console device if D3=0 and the keyboard queue is already connected to the
console.

This implies that if you use this trap on a channel that is not connected to the keyboard queue it will come back with an error.

Tobias

Ah, that looks promising, I'll have a look at that when I get home.

All I needed was to check that the cursor is actually flashing or some other way to prevent drawing around a non-existent cursor (somewhat unpredicatle results occur)

[EmmBee]

All I needed was to check that the cursor is actually flashing or some other way to prevent drawing around a non-existent cursor (somewhat unpredicatle results occur)

To find out whether the cursor is flashing or not, you need to examine the byte at base+$43. This will be zero if there is no cursor, a one if the cursor is flashing on and 255 if it is flashing off.

This sounds like an interesting project. I wish you the best with it.

Michael

[dilwyn]

All I needed was to check that the cursor is actually flashing or some other way to prevent drawing around a non-existent cursor (somewhat unpredicatle results occur)

To find out whether the cursor is flashing or not, you need to examine the byte at base+$43. This will be zero if there is no cursor, a one if the cursor is flashing on and 255 if it is flashing off.

This sounds like an interesting project. I wish you the best with it.

Michael

Thanks again Michael. I'll see if I can use that, looks useful, especially as I'd thought from the QL Technical manual it was only 0=suppressed >0 = visible, hadn't realised there was another option.

Magnifier is up and running now, currently debugging and trying to speed it up a little.

[dilwyn]

The magnifier is up and running and I'm still tidying up the code a bit. Here's a screen dump to give you an idea what it looks like and what it does. Here' it's magnifying where I'm editing its own source code.

magnify.jpg

I hope it proves useful for those with restricted eyesight or who may occasionally need a magnified view of part of the screen when using small QL text on modern high resolution screens.

Facilities:

• follow pointer or text cursor
  magnify from x2 to x8
  move - place it where you want on screen
  resize - change size of magnified area
  works in mode 4, mode 16, mode 32 and mode 33
  minimal or full display (full display shown above)
  uses system palette colour themes

To be done: redesign top menu to have larger text (seems pointless having a magnifier with small menu text), config block, finish instructions.

I need a hand with the name - I knew Windoze had a facility like this (it was where I got the idea from) but I forgot it was also called Magnifier. So I need a new name before M$ moan