TextEditor 15.54 opens a "Inser MUI: drive" requester on i386 AROS

[paolobesser]

As the title says. If I place texteditor .mcp and .mcc in my current installation, a requester asking for MUI: drive appears several times at system startup and almost randomly when opening volumes and applications.

The issue does not occurr with texteditor 15.53 beta.

[tboeckel]

This happens due to commits 72598a7198b7413537374c3ff02c33e8cdad9949 and e75e577b81388141a9f7991dbe8188cb5c1226b0.

Before version 15.54 the clipboard process inherited NP_CurrentDir and NP_ProgramDir from the parent process. This caused the corresponding directories to be Lock()ed as long as TE.mcc remains in memory. On the other hand this also makes it impossible to delete the directory of the very first application to use TE.mcc, at least as long as TE.mcc is not flushed from memory. The solution was to set a specific directory for both NP_CurrentDir and NP_ProgramDir. I chose "MUI:", because (at least on AmigaOS) this assign always exists and Lock()ing it does have no bad impact on the directory of arbitrary applications.

It seems AROS is lacking this assign and hence you get the requesters.

Can you recommend any other assign or directory to use instead on AROS?

[tboeckel]

As a workaround until we find a valid solution for all systems, you can add something like "assign MUI: T:" to your startup-sequence. This will make the requesters vanish. It doesn't matter where exactly the assign "MUI:" points to, the path just needs to exist and the assignment must be done before the first application using TE.mcc is started.

The same applies for applications using NList or BetterString, because the classes use the same approach as TE.mcc.

[paolobesser]

Hi Thore

Thanks for your explanation. Unluckily I am no coder, so please take this suggestion with much precaution. As far as I know, the T: drawer and assign should be common for all Amigaish systems and set in RAM for temporary stuff, like NP_CurrentDir and NP_ProgramDir should be. I'd have used it instead. Also Env: seems to be a good place. So, I'd have created a MUI subdirectory in T: or in Env: for this purpose, since locking that subdir wouldn't impact - at least in theory - on other running processes. But take this with a grain of salt: maybe I just wrote a complete oddity. Maybe some AROS coder would be much more prepared than me for a proper answer.

Anyway, I though it was a TextEditor behavior only. I didn't think it was common with other MCC as well. I guess I will work around this with an

ASSIGN MUI: T: DEFER

thank you for your time and for everything you do for our community.

kind regards

Il giorno mar 8 set 2020 alle ore 07:23 Thore Böckelmann < notifications@github.com> ha scritto:

As a workaround until we find a valid solution for all systems, you can add something like "assign MUI: T:" to your startup-sequence. This will make the requesters vanish. It doesn't matter where exactly the assign "MUI:" points to, the path just needs to exist and the assignment must be done before the first application using TE.mcc is started.

The same applies for applications using NList or BetterString, because the classes use the same approach as TE.mcc.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/amiga-mui/texteditor/issues/31#issuecomment-688624956, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJZEBDLIVSRFT232VFDOH3SEW5UFANCNFSM4Q6U3IEQ .

-- p.bes Senior IT specialist, journalist, advisor

http://www.thegamesmachine.it http://www.commodore-cbm.com http://www.icarosdesktop.org https://www.linkedin.com/in/paolo-besser-05675243/