I'm trying to get CDT_GETROWS and CDT_GETCOLUMNS from the active shell window (so no new windows opened).
I've use this code but it crash in DoIO()
struct Process *me = (struct Process *) FindTask(NULL); struct MsgPort *consolePort = me->pr_ConsolePort; if (consolePort != NULL) { struct IOStdReq *writeReq = AllocSysObjectTags(ASOT_IOREQUEST, ASOIOR_Size, sizeof(struct IOStdReq), ASOIOR_ReplyPort, consolePort, TAG_END); if (writeReq != NULL) { struct TagItem tags[3]; uint32 cols, rows, xcp, ycp; printf("Setup tags\n"); tags[0].ti_Tag = CDT_GETROWS; tags[0].ti_Data = (uint32) &cols; tags[1].ti_Tag = CDT_GETCOLUMNS; tags[1].ti_Data = (uint32) &rows; tags[2].ti_Tag = TAG_END; writeReq->io_Command = CD_GETATTRS; writeReq->io_Data = tags; writeReq->io_Length = sizeof(tags); DoIO((struct IORequest *) writeReq); ...more code below..
My question is. Is it possible to use the process console's message port? Is there any other way to do this? I didn't find any great documentation how to handle the current shell console device
I'm not surprised. That's a strange way of coding it. You've taken a message port then used it in a device call without opening any device. How confusing! :-D
First, rather than read directly you can use GetConsolePort() from DOS to also grab it. Second, if I read the API correctly, it's a port for DOS packets. So you would need to send it a DOS packet. Third, SendPkt() is good for that after allocating a packet.
Looks like you could open console.device the usual way and specify the Process->pr_WindowPtr but I can't find much info that way. It's likely in some Amiga book somewhere. I read about it years ago but not so sure about interfacing it with a shell window.
Regardless, if your intention is to simplly find the matrix columns and rows it may just be easier to use a CSI sequence to do the job and read it back from stdin. Check this section about CSI. At the top is more info about using console.device directly.
https://wiki.amigaos.net/wiki/Console_Device#Cursor_Position_Report
GetConsolePort() return the same pointer. So no difference using it or using pr_ConsolePort.
Theoretically (but of course i'm not so sure about this because there is no documentation) the console.device should be already opened for that Message Port.
I'll try top open console.device using the window pointer to see if it works
However my intention is not to find current row and column (the CSI you poninted at) but Window's rows and columns and from the doc CD_GETATTRS should do the trick
However even allocating a port with ASOT_PORT and using it in ASOT_IOREQUEST, when trying to open console.device using writeReq->io_Data = (APTR)me->pr_WindowPtr; doesn't work. console.device cannot be opened
I've even tried to get the window pointer like Olsen wrote here:
https://forum.amiga.org/index.php?topic=73249.0
But no luck..
Ok. i've found a way to make it work. This is the code (updated) if anyone want to use it:
The problem is that the window console is cleared above the current line.. and i don't know why..
Yes, GetConsolePort() returns the same pointer, but it looks cleaner. :-)
Also, if there are any changes to the internals and there usually are, it's recommended to use a function than read it directly.
Looks like you figured out the quirks of console.device. That guide to the units looked over complicated. Thing like getting the window of a shell are always too complicated on AmigaOS.
You would be right, the console.device would already be opened. But it may not be using that port for device I/O and the little I found suggests it is used for DOS packets. And in programming the API it's right and proper to open it for your own use. It's wrong to use it just because it is opened, you must ask permission first. That's the design. :-)
Also, you don't need to give message ports a name. Unless they are made public. While I don't think it hurts, for private use they can remain nameless.
Regarding the CSI, I was actually thinking of the one below it, but thought it better to expand it. Pointing to the whole section may have helped better.
I'm not sure about this ACTION_UNDISK_INFO as I never heard of it until now. Things like a window can go away but it usually happens when the file handle is closed. In which case the file handle will be totally invalid as well. What if you take that packet out? Still get the screen clearing?
The funny thing is that if you resize the window the content is repainted correcty. I've sent a message to Tony to see if he can reproduce the problem
I'll test this method to see if i have the same problem. Howerver since there is a new Command in console.device why don't use it?
I didn't try. However i get the code from the example i've found on amiga.org. I didn't find any documentation how to do this. And i've also checked the window pointers (that one in Process struct and that one retrieved via DoPkt1) and they are different. And the process one returns wrong cols and rows
Even without ACTION_UNDISK_INFO i get the same effect. But i've also noticed another problem
Every time you execute this code, a Window is created (you can see it with Ranger) and on Sam440 where I have the blinking cursor i can see the blinking cursor on top-left. I've noticed also that console.device counter is increased every time and doesn't decrease on CloseDevice.
It is possible that something still opened (the window)?
Edit:
This problem was caused by a wrong sequence of freeing stuff. I was closing the device after freeing objects that of course is wrong
A different approach using escape sequences:
Any answers yet?
For one thing the overhead and extra code in using the console.device. If you need to use it for other direct access that is fine. But it's one of those Amigaisms where you need all this code to find a small piece of infomation.
OTOH, the older method just uses a file handle, and you can even grab it with Input() or Output().
What's your compile line for the code below? I almost got it but forget what define you need to avoid interfaces. And couldn't find it in the SDK PDF.
ppc-amigaos-gcc console.c -o console -D__USE_INLINE__ -lauto