Re: Mutex.ReleaseMutex() asynchronous ? - C# Discussion Boards

led mike10-Oct-07 4:45

10-Oct-07 4:45

Zilo(svk) wrote:
this fails from time to time

Yes it would. The code in the main() method does not reflect the desired behavior as you described it in your original post. This would also be known as "a bug".

Stevo Z10-Oct-07 5:24

10-Oct-07 5:24

Can you be more specific ?

looks like I'll use your solution.

Anyway thank you very much!!!

led mike10-Oct-07 5:58

10-Oct-07 5:58

Zilo(svk) wrote:
looks like I'll use your solution.

Oh dear, that's why I don't normally post code. You should only use your solution. This requires your doing the work to understand what you are doing.

Zilo(svk) wrote:
Can you be more specific ?

Yes, here is what you said:

Zilo(svk) wrote:
I have an application and I want to keep only one instance running

The code in your main() method cannot possibly do that since you release the Mutex at the start of the application rather than right before it ends.

Also:

Zilo(svk) wrote:
I have an application and I want to keep only one instance running

Restarting the application from itself just doesn't make any sense. If you want an instance running and you already have an instance running then you have already satisfied that requirement so no action needs to be taken.

Stevo Z10-Oct-07 8:36

10-Oct-07 8:36

led mike wrote:
Oh dear, that's why I don't normally post code. You should only use your solution. This requires your doing the work to understand what you are doing.

I never use code only by copying it, that's not the way I work. I always try to understand it. That, of course, doesn't mean that I'm going to dig for every method I see in MSDN just to be 110% sure, that's a waste of time. I was satisfied with explanation in article where my code comes from, maybe I missed something ?!

led mike wrote:
The code in your main() method cannot possibly do that since you release the Mutex at the start of the application rather than right before it ends.

I release Mutex after all work is done, that means main application form and all application resources are disposed (which was not in that example to keep it simple), as I wrote in first post. After Mutex is released I can restart application in certain case (not always of course). Obviously I cannot run restarting sequence before Mutex is released.

led mike wrote:
Restarting the application from itself just doesn't make any sense. If you want an instance running and you already have an instance running then you have already satisfied that requirement so no action needs to be taken.

Restarting application makes exactly same sense as restarting windows for instance. When application starts, certain key resources are loaded, that may not be refreshed/reloaded while application runs (for simplicity reasons). I need to keep only one instance because using(modifying) those key resources by two application instances at one time would cause possible errors...

led mike10-Oct-07 8:51

10-Oct-07 8:51

Zilo(svk) wrote:
that may not be refreshed/reloaded while application runs (for simplicity reasons)

What simplicity? You are now complicating the application with this restart scenario to avoid complicating it? You can't have your cake and eat it too. I highly recommend you abandon this hack and solve the problem of refreshing those resources you mentioned.

Stevo Z10-Oct-07 9:32

10-Oct-07 9:32

Application restart is small price for implementing refreshing scenario. Believe me. I'm not talking about some simple application. Restarts are not meant to occur every day, they are rather occasional, when significant changes are made (adding new sub-applications, refreshing licenses and objects bound to them, etc...)

However, it looks that you're not willing to bless my mind with a reason why it doesn't work my way Smile | :)

)

...though, it's been nice talking to you. What do you do ?

led mike10-Oct-07 10:13

10-Oct-07 10:13

Zilo(svk) wrote:
However, it looks that you're not willing to bless my mind with a reason why it doesn't work my way

At this point I don't think I have ever understood what you have said. When I run your code it behaves exactly as I expect it would. My code behaves differently because it is different.

In both cases the usage of the Mutex to verify single instance status works correctly, it is the remainder of the code that is different. Your code correctly identifies that it is a second instance but then continues to launch another instance prior to exiting. My code correctly identifies that it is a second instance and exits directly without launching another instance.

Stevo Z10-Oct-07 10:45

10-Oct-07 10:45

I disagree

Lets talk in steps :

Assuming:
Mutex is identified by unique name, which only my app knows and uses.
If I dont get Mutex ownership immediately, I don't wait for it (Mutex.WaitOne()), that means I don't have anything to Release.

