Call for tester for 1.4.0 features and fixes (5 Viewers)

[Scythe42]

So, you saying that splashscreen always still starts on your primary display regardless which type of spashscreen you use.

correct

Will find the last bit also. Not that the code is that big. Maybe something left in the Form Designer values. I have not checked these in detail. Will come back later to you. Again thanks for helping out.

 

[Holzi]

So, you saying that splashscreen always still starts on your primary display regardless which type of spashscreen you use.

correct

Does this work in MP 1.3.0?
Thought there were reports that it never worked. But I could be wrong.

 

[legnod]

So, you saying that splashscreen always still starts on your primary display regardless which type of spashscreen you use.

correct

Will find the last bit also. Not that the code is that big. Maybe something left in the Form Designer values. I have not checked these in detail. Will come back later to you. Again thanks for helping out.

No problem...the MP community have to thank you for your hard work!

So, you saying that splashscreen always still starts on your primary display regardless which type of spashscreen you use.

correct

Does this work in MP 1.3.0?
Thought there were reports that it never worked. But I could be wrong.

i have no idea if it has worked in earlier releases too . until i set up MP on my desktop system i had no usecase for that...

 

[Scythe42]

Regarding the Audio Endpoint Crash I checked MSDN a bit.

@Developers: Need some C# advise, guys.

Shouldn't adding a [System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions] help here? It would catch the STATUS_ACCESS_VIOLATION code from native audioske.dll side.

Then at least we will not crash for whatever reason in case the audio renderer is gone and the graph cannot be properly stopped/cleanedup. Don't want to change in DSShowLib to keep it as original as it is (upgrade is there for testing as well in branch since a couple of months).

But as our CleanUp() functions are mostly the same that should be an easy implementation. If nothing crashes nothing bad will happen.

 

[Scythe42]

Does this work in MP 1.3.0?
Thought there were reports that it never worked. But I could be wrong.

I think it never worked properly, too lazy to check the code in master.

But that is something I should be able to reproduce without even having a multi-display by placing the normal splash screen at a position I like. If I can place it at any position where the screen selector stuff is it, should be no problem.

Will try... Not giving up here.

 

[tourettes]

Regarding the Audio Endpoint Crash I checked MSDN a bit.

@Developers: Need some C# advise, guys.

Shouldn't adding a [System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions] help here? It would catch the STATUS_ACCESS_VIOLATION code from native audioske.dll side.

Then at least we will not crash for whatever reason in case the audio renderer is gone and the graph cannot be properly stopped/cleanedup. Don't want to change in DSShowLib to keep it as original as it is (upgrade is there for testing as well in branch since a couple of months).

But as our CleanUp() functions are mostly the same that should be an easy implementation. If nothing crashes nothing bad will happen.

I think there was some MS blog that explicitly stated that HandleProcessCorruptedStateExceptions shouldn't be ever used in production code - they can be result of some native code writing over the .NET runtime insides. Continuing program execution after such is a really bad idea since the program is already lost case and it could do even damage to system as the runtime itself could be damaged (who wants to have a read call turning into some write call? ).

 

[Scythe42]

I see, bad idea. Beside that it is .NET 4 only. We are 3.5 and would have to do it in a different way. So basically it is do not catch SEH exceptions on the native code side?

If this one is catchable at all. I mean it goes down with a wrong pointer to the audio renderer device that does not exists anymore.

Nothing that serious in the end. Just an access violation on the native code side that is not caught on the native code side. So we have to do it on the managed side.

I doubt it will corrupt the stack or anything. Different AppDomain to allow C# to bail out?

Any suggestions. I am curious about this, not only for our case but in general from a .NET perspective.

PS: I mean even a clean exist of MP with an error message would be nicer than a crash.

 

[radical]

I can confirm legnod's Report.
Fullscreen now on choosen screen.

Good work Scythe42.

 

[Scythe42]

Will do the Splashscreen tomorrow.

 

[Scythe42]

Got the Splashscreen.....

• Normal splashscreen has StartPosition = FormStartPosition.CenterScreen set. Basically that will set it always to the center of the primary screen when shown overriding our positioning.

• Fullscreen Forms is missing a "StartPosition = FormStartPosition.Manual", therefore it defaulted to WindowsDefaultLocation, which means it take the default location Windows provides (always on the primary screen per default) and only uses the size we gave it.

So, screen selector for the splash screen never worked before.

Will provide a full new build tomorrow (without the BASS rework or I have to include even more binaries not related to my work - will solve merge conflicts when we are done here)