Beta 11f multiple monitor bug
During the process of providing John some screen shots of multiple monitor setups I think I may have found a new bug. At one time it was possible to run multiple copies of the same beta. Jim fixed that but... trying to run a second instance now... creates problems.
In full screen mode there is no problem as it is impossible to start a second application. But in a windowed mode.. an attempt at starting the second instance brings up the splash screen on the second monitor and can only be removed by stopping the original instance. The splash screen occasionally is a segmented full screen display but the display settings do not seem to directly influence it and at other times it is just a black screen. Right clicking on that second monitor brings up an option to go full screen which seems to work |
Are you clicking on the same icon or filename to start the second instance?
|
The best solution, (assuming it's simple to implement! ;)), might be to prevent any second window instance, if a window is already running?
I can partly confirm Ralph's experience. (Though I didn't see the splash screen). - Yes, I did click on the same desktop icon for the second instance. This is not common only to 11f. The same also applies to the official 10d. - Exiting closes both instances. |
Quote:
|
All versions of Marine Aquarium have used a technique called a Mutex, which is SUPPOSED to prevent a copy of the program from starting if another is already running. Somehow, you guys are able to get around this, but in looking through (Edgar's) code, I don't see how. The reason I asked if the same icon was being used to start the program is that the Mutex uses the internal name of the program to see if it's the same one that's already running. Previous versions, Beta versions, etc. have different internal names, so they would not be prevented from starting.
|
Quote:
Is it possible that this Mutex doesn't work with .scr files? Perhaps depending on the version of Windows being used? |
It definitely works here. Putting in breakpoints in my debugger, I can watch as a new instance finds an old instance running and shuts down.
|
From yesterdays observations.. it seems that the second instance is related to the settings in the display panel. Where there are instructions to use or not use the second monitor, the second instance (possibly the same instance but asked to do it over??) finds these instructions confusing and thus the various displays I noted yesterday. From showing the splash screen to a black screen to segments of my wallpaper showing through a black screen.
|
Ralph; what version of Windows (I'm told that Mutex works slightly differently in Windows 7).
Quote:
That's not the "intended use" of Mutex (detecting when a program should kill itself). When it works, it works fine - but Mutex implementation can change when operating systems change, and also the "right" way for a program to commit suicide may be different between operating systems. Of course, I'm making some really broad assumptions about how this is coded. In particular, I'm assuming that it's the responsibility of the "2nd copy" to detect the "problem" and commit suicide. |
My system is running Windows XP SP3
|
My belief is that this second-instance problem only occurs where there is a secondary monitor present. It isn't possible for me to completely simulate only having one monitor because MA3 still thinks that there are two screens, due to Windows seeing a Dual DVI-out Video card and therefore MA3 still shows two Monitor tabs in the MA3 Display Settings, even when one monitor connecting lead has been completely removed. And under those conditions, opting to 'Display nothing on this monitor', does not have the desired effect of simulating only having one screen.
It isn't really a problem. I'm confident that it wouldn't happen on a singe monitor setup, and why would we want to re-select the same app a second time? I say, live with it. - Put it down to the joys of having multiple-monitors! ;) - There are other more important considerations that we need to be aware of when running dual-screens..... As I've reported in the past, it should be pointed out that the FPS will drop dramatically if any part of a window is allowed to extend onto the second monitor. ie: The window must be contained within the 'Primary' monitor only, - if the expected FPS are to be maintained. Also, which monitor is to be chosen as the Primary, (and how it is chosen), is another important but thorny subject that has also been covered on a number of occasions. |
Yes, I'll probably ignore the dual-instance issue for this release. Without being able to duplicate it, anything I would try would be a complete shot in the dark. Could take weeks to track down that way, if ever.
|
Fair enough... possibly we can try to pin it down with the next release. As Cliff states this is not a big deal and one should not try to run two instances anyway.
|
Agreed! .... Don't do it, Jim.... Don't even think about it!
If you try to cover the setup of Dual-Monitors to include all situations of Widows OS, different video cards, different driver settings, different screen sizes/resolutions, and the multitude of different settings in different places..... You will not only open-up a very large can of worms, - but you will probably get the mother of all headaches! |
I agree as well.
MA appears to work in some manner on most, if not all, multi- monitor systems. If one has such a system, enjoy it as best as you can. Although, a "very large can of worms" might feed our fish for a long time! :) |
In my programming experience, I checked to see if another program was running on the computer with the same internal program name. Never heard of a Mutex.
|
Quote:
Assume there is a critical resource (serially-reusable but non-reentrant) that is needed by two or more programs. Those programs do not need to be doing the same tasks, and do not need to have the same program name - they just need exclusive use of the resource for a while. Each of the several programs will get access to the critical resource by issuing a Mutex. The effect is like each program asked the system: "Please give me access to this resource, and if you can't do that right now, then put me in a queue (in request order with everybody else who wants that resource), and suspend my execution until I can have that resource. Mutex is not normally/generally/usually used in the way MA3 is apparently using it: "Give me that resource right now, or I intend to commit suicide". Footnote: Not that it makes any difference, but it's also not clear what "resource" MA3 is looking at. |
In this case, the Mutex IS the resource. MA3 attempts to create a Mutex called Marine Aquarium 3. If the call fails because one already exists, the program exits.
|
Quote:
Thanks for the clarification. |
Using a Mutex is a very common way to prevent a second instance of a program from opening.
|
2 Attachment(s)
Testing a bit more with the current beta running in window mode. For what it is worth.... and not worth fixing, one could even argue showing the splash screen on the second monitor is a feature:D
When display setting for the second monitor is set to "display screen saver on this monitor" clicking on the same icon to start a second instance brings up screen capture 1. But, when this is done the second and subsequent times without rebooting, on the first occurrence one gets the MA splash screen. When the display settings are set to "show nothing on this monitor" one gets screen capture 2 (the splash screen). The second instance is also the active window. In full screen mode the results are what one would expect, as in when "show nothing on this monitor" is selected one gets a black second screen. |
Nothing I can do until I can set up a system to see this occur when the debugger is running. That won't be happening for a while.
|
Quote:
Sorry for the above, but my MSCS degree and 45+ years of experience in the IT field both say that it "inhales briskly". And it clearly doesn't work (sometimes) in this application. Many things that are "very common" in some circles, are not necessarily "recommended". Having said that: Quote:
Besides, you didn't write that code. And it works almost all of the time. I quite agree that it should be on something like Page 179 of the "fix it" list - if it's on any list at all. |
If you do a Bing sesarch for 'Mutex "second instance"', you will see about 6000 results, nearly all of which recommend using it to prevent a second instance of a program from coming up.
|
Quote:
If I do a Bing search for 'Mutex "second instance" deprecated' I get 1,660 results. OK, let's exclude the word "Mutex" from the search: If I do a Bing search for '"second instance" -(mutex)', I get 63,700,000 results. If I limit further - say 'windows application framework properties "second instance" -(mutex)', I get 17,800 results. All of my above searches "prove" nothing at all, except that we should not be arguing about this. |
So stop.
|
It's been done this way for 9 years with few problems.
If you have a suggested code example on how to do it better, submit it. Otherwise, move on please. |
Quote:
Technology, available programming tools, and versions of operating systems have changed substantially in 9 years. I understand why the current code works with a few problems, and I'm moving on. |
All times are GMT -6. The time now is 10:30 PM. |
Powered by vBulletin®
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.