I still dont believe in an OS4 bug, despite your experiments with MUI programs. The interesting point is the following:
New for V36: this function will refuse to close the screen
if there are windows open on the screen or if there are any
outstanding screen locks (see LockPubScreen()) when
CloseScreen() is called. This avoids the almost certain crash
when a screen is closed out from under a window
This one quite clearly states, that the calling process is responsible for a senseful reaction to the case, that a public screen cannot be closed. Its easy as that.
In case of MUI (and related programs) this still doesnt take away the responsibility from MUI or the application using the MUI autoscreen features to check for a successful close of the public screen it opened.
There are still cases, where a process opening a public screen could be prevented from closing it. I.e., if a foreign process (CygnusEd in your case, this one doesnt use MUI AFAIK) holds a lock on this public screen on closing time.
Turn it as you like. Its just another application development quirk. People doesnt obey AmigaOS software development rules just to save some cleanup work.
If MUI isnt able to close the screen after the locking process frees all of its screen locks and terminates, its broken. If the OS4.x PublicScreen automatic open feature isnt able to close a (after some time) lock-free public screen it opened, its broken. If any application that opened a public screen itself isnt able to close it after the last visitor window vanished, its broken.
Let me recall this: You have to check for a successful close since V36 and you have to take measure for the negative case (i.e. waiting or give up in a Wait() loop, i.e. waiting for an Intuition message. SDK isnt very clear here, sadly).
Some day there may be a more elegant solution to this problem, I suggested some kind of "SAFE_TO_CLOSE_PUBSCR" message from Intuition, maybe some people come up with another solution.
Until that day, all applications/application layers have to check for a CloseScreen() fail and response to it accordingly. This includes a "I give up on this and I free all resources I can free" in the hardest case.
There is no need for a patch or a mere bug fix. All we need is some discipline for the clean up part of our software pieces.
Edit: Forgot to tell, that you as application developer are still free to request the user to close all possible visitor windows in the case CloseScreen() fails on a public screen your application opened. IIRC, there were some applications in ancient times which did exactly that.
@all I realised that my OWB screen was set-up in Prefs/Screens, but my SimpleMail one wasn't. Having now added it, it does appear that OS4 closes the public screen after the visiting CygnusEd is closed... however this does not happen with Ringhio.
So there appear to be two very similar bugs: 1. MUI is not handling CloseScreen() failing. 2. Ringhio is causing OS4's "Open/close screen automatically" to fail to close screens.
Still, both MUI & Ringhio are part of OS4, so it is not the fault of buggy 3rd-party programs.
EDIT: Please see post #36 and #37 for more details.
Let me recall this: You have to check for a successful close since V36 and you have to take measure for the negative case
I perfectly agree with this, so I don't know why you are writing a huge post about this. The bugs I reported have NOTHING to do with 3rd-party programs failing to handle CloseScreen() correctly.
Quote:
There is no need for a patch
Ah, perhaps you are indirectly railing against my patch. Well, as I already said: Quote:
I do NOT wish to debate the pros & cons of my CloseScreen patch in this thread, and kindly ask you to refrain from doing so. This thread is about an OS4 bug. You can create a new thread if you wish to discuss my patch... however I would prefer if you would wait for the "r2" release to be verified for public download, since this fixes a major bug.
Yeah, Ringhio seems to have some screen lock problems, but as m3x stated, this seems to be solved in the meantime.
MUI isnt really part of AmigaOS4.x, AFAIK, but it can be fixed. Good message so far
I tried to tell you and others, that CloseScreen() is working exactly as documented and expected, and that application developers should not try to do their work using lin/win developing behaviour. This means, relying on the OS to do cleanup work they (the developers) should do. Thats all.
What we should really talk about is a proper way of responding to the CloseScreen()-fail-case. As far as I see the SDK contents, there is no official procedure mentioned for giving up. For future compatibility there should be a standardized and documented procedure for handling this case, so that a possible future solution to the screen lock "freeze" will not be useless for older software.
Edit:
@ChrisH
You misinterpreted my post. I didnt argue against your patch specifically. I just stated that there is no patch needed in any case for this specific problem.
This problem results from misbehaviour of other, new, OS components (not tied to the CloseScreen() function code) or 3rd party software (that MUI still is).
I argued against the mainstream method of talking about software quirks. Did you realize that there is more and more talk about "bugs" in long term proven OS components? Public screen automatic open/close worked from the first day it was incorporated into AmigaOS, and it worked in an expected manner.
There is actually no way to close a screen a foreign process still holds a lock on, and this is absolutely correct and necessary for OS stability.
Any attempt to solve this by brute force will mess up future (and clean!) solutions.
Thats why my post was so huge... you cannot talk enough about this
What we should really talk about is a proper way of responding to the CloseScreen()-fail-case.
BUT NOT HERE. Please, I have politely asked TWICE already that this thread is only used for discussing the OS4 bug(s) that I have reported. You are spamming the thread with TOTALLY unrelated topic.
Thanks in advance.
Quote:
I tried to tell you and others, that CloseScreen() is working exactly as documented and expected
And no one in this thread has EVER disagreed, as far as I can see. (This is still off-topic though)
Well, if you see explanation of your bug report more deeply as spamming, well... ok.
But I definetly reject your "off-topic" accusation. The bug you reported was about a specific CloseScreen() pitfall, and thats what I was talking about.
2. Ringhio is causing OS4's "Open/close screen automatically" to fail to close screens.
I've done some tests with my own public screen (not using Screens prefs, which adds an extra layer of debugging)
CloseScreen() returns TRUE if the only visitor window is Ringhio, so the calling app believes the screen has closed. However, the screen hasn't closed.
I think now that this is an Intuition bug, as if the screen hasn't physically closed then there is no way CloseScreen should return that it has.
Ringhio is not at fault, although it is highly likely that the way it draws its notifications means Intuition isn't aware it is open. However, it must be locking the screen, otherwise the screen would close. The bug is that Intuition should not be reporting that it has closed a screen successfully when it hasn't.
@whose
Quote:
I tried to tell you and others, that CloseScreen() is working exactly as documented and expected
I've just proved that it isn't. Please make up, both of you
With regards to your MUI variant, I'm not sure if I'm seeing the same as you here.
I run YAM on it's own screen, and that screen is defined via MUI settings and named YAM
If I cause AWeb to open on YAM's screen then iconify YAM the screen ofcourse remains open. If I then close AWeb the YAM screen does remain open. If I then uniconify YAM it happily reoccupies it's named screen.
Like wise if I quite YAM with AWeb on the screen AWeb prevents screen closure, and the screen remain open once I quit AWeb. Restarting YAM, and YAM happily occupies the named screen.
This seems to slightly conflict with your example where SimpleMail can't open it own screen (because it's open) and defaults to the workbench.
CloseScreen() returns TRUE if the only visitor window is Ringhio, so the calling app believes the screen has closed. However, the screen hasn't closed.
I think now that this is an Intuition bug, as if the screen hasn't physically closed then there is no way CloseScreen should return that it has.
Ringhio is not at fault, although it is highly likely that the way it draws its notifications means Intuition isn't aware it is open.
You see that your argumentation has a serious flaw? If Ringhio manages to "work around" the Intuition screen locking system (which it seems to do!), its definetly Ringhio which is at fault for now
You couldnt call Intuition the bad, if you do tests involving Ringhio only. Test "normal" CloseScreen() use, means: without Ringhio intervention, and then tell us, what it returns. I bet that it works exactly as documented.
If Ringhio invents a new display locking method and Intuition for normal users cant handle this new method yet, we should wait for some OS developer (IIRC Rigo is responsible for Ringhio) to tell us more about it. Instead of yelling "bug! bug!" all the time, I mean.
Btw., I share broadblues´ feeling of Deja Vu. Some time back these Ringhio related problems with Screens were mentioned and reported already. But I dont remember yet, where it was. Maybe AW?
The MUI YAM screen can be manual closed from the screens tab in the MUI program.
It can also be manually opened.
If I open it and start AWeb with it set to uses YAMS screen AWeb will occupy that screen (defaulting to the workbench if it is not open, unlike with OS4 screens MUI does not appear to auto open screens on demand from non MUI apps)
If I then close AWeb the screen remains open.
I'm not seeing any bugs here just consistant if slightly unexpected behaviour.
MUI exhibits different behaviour for MUI apps and non MUI apps.
It has a set of screens in it's database that it manages. These screens may be manually opened or closed from the MUI program ie sys:MUI/MUI
If a screen is manually opened it will stay open til it manually closed.
If any app opens it's window on that screen it can't be closed manually till that app closes it's window.
The fact that you tried to manually close it does not mean it will auto close once the app window has closed.
An MUI app may be set to open on that screen, if the screen isn't open when that app is started or uniconified MUI will open the screen for it.
When that App closes MUI will autoclose the screen again, unless another app is using it. As far as I can tell it will only autoclose a screen for the app that autoopened it. If another app even another MUI app opens on that screen then the screen is not autoclosed when the later app quits / iconifies even if that app is set to use that screen.
Thus MUI autoclosing a screen is a one off response to the closing of the open apps window.
Am I right in thinking that this is the behaviour that ChrisH thinks is abug?
It seems like a consistant behaviour to me but a differemt behaviour to the OS4 "native" screen system.
Ringhio is not at fault, although it is highly likely that the way it draws its notifications means Intuition isn't aware it is open. However, it must be locking the screen, otherwise the screen would close. The bug is that Intuition should not be reporting that it has closed a screen successfully when it hasn't.
Not necessarily. If Ringhio is PATCHING Intuition or the underlying graphics functions, Intuition may not be getting accurate results to pass back to your program. Your test proves nothing unless we see the Ringhio code to be sure that it is not altering Intuition. I can cause failures or even crashes in a lot of system libraries by giving NULL or incorrect pointers to some functions. That doesn't necessarily mean those libraries are bugged, it just means I wrote a defective program.
if you see explanation of your bug report more deeply as spamming,
Quote:
But I definetly reject your "off-topic" accusation. The bug you reported was about a specific CloseScreen() pitfall, and thats what I was talking about.
There was absolutely NO hint of any mis-use of CloseScreen() (at least in the way you suggest) until post #22. And even then that is related to how MUI (a part of OS4) handles screens, not 3rd party programs.
This thread is about bugs in OS4, not about bugs in 3rd party programs.
(BTW, I have no objection to those parts of your (edited) post that discuss MISbehaviour of OS4 in relation to closing screens - that is the topic afterall!)
Edited by ChrisH on 2011/6/17 9:25:02 Edited by ChrisH on 2011/6/17 9:26:13
CloseScreen() returns TRUE if the only visitor window is Ringhio, so the calling app believes the screen has closed. However, the screen hasn't closed.
I think now that this is an Intuition bug, as if the screen hasn't physically closed then there is no way CloseScreen should return that it has.
Ringhio is not at fault, although it is highly likely that the way it draws its notifications means Intuition isn't aware it is open. However, it must be locking the screen, otherwise the screen would close. The bug is that Intuition should not be reporting that it has closed a screen successfully when it hasn't.
Interesting! Although this does not explain why my CloseScreen() patch fixes Ringhio's problem (since my patch only does something if CloseScreen() returns FALSE).
Your observation seems a likely explanation for my second bug, but not my first one: Quote:
1. MUI is not handling CloseScreen() failing. 2. Ringhio is causing OS4's "Open/close screen automatically" to fail to close screens.
I do not think it can explain the first one, which causes this: Quote:
If I get MUI to open a screen for SimpleMail, then tell CygnusEd to open it's window on that public screen, then close SimpleMail, then close CygnusEd... then the public screen will remain open
Note that the MUI screen must NOT be defined in Prefs/Screens (with 'Open/close screen automatically' set).
Edited by ChrisH on 2011/6/17 10:43:31 Edited by ChrisH on 2011/6/17 10:44:18 Edited by ChrisH on 2011/6/17 10:44:57
This seems to slightly conflict with your example where SimpleMail can't open it own screen (because it's open) and defaults to the workbench.
My example was slightly wrong: MUI apps are not able to re-use a (failed-closed) screen ONLY when Ringhio blocked it from closing. I wrongly assumed it was caused by all apps blocking screen closure.
This is further evidence that there are TWO bugs, with Ringhio's being entirely unrelated (although superficially similar).
Quote:
As far as I can tell it will only autoclose a screen for the app that autoopened it. If another app even another MUI app opens on that screen then the screen is not autoclosed when the later app quits / iconifies even if that app is set to use that screen.
Thus MUI autoclosing a screen is a one off response to the closing of the open apps window.
Am I right in thinking that this is the behaviour that ChrisH thinks is abug?
Yes, this appears to be the main MUI bug that I reported in post #22.
This is further evidence that there are TWO bugs, with Ringhio's being entirely unrelated (although superficially similar).
We can ignore the ringhio bug from now on as that is known, reported and fixed.
Quote:
Quote:
As far as I can tell it will only autoclose a screen for the app that autoopened it. If another app even another MUI app opens on that screen then the screen is not autoclosed when the later app quits / iconifies even if that app is set to use that screen.
Thus MUI autoclosing a screen is a one off response to the closing of the open apps window.
Am I right in thinking that this is the behaviour that ChrisH thinks is abug?
Yes, this appears to be the main MUI bug that I reported in post #22
I'm not convinced this is a bug a such, rather a slightly different way of handling screens when compared to the OS4 public screens approach.
Do you know of any documantation, that describes how MUI is expected to handle screen opening? I can't find anything in the autodocs.
I just examined the MUI screen editor more closely and there is an autoclose flag. If I set this then after the last visitor window leaves my YAM screen the screen closes as expected.
So do you have this flag set in your MUI screen prefs for your simple mail screen? If not I suggest you test with that flag set and see whether it still fails to close for you.
whose wrote: You see that your argumentation has a serious flaw? If Ringhio manages to "work around" the Intuition screen locking system (which it seems to do!), its definetly Ringhio which is at fault for now
It's irrelevant, as CloseScreen() isn't working as documented.
Quote:
You couldnt call Intuition the bad, if you do tests involving Ringhio only. Test "normal" CloseScreen() use, means: without Ringhio intervention, and then tell us, what it returns. I bet that it works exactly as documented.
Yes, it does.
Quote:
If Ringhio invents a new display locking method and Intuition for normal users cant handle this new method yet, we should wait for some OS developer (IIRC Rigo is responsible for Ringhio) to tell us more about it. Instead of yelling "bug! bug!" all the time, I mean.
If Intuition isn't closing a screen, it shouldn't be reporting that it is, regardless of what is preventing it from closing.
Anyway, broadblues says it is fixed so probably not worth discussing this further.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
