ASLxx_StayOnTop: good idea, bad implementation

The recent version of OS4 (53.34) has introduced the ASLxx_StayOnTop tag in asl.library. Its purpose, quoted from the autodoc, is the following:

"When set to TRUE, this stops requesters being depth-arranged. Useful especially in cases where the parent window input is blocked while the requester is open, otherwise the requester may be pushed to the back of the stack of windows, and the user may be confused as to what is blocking the input."

Looks like a good idea that has the user in mind. Well, partly.

If you open a file requester with "ASLFR_StayOnTop, TRUE" and then use the requester's menu to create a new drawer, the small window for entering drawer name silently opens HIDDEN BEHIND the requester, and the user absolutely doesn't know what is going on! Try it for yourself in the latest version of CodeBench or WordNet, which both use the tag in their file requesters.

It strikes me that the betatester team let this go because such behaviour is, without any doubt, unacceptable. Well what's done is done; let's talk about how to remedy the situation and how to implement it better.

@trixie

Thanks for the heads up. I reported your findings to the ASL maintainer.

@Cyborg

Thank you! And while we're at it, could you also pass the following feature request to the ASL maintainer? I proposed it some time ago, and was told this feature would be implemented in Update 1 - but it apparently was not.

When creating a new drawer using the requester's menu, could the text "Rename_Me" be highlighted by default? You want to enter a new drawer name and will replace the text anyway, so why not make the user's life easier?

@trixie

Yeah, I noticed this in one particular app, but not in others... I feel it's of limited use to be honest, seeing as I might have a file requestor open, yet still want to do some work in another window (look up a file name for example) - if the requestor is forced on top it makes this a little more awkward...

@Daedalus

I agree absolutely. The idea was to prevent user confusion as to what is happening, why the input is blocked. I can understand the reasons for implementing the StayOnTop tag, and I originally thought it was a cool feature.

But on second thoughts: shouldn't it be the PROGRAMMER'S duty to provide enough (visual or other) clues that a requester is opened and a user input is expected? Instead of forcing a requester on top (and getting in the way) of other windows?

@trixie

Yep, I agree... It's one of the (many) things I despise about working with Windows - having a dialogue box open freezes your app, meaning you can't move, minimise or resize it, and it would be disappointing to have the same sort of "in-your-face" behaviour from AOS. I think something like changing the screen/window title to "Waiting for your input..." or something like that would suffice.

@trixie

IMO ASLxx_StayOnTop is only useful if your program's window is also set to stay on top. In that case if you didn't use ASLxx_StayOnTop the requester would open behind the window.

@salass00

Could be, but that's not what the autodoc gives as reason for introducing the new tag, or its intended use

This is fixed in the next release of asl.library. It was a feature I added very close to the release date without thinking thoroughly about possible repercussions of child requesters.

As a result, it is now fixed at the source, and will no doubt appear in the next public update.

Simon

@Rigo

Thanks for the information, Rigo! What about the drawer name highlighting (see above), is there a chance it gets into the next public release as well?