|
If, by this, you mean can you create a Kiosk using C# then yes you can. Microsoft even publish a sample[^] to show you how to do this.
This space for rent
|
|
|
|
|
|
|
I'll look forward to March's instalment then.
|
|
|
|
|
I understand this code: [^]
class Base
{
public static void F() {}
}
class Derived: Base
{
new private static void F() {}
}
class MoreDerived: Derived
{
static void G() { F(); }
}And, I can follow MS's explanation:
"In the example above, the declaration of F in Derived hides the F that was inherited from Base, but since the new F in Derived has private access, its scope does not extend to MoreDerived. Thus, the call F() in MoreDerived.G is valid and will invoke Base.F." 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. And, I am curious about that ... note that my working assumption is that the creators of C# are (infinitely) smarter than I'll ever be, and had good reasons to make the design decisions they did.
While I think the right way to achieve method "hiding" in the context of inheritance is using Interfaces, I also have (as some QA posters express it) "a doubt" about that.
To make this less "theoretical," let me pose a scenario where you have a class where the constructor has a boolean flag; and, you have methods in the class some of which you would like to be unavailable depending on the value of the boolean flag:
public class SomeClass
{
private bool HideThis;
public SomeClass(int someInt, bool hideThis = false)
{
HideThis = hideThis;
HideThat = hideThat;
}
public void Method1(int someint)
{
if(HideThis) return;
}
}An obvious strategy is just to use a flag to skip executing code in a Method (as shown above). But, what would be interesting is some code where the constructor of the Class is, somehow, a "factory" and returns a class with/without a given method depending on the boolean flag.
While I am sure you could use reflection and compiler services, to generate classes on-the-fly, I would not want to use that unless that was absolutely required for other reasons. And, using System.Dynamic is another route I avoid. I am also aware of using the "Obsolete" attribute to make methods non-browsable; and, that's another place I don't want to go.
The various "factory method" patterns I've seen do not seem to me be usable for this type of scenario ... unless you are willing to do specific casting of the whatever new "object" is returned from the factory to a specific Interface.
thoughts ?
«In art as in science there is no delight without the detail ... Let me repeat that unless these are thoroughly understood and remembered, all “general ideas” (so easily acquired, so profitably resold) must necessarily remain but worn passports allowing their bearers short cuts from one area of ignorance to another.» Vladimir Nabokov, commentary on translation of “Eugene Onegin.”
|
|
|
|
|
Similar example as your found in the IDbConnection-classes; simplified, there's a property that shows the connection-state. Calling a method when using the wrong state will result in an exception offcourse.
..but yes, pass the boolean as a parameter and you can create a factory that returns either a class with five or one with seven members - but please don't abuse the constructor for that. Your construction-method is no longer part of the class being created.
Having seen the questions on CP on how to hide a proprerty from the UserControl-class, I still fail to see the value of hiding a public class-member. Simply make it private if you don't want it.
Make it private in the base, and implement it only on one of the inherited classes; that's not exactly hiding, that is simply not providing a method when it is not needed.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
