Hyperion Entertainment Message Boards

@nbache

You keep writing "except drivers", but it's not drivers, but drawers.

It was just typo, of course i mean drawers (that why there logical connection with WB windowses when drawers in meaning).

A driver is some software which drives a hardware (or virtual) device - but you probably know that.)

just reread whole topic, you will see what it all about, and that _of course_ it was just a typo, because we discuss misleading of warning when it say close all windowses, except drawers (like only wb windowses, while its not about windowses at all, but about bad done app).

So the message is (at least more) correct: You don't have to close the windows which are under Workbench's control, i.e. the drawer windows, but all other windows (which haven't already closed automatically by then) are candidates for being closed manually.

As we discuss in that topic on previous pages, problem is not closing of windowes, but found a faulty app which do not unlock screen, and that app may have no window at all.

@Whose

Ok, BZ done with all explaining, point on that thread, and with asking for change warning window on that:

Intuition is attempting to reset the Workbench screen, and can't. Probably one or more applications you run now are writen badly and need fixing. Please try to close applications one by one to found faulty one(s)

Trivial to change, but only hope is that it will be not ignored

It doesn't have to be a "faulty" or "badly" written application. There may be a reason why they keep the screen from disappearing.

Intuition is attempting to reset the Workbench screen, but one or more applications are still locking the screen. Please quit all applications before retry.

gazelle wrote:It doesn't have to be a "faulty" or "badly" written application. There may be a reason why they keep the screen from disappearing.

I can´t imagine very much reasons to keep a permant screen lock... even if there is one, the application should behave nicely and free the lock as soon as possible, when it detects the attempt to reset Workbench. Otherwise it should use an own screen...

whose wrote:I can´t imagine very much reasons to keep a permant screen lock...

I'm in the process of writing a prefs program with several "getcolor.gadget" objects.

autodocs wrote:GETCOLOR_Screen (struct Screen *)
Screen for allocation of needed pens for the display.
This MUST be provided and MUST remain open until after
the gadget has been disposed.

My prefs program would need to dispose all of the getcolor objects and then recreate them. Way to much work for a simple prefs program. I just keep the screen locked and if the user want to change the screen he would have to close the program first.

whose wrote: I can´t imagine very much reasons to keep a permant screen lock...

There is a difference between locking the screen and having a window open and not closing when Workbench attempts to change screenmodes. Leaving a window open will block the screen from closing even it there is no screen lock.

gazelle wrote:I just keep the screen locked and if the user want to change the screen he would have to close the program first.

Why would you need to keep the screen locked? If your window is open, it will prevent the screen from closing just as effectively as locking the screen.

xenic wrote:Why would you need to keep the screen locked? If your window is open, it will prevent the screen from closing just as effectively as locking the screen.

Because the window supports the iconification. Doesn't matter anymore, I found a solution and the program does now support a screen change.

kas1e wrote:@nbache

You keep writing "except drivers", but it's not drivers, but drawers.

It was just typo, of course i mean drawers (that why there logical connection with WB windowses when drawers in meaning).

Okay, I just wasn't sure from what I had read so far, so I figured it was better to make sure .

So the message is (at least more) correct: You don't have to close the windows which are under Workbench's control, i.e. the drawer windows, but all other windows (which haven't already closed automatically by then) are candidates for being closed manually.

As we discuss in that topic on previous pages, problem is not closing of windowes, but found a faulty app which do not unlock screen, and that app may have no window at all.

Right, but if the user tries to find the app which is blocking the reset, it is at least a waste of time to start closing drawer windows, as they will never be the guilty ones. This is what I understand from the message as it is worded right now. You are of course correct when you say that the guilty program may not even have an open window, but that is probably the exception, not the normal situation. Normally the user will find the blocking app by closing non-drawer windows one by one, until the reset happens.

Best regards,

Niels

gazelle wrote:Because the window supports the iconification. Doesn't matter anymore, I found a solution and the program does now support a screen change.

Nice