1. Very first app launch, try to get ownership of Mutex, receives it because Mutex is not owned by any other processes.
2. Do whatever app does.
3. Release Mutex ownership. At this point, there should be no Mutex ownership.
4. Restart app.
5. Starting second app instance. If Mutex was previously released correctly and no other same app's are running (the first one may be still running but Mutex was released), I should receive Mutex ownership same way I received it first time. But for some reason, there is still ownership pending from first Launch sometimes. That's my problem.
6. If has ownership -> Step 2. Else -> Let user know that there cannot be more app instances.
7. If has ownership -> Step 3. Else -> Finishing without releasing ownership (which I don't posses).
8. Restart etc...

led mike10-Oct-07 11:03

10-Oct-07 11:03

Zilo(svk) wrote:
I disagree

With what?

In your app step #4 Restart app, always occurs without regard to the Mutex condition.

In my app step #4 Restart is dependent on the Mutex condition.

Stevo Z10-Oct-07 11:14

10-Oct-07 11:14

My problem is not that I'm restarting application when mutex is not owned!!! Besides that can never happens in real...

My problem is that I'm not able to (always) own mutex in the second application launch (restart) after it was properly released in first one!!!

That application is not about restarting all the time!!!! But sometimes, when it happens, it may fail for a reason a cannot understand!

led mike10-Oct-07 11:36

10-Oct-07 11:36

Zilo(svk) wrote:
My problem is that I'm not able to (always) own mutex in the second application launch (restart) after it was properly released in first one!!!

As I stated previously I cannot reproduce that behavior. Not with my code or yours.

Stevo Z10-Oct-07 11:44

10-Oct-07 11:44

hmm..

I can, at least on computer at work. I run exactly that code and it failed.

Let me try at home...

Edit:

I couldn't reproduce that at home either. That's not funny at all....

Dave Kreskowiak10-Oct-07 14:05

Dave Kreskowiak

10-Oct-07 14:05

If you can't reliably reproduce the functionality if the code, what does that tell you about the quality of your solution?

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007

Stevo Z10-Oct-07 20:25

10-Oct-07 20:25

u are killing me...

look

I have relatively simple piece of code, that should work perfectly without any problems. It's not something sophisticated. But then, I find out that it's not working so perfectly without any problems, so I try to find out why it doesn't ??? According to all information about Mutex (I read MSDN in the meanwhile) it should work the way I wrote it. So now my question is why it doesn't ? Possibly I might miss some important piece of information... or I don't know why it doesn't work. Maybe my computer at work just got crazy. Anyway, what does that tell about the quality of my solution? I tired of this all...

zilo

Stevo Z10-Oct-07 22:01

10-Oct-07 22:01

Guys,

Mutex.Close() (in Disposing sequence)

that's it. That's my missing piece of information.

now, I can RIP Smile | :)

)

Looks like that on faster CPU's, GC or some other mechanism took care about it(Releasing mutex completely) always before instantiating new app, what my slower CPU at work didn't manage always.

I'm just curious. Did you know it all the time?

zilo

Web browser control (Print() functionality) - Printing in landscape from code

Dave Kreskowiak11-Oct-07 1:56

Dave Kreskowiak

11-Oct-07 1:56

Nope. I never looked at your code. I read the first part of this thread, and the last part. I never knew you posted any code.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007

madhusri9-Oct-07 3:25

madhusri

9-Oct-07 3:25

Hi all,

I have developed a windows application in C#, which is going to display a report and print itt automatically without intimating the user.

The report is displayed in the web browser control using XSL in a windows forms application. I would like to know how to print the report in the landscape format? The user should not be allowed to set the page options like Portrait/landscape.

Please let me know of how this can be achieved from coding

Thanks in Advance.

Thanks and Regards
Madhu

Serializing an Interface in C#

Lucian.Palcu9-Oct-07 3:23

9-Oct-07 3:23

Hello,

I have a problem when trying to serialize the components(the components are diffrent and they are represented by an interface from that they are derived) of a list using XmlSerializer in C#. The exception message thrown when this line is executed
"XmlSerializer ser = new XmlSerializer(typeof(ISchedule))"
is "Cannot serialize interface BL.ISchedule".

I want to know if is this thing possible and should I avoid the encountered problem.

Thak you!

Lukas

mav.northwind9-Oct-07 19:31

mav.northwind

9-Oct-07 19:31

Hi!
I don't think this is possible.
Think about it: An interface cannot be instantiated. So the XmlSerializer could somehow serialize the public members that are part of the interface, but it doesn't make much sense because there's no way back. If you only have the information concerning the interface, you cannot create an object from this.

Regards,
mav

--
Black holes are the places where God divided by 0...

Lucian.Palcu9-Oct-07 21:10

9-Oct-07 21:10

Hi!

I have thought at what you told me before but I want to serialize some classes that are represented by that interface not the interface. I have this some instances of these classes in a list of interface type elements and I don't know how to serialize every element in list without taking in account its particular type only the type it is derived from. Is this thing possible?
Thank you!

Regards,
Lukas

TJoe10-Oct-07 5:32

TJoe

10-Oct-07 5:32

When serializing, there is always one root object (which is associated with the root node in the xml). I'm assuming you have an object (say MainClass) that has a collection of sub-objects (say in a property called Items). The Items is a collection of objects that implement an interface (say IMyInterface). Is this correct?

Take care,
Tom

-----------------------------------------------
Check out my blog at http://tjoe.wordpress.com

Lucian.Palcu10-Oct-07 5:40

10-Oct-07 5:40

Hi, Tom!

All what you have supposed is true. Help me,please, if you know the solution for this problem.

Thanks,
Lukas

TJoe10-Oct-07 5:56

TJoe

10-Oct-07 5:56

If you have a set number of classes, then you can specify these classes that can appear in the Items collection, like so:

using System;
using System.Collections.Generic;
using System.Xml.Serialization;
  
// ... namespace not shown
  
public class MainClass {
    private List<IMyInterface> items = new List<IMyInterface>();
  
    [XmlArrayItem(typeof(MySubClass1))]
    [XmlArrayItem(typeof(MySubClass2))]
    [XmlArrayItem(typeof(MySubClass3))]
    public List<IMyInterface> Items {
        get {
            return this.items;
        }
        set {
            this.items = value;
        }
    }
}

If you have a variable number of items, then instead of using XmlArrayItemAttribute, you can specify the class types using this[^] XmlSerializer constructor. Keep in mind that if you use this constructor, that a new assembly (.dll) is created, saved to disk, and loaded into your application's memory every time you call it (see this[^] for more info).

In either case, you will need to know all the class types that will be in the Items property.

Take care,
Tom

-----------------------------------------------
Check out my blog at http://tjoe.wordpress.com

Lucian.Palcu10-Oct-07 6:05