texteditor.gadget questions

With window class windows you need to add a idcmphook, WINDOW_IDCMPHook or similar (away from any amiga to check) search window class auto doc.

You might need to set the gadgets ICA_TARGET to the window, check includes for correct values, should be obvious

@broadblues
Quote:

Not sure if it all that obvious, but while i got it, still will share some info as maybe someday someone else will search amigans.net for that info.

So, i was told today by Dan that we do have actually 2 methods of using ICA_*. After some digging and testing that indeed few ways : One is just when you create a map, like:



and then:




This way winObj have no needs to have any IDCMP_IDCMPUPDATE/WINDOW_IDCMPHook/etc flags, and it works as OM_UPDATE.


Then, another way is like you say : creating an IDCMPHook, via adding to main window object like:



And then while our main loop is still reaction based with != WMHI_LASTMSG, we in the hook do:




Surely first way give not much control , just an information, but maybe that also enough ?

@kas1e

Not sure what you are trying to do, but if it's just connecting a vertical scroller to a texteditor you can just do:



and the text editor class will handle updating the scroller as necessary, as well as setting ICA_TARGET and ICA_MAP so that it gets updates from the scroller when it's moved.

@salas00
Turns out that was it :) Went through custom scrollbar logic, ICA_* attributes, and hook setup — only to realize it all boiled down to a single string of code..

@all
Any ideas on properly loading large binary files (more than 100mb) into texteditor.gadget? Issue is that null bytes (0x00) get treated as string terminators, so content gets truncated. Notepad and MultiEdit seem to handle this: they not only skip 0x00 but also appear to skip something else too, and that no isprint() from ctype.h.

I currently just skip 00 but curious how Notepad do. It's more than isprint() filtering for sure — they skip additional chars.

Also, what’s the proper way to load a file via DOS these days? I mean modern with all the things way. Currently use:

IDOS->FOpen
IDOS->GetFileSize
IDOS->Read

But maybe that all dated already..

@kas1e
Quote:Don't mix buffered and unbuffered dos.library I/O functions.
Either use IDOS->Open(), IDOS->Read() and IDOS->Close() (unbuffered, faster if you only do large reads, slow for small reads, it's similar to the POSIX low-level open(), read() and close() functions), or IDOS->FOpen(), IDOS->FRead() and IDOS->FClose() (buffered, faster for small reads, more like the C library fopen(), fread() and fclose() functions).
For your case check the IDOS->FGets() and IDOS->FReadLine() function as well, the 2nd one can read single lines like FGets() (default) or with ADO_TermChar, -1 the complete file into a single buffer.

@kas1e

Quote:

1. You probably shouldn't as it's a text editor

but

2. JUst use

@Andy
As i aware WMHI_RAWKEY are eaten up by the texteditor if it active, is there any way to still add support of my keys while editor active ? Maybe via idcmp or something ?

@All
Is anyone know about how to deal with ?

I were able to catch my own keys with active texteditor, but by some hardcore way: i installed input handler:





In which (in inputHandlerFunc() ) just catch for event->ie_Class == IECLASS_RAWKEY for keys i need : once key is pressed, i set a BOOL flag shared across with main app, and IExec->Signal(inputPort->mp_SigTask, 1L << inputPort->mp_SigBit).

In the main while loop i had of course to change my original "sigGot = IExec->Wait(sigMask | SIGBREAKF_CTRL_C);" to "sigGot = IExec->Wait(sigMask | SIGBREAKF_CTRL_C | (1L << inputPort->mp_SigBit));" , so to retrieve signal from inputPort.


And then:




The code works fine, but there are a few points to address:

1). I had to set ASOINTR_Pri higher than 50 (51 works, but 50 does not). Otherwise, the handler didn't catch any events. Initially, I thought the TextEditor.gadget's input handler was consuming all events, but then I tested a plain window without any objects, using a standard Reaction application's WM_HANDLEINPUT loop, and observed the same behavior. It seems that any priority below 51 is overridden by the WM_HANDLEINPUT loop. Regardless, I'm still unsure how safe this is for the system or what potential issues this "priority juggling" might cause if I use a priority of at least 51.

2). I'm not fond of using a BOOL "flag" for handling my key events. It feels clunky, and I think it would be cleaner to handle it through events or something like a case MYHANDLER: block with switches inside the main loop. This would make the while loop look more organized and elegant.

3). I need the handler to send signals only when my window/app is active, to avoid processing key events when another application is in focus. I'm not sure how to properly implement this, as some applications (e.g., commodities or background tasks) might also handle the same key, but I need to ensure that my general-purpose handler sends signals only to my task when my window/app is active.

@All
Fixed the usage of the BOOL flag to be an event sent by a signal. Also fixed the interrupt to only trigger for my active window. (The interrupt is, of course, global, but events are now sent to the main app only when my app's window is active.)

Tested with Capehill's Tequila: it shows no overhead at all. The app consumes resources as before, with no additional load.

However, I noticed an interesting detail: as mentioned, I had to set ANOINTR_Pri higher than 50, or the interrupt wouldn't catch anything. Thanks to Tequila, I found that input.device runs at priority 20. So why can't I go below 50 in my app? Is WM_INPUTHANDLER, which sits on top of input.device, taking an additional 30 priority levels? Or is something else happening? Initially, I thought texteditor.gadget might be taking up priority levels up to 50. But then I created a simple Reaction-based app with no objects, just the main WM_INPUTHANDLER loop, and I still couldn't set the priority below 50. So, is it likely window.class causing this? Or is something else happening?

@kas1e
Quote:Task priorities aren't related to interrupt priorities in any way.
Check with tools like Ranger, Scout, etc. which other input.device input handler interrupts are installed, there seems to be one with priority 50 eating up all input events (returning nothing instead of the original, or some modified, input events), making all input handler interrupts with a lower priority fail.

@joerg
(click open in new tab for fullsize):



So, that intuition.. Funny that commodities 53.
ps. shouldn't i fill any data , so to not be 0x000000, or that doesn't matter? I just did ASOINTR_Data, NULL, as i have no needs in data to send to handler, i only need return from which is ok with data = NULL, but just when i see 0x0000000 anywhere i fear of crashes and null pointer acceses :)

@kas1e
Quote:It's internal data for your function only, just like h_Data in Hook functions.
As long as you don't try to access it in your own code there is no problem with NULL data.