|
BillWoodruff wrote: why method over-riding with 'new is defined as limited in scope in terms of inheritance
That's only in conjunction with the private modifier. If it wasn't private then the new method's scope would extend to derived classed.
Do you have a real life scenario where you think you need method hiding or "something like that"? I have yet to find one - there was always a way to design it in a way that does without method hiding. (State-dependent method availability sometimes is neccessary of course.)
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
BillWoodruff wrote: But, in terms of why method over-riding with 'new is defined as limited in scope in terms of inheritance: I can't say I understand that.
It certainly looks weird, but to me it looks like since "new" is supposed to work together with access identifiers, it should play nice with all of them. Or, simply not have access identifier, and just inherit it from the Base class' method - which now that I think of it, probably would have mad more sense  *
Having said that "it should play nice", I think the default behavior for new private is the right one - what else should it do?
* inheriting from Base method might not work either, because we can have several methods with the same name, and they each can have their own access identifier. So, it would need to inherit the one with the same signature as its own.
Best,
John
-- Log Wizard - a Log Viewer that is easy and fun to use!
|
|
|
|
|
John Torjo wrote: access identifier
Just a bit of nitpicking, since it's programming terms that have some importance: It's access modifier(s) 
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Yes, agreed 100%. My bad 
Best,
John
-- Log Wizard - a Log Viewer that is easy and fun to use!
|
|
|
|
|
My C# dll is loaded by an application. I wanted to add logging in the dll. The only question in mind is how I can make sure that only one instance of the loaded dll is writing to the log file at a given time.
I found following approaches while searching, but not 100% sure if they would help:
1. Use FileShare Enumeration: But, this might cause problem if the first process hangs and blocks the resource.
2. Use Mutex: It was recommended to not use as it doesn't help when there are multiple processes accessing the same file. It is helpful when multiple threads are accessing the same file.
Since, I can be wrong in my assumption so wanted to ask experts for some advise.
Thanks.
|
|
|
|
|
NJdotnetdev wrote: But, this might cause problem if the first process hangs and blocks the resource.
Any scheme you can come up with will struggle if a process hangs whilst holding the lock on the file.
You might want to consider using the Semantic Logging library[^] instead of your custom logging code. That way, you won't need to worry about synchronising access to the log file.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks a lot Richard for the advise. Will look in to it.
|
|
|
|
|
Depending on your requirements it may be easier for each application to provide a file or filename for the library to use as its log file.
|
|
|
|
|
Quick question: Will there be a problem if multiple instances of the same application try to write in the same flat file at the same time?
I found following text on MSDN:
You should not configure more than one Flat File sink or Rolling Flat File sink instance to write to the same physical file. However, you can enable the same listener (and sink) on multiple event sources and funnel the events from those multiple event sources to the same file.
Link: Logging events to a disk file[^]
|
|
|
|
|
|
The Microsoft Enterprise Library Enterprise Library 6 – April 2013[^] Has a block which provides a very flexible logging mechanism.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
If you want simple, don't log to a "file" in this case; log to a database.
Any decent logger will support this via configuration options.
|
|
|
|
|
NJdotnetdev wrote: The only question in mind is how I can make sure that only one instance of the
loaded dll is writing to the log file at a given time.
You can't. I can create a new AppDomain and load your dll again.
As long as the logger does what it is intended to do (log a message and uniquely identify the origin) things should work, even if loaded more than once, or, multiple versions of the same library
Imagine writing a new product. Some dev finds out how to create a mini-dump, and includes an option to send the mini-dump along with the logging. Your new product uses YourCompanyLogging2.0, the improved logger; whereas the client has a different product on his/her machine which depends on YourCompanyLogging1.0. It knows nothing of the extra filepath it is supposed to send, and would throw and ArgumentNullException if the new routine is launched.
There is a whole host of dragons ahead, and the subject you are diving into is called "DLL HEL". There is no neat solution there.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
The question here is why do you want every one of your DLL instances to write in the same log?
Why not have each instance of your DLL write to a different log? And besides, this probably makes more sense - since each app using your DLL will have its own workflow.
Best,
John
-- Log Wizard - a Log Viewer that is easy and fun to use!
|
|
|
|
|
HiEveryone,
I am automating my .net application using AutomationElement. I want write process synchronization for my framework. Is there any API which can tell us whether application is busy or not?
REegards
Raj
|
|
|
|
|
Define, in precise terms, what a "busy application" is first.
|
|
|
|
|
I have an ObservableCollection and a Property that implements INotefiedPropertyChanged so I want to find out what type the object is, basically:
if ((MyObject is INotifyCollectionChanged)&& (MyObject is INotifyCollectionChanged))
Console.WriteLine("This object implements both INotifyPropertyChanged and INotifyCollectionChanged");
if (!(MyObject is INotifyCollectionChanged) && (MyObject is INotifyCollectionChanged))
Console.WriteLine("This object implements only INotifyPropertyChanged");
And I want to use it to write something like:
public static IObservable<EventPattern<PropertyChangedEventArgs>> Observes<TSource>(this TSource MyObject) where TSource : INotifyPropertyChanged
{
return null;
}
public static IObservable<EventPattern<PropertyChangedEventArgs>> Observes<TSource>(this TSource MyObject) where TSource : INotifyCollectionChanged
{
return null;
}
This last code won't compile as the definitions are considered equal. BTW: I know I can solve the problem by naming the two methods differently, but I want it to be one simple call for both.
|
|
|
|
|
NB: You have some (copy&paste?) mistakes there:
if ((MyObject is INotifyCollectionChanged)&& (MyObject is INotifyPropertyChanged))
Console.WriteLine("This object implements both INotifyPropertyChanged and INotifyCollectionChanged");
if (!(MyObject is INotifyCollectionChanged) && (MyObject is INotifyPropertyChanged))
Console.WriteLine("This object implements only INotifyPropertyChanged");
public static IObservable<EventPattern<PropertyChangedEventArgs>> Observes<TSource>(this TSource MyObject) where TSource : INotifyPropertyChanged
{
return null;
}
public static IObservable<EventPattern<NotifyCollectionChangedEventArgs>> Observes<TSource>(this TSource MyObject) where TSource : INotifyCollectionChanged
{
return null;
}
The only way to keep the method names the same would be to have different parameter lists. But that doesn't make sense here. Just name them ObservePropertyChanged and ObserveCollectionChanged and move on 
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Well, I could also Say something in the line of
public static IObservable<T> Observes<TSource>(this TSource MyObject) where TSource : object, T: object
{
if ((MyObject is INotifyCollectionChanged)&& (MyObject is INotifyPropertyChanged))
Console.WriteLine("This object implements both INotifyPropertyChanged and INotifyCollectionChanged");
if (!(MyObject is INotifyCollectionChanged) && (MyObject is INotifyPropertyChanged))
Console.WriteLine("This object implements only INotifyPropertyChanged");
}
But then Id have the problem of converting the output to Action<t> from Action<object>. That didnt seem so simple, at least to me.
|
|
|
|
|
For a generic return type the type has to be part of the generic type arguments of the method:
public static IObservable<T> Observes<TSource, T>(this TSource MyObject) where TSource : object, T: object
So this would just move the neccessity to write a different method name to having to write a different type name.
However, if you merged the methods for creating the observable and subscribing to it into one, you wouldn't have to return the generic IObservable but just the non-generic IDisposable subscription object instead.
But: Lifting the type constraint for TSource from IPropertyChanged / INotifyCollectionChanged to Object for the sake of having one method is rather "dirty"
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Sascha Lefèvre wrote: But: Lifting the type constraint for TSource from IPropertyChanged / INotifyCollectionChanged to Object for the sake of having one method is rather "dirty"
Oh yes indeed  What I really wanted was a way to write a little more complex where clause, and I thought I might have missed something. I could write where T : INotifyPropertyChange,INotifyCollectionChanged but not a clause that said that it cound not implement some interface.
|
|
|
|
|
Kenneth Haugland wrote: I could write where T : INotifyPropertyChange,INotifyCollectionChanged but not a clause that said that it cound not implement some interface.
Yes, that's not possible.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
As it turns out, I was asking the wrong question, thus looking for solutions in the wrong place.
The trick I used was that I created a generic SubscribeWeakly, and it was this method that I really needed:
Weak events in .NET using Reactive Extensions (Rx)[^]
Yeah, question is old now, but in case other people see it they should now be able to solve it 
|
|
|
|
|
Thank you, Kenneth, I'll take a look at it
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Hi C# Developers,
Question 1:
How do I suppress Cancel button click event of Save As dialog box to make sure that my users click save button only?
Question 2:
How do I prevent users from creating New folder while Save As dialog box is open?
Question 3:
How do I prevent users from changing the current folders path while Save As dialog box is open?
Your help is much appreciated in advance
Kindest Regards
Lucky Khoza
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
