|
As your code currently stands, you can't. What you need to do is create a class that Model implements (let's call it the Model class). Now, in this Model class, you'll have your Color property, so you end up with something like the following:
public class Cars
{
public Model Model { get; set; }
public string Year { get; set; }
}
public class Model
{
public string Color { get; set; }
}Now, a couple of things to consider here. First of all, you shouldn't be using a string for the Year property - it's really a number. Secondly, you shouldn't really call your class Cars - it's describing a single car, so it should really be called Car.
|
|
|
|
|
I think you're going about it wrong.
I think the Model class should have the Year property, but not the Color property. Although the Model class could have an AvailableColors collections.
|
|
|
|
|
Hey Guys,
I want to write a C# WinForms application, which on clicking a button will go to a particular web page and input the user name and password correctly. Once this step is done, it will go to the inbox and here i want to click a button. All this needs to be done with the web page in hidden mode.
For eg, Go to mail.yahoo.com and correctly enter the user name and password. Now it should click on the "Delete" button in my inbox.
Is it possible? Any sample code is welcome.
Thanks in advance
|
|
|
|
|
Gmail offers access over it's own API[^], might be easier.
Bastard Programmer from Hell 
|
|
|
|
|
.NET 4.0
I have just finished finally figuring out how (in WinForms) to make changes to Properties in an ObservableCollection<T> fire notifications ... attaching events to ObservableCollection items, like adds, and deletes, are, of course, easily handled ... and it required a rather ugly hack to do it which involved casting an instance of an Observable<t> to the INotifyPropertyChanged interface.
Attempting to figure out if I have created a monstrosity, or if there's a better way, I have been searching CP for information on generic ObservableCollections<T>, and INotifyPropertyChanged, and just about everything that comes up is WPF or SilverLight related.
My impression is that WPF and SilverLight offer much more flexibile facilities for wiring-up property changes than WinForms, that 'INotifyPropertyChanged' is a different critter in WPF, and that one would not have the problem I encountered in WinForms in getting Property changes to raise events.
But, I would appreciate an opinion from those of you who I am sure know both WinForms and WPF well, if my impression is correct.
In the unlikely case I have discovered some useful technique for WinForms, I'll certainly publish an article on it here on CP.
thanks, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
modified on Thursday, August 11, 2011 2:23 PM
|
|
|
|
|
First question, if you're data binding, why not use a BindingList<T>? Binding to that automatically causes the collection changes to be attached to, though I think that is the case for anything which implements INotifyCollectionChanged.
If your element type (i.e. 'T') implements INotifyPropertyChanged, the data consumer will hook to it and will update its display when you fire it (for the property which you declare as notified). I have tried this at least for a DataGridView and basic one-property controls (text box, check box etc) and it works as expected. You shouldn't need to do any casting if T implements that interface.
I'm not quite sure if you're asking a question here or just providing information about your experience so replying to the post is a bit tricky!
|
|
|
|
|
Hi Bob, thanks for your response !BobJanova wrote: if you're data binding, why not use a BindingList<T>?
In this case I am not binding anything; there's no dataset in the woodpile  I will go and take a look at Binding<T> now that you've pointed that out to me. fyi: I am familiar with implementing property notifications, like for the Text in a TextBox changing without any use of a dataset, or datasource.BobJanova wrote: not quite sure if you're asking a question here or just providing information about your experience
I'm not quite sure either; I believe I am asking the question of whether the requirement, in the case of using an OC<T>, to cast an instance of it to INotifyPropertyChanged, in order to use its internally implemented property change notifications ... which I consider a very odd thing to have to do ... is worth the 'ugliness' involved.
And, I am hoping that you, or someone else here, who I am sure are at very advanced levels in .NET development, will give me some insights into what seems like a 'mystery' (to my 'naive' eyes). Perhaps, insights, based on your knowledge of how .NET has evolved. I know that OC<T> has changed library locations, and possibly some internal behavior, from .NET 3.0=>3.5=>4.0.
My intent in exploring this area is somewhat academic ... but certainly not homework (I'm nearing 68 years old) ... I am just deeply interested in understanding .NET's implementation, in WinForms, C#.
On a practical level, the ability to get a notification when a value is changed of a member of an arbitrarily typed collection, independent of binding to a datasource, seems valuable to me; I focused on OC<T> because that gives you 'out-of-the-box' notifcations when an item is added, or deleted, from the Collection<T>. It seemed natural, once I found out that OC<T> implemented property notification, to want to use that.
I did 'stumble' into finding out how to use the native property notification facility in OC<T>, but finding even a 'clue' about how to use it took pretty thorough research here, on StackOverFlow, and on MSDN. And, the way I found to actually use it, in a fairly standard scenario, I came up with on my own; didn't find a single example of that in my research (which of course doesn't mean it isn't there, somewhere on the internet).
Let me see if I can 'wrap this up:' for example, if you, or Pete O., or Shameel, or others here, said to me: 'yeah the fact that OC<T>'s INotifyPropertyChanged implementation is kind of 'sealed,' and you have to cast an instance of your collection to it to be able to use it, really is weird, probably better ... because of .?. not to use it, I'd feel enlightened, temporarily.
On the other hand, if I heard here that it might be valuable to use a technique for making an OC<T>'s property notifications available, I'd certainly at least write up a tip/trick for CP.
On the broader level, I do look forward to one-day, perhaps, having something like Property Extensions in .NET, and I understand that has been considered seriously, but is not on the .NET time-line now. I'd definitely like to be able to do some of the things that it seems WPF offers you in terms of property bindings, etc.
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
Unfortunately I'm not really that familiar with ObservableCollection, though I have used the Silverlight version (is it the same?).
If I understand you correctly, you want to get an event on the collection when a property of an element is changed (and notified through INotifyPropertyChanged on the element – T must implement INotifyPropertyChanged and fire the notification event for any method of having observer updates). The ObservableCollection explicitly implements the INotifyPropertyChanged interface, so yes, if that event is correctly fired when a member element is updated, you will need to cast the collection to hook it. I haven't tried it so I don't know if it works.
(I.e., does the event get fired in this test case, and if so are the arguments useful:
void Test(){
var c = new ObservableCollection<Notifier>();
((INotifyPropertyChanged)c).PropertyChanged += (s,e) => MessageBox.Show("Property "+e.PropertyName+" on "+s+" updated");
c.Add(new Notifier());
c[0].NotificationProperty = 42;
}
class Notifier : INotifyPropertyChanged {
public event PropertyChangedEventHandler PropertyChanged;
public int NotificationProperty {
get { return notificationProperty; }
set { notificationProperty = value; PropertyChanged(this, "NotificationProperty"); }
}
}
)
The fact that they made that interface implementation explicit and force the cast implies they probably aren't expecting you to use it in this way, but if the event is fired when properties on the elements change and that is useful to you, I don't see a problem with using it in that fashion.
|
|
|
|
|
Thanks, Bob, for your response ! I will study your code over the weekend (I'm on GMT+7).
I think the best thing for me to do here, in order to clarify what I have found, and get reactions, is to go ahead and write up a Tip/Trick demonstrating fully what I started out to do, what the problem was I encountered in trying to do it, and what the 'odd' solution was that I finally came up with.
Then if the Tip/Trick leads to great gnashing of teeth, and I am cast into outer darkness, so be it.
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
I'm not sure what effect you are trying to achieve. ObservableCollection does not raise an PropertyChanged event - it raises events from INotifyCollectionChanged. What you could do, is inherit from ObservationChanged, and override the OnChanged method - and use this to raise a PropertyChanged event.
I hope that helps.
|
|
|
|
|
According to the documentation[^], ObservableCollection also implements INotifyPropertyChanged, but explicitly (i.e. requiring a cast to hook to).
|
|
|
|
|
Hi Pete, Thanks for responding !
As Bob says, in the post just above this one, ObservableCollection<t> does implement INotifyPropertyChanged, and my whole problem here was finding the way to use facility.
I think the best thing for me to do now, as I just wrote to Bob, in order to clarify what I have found, and get reactions, is to go ahead and write up a Tip/Trick demonstrating fully what I started out to do, what the problem was I encountered in trying to do it, and what the 'odd' solution was that I finally came up with.
Then, if the Tip/Trick leads to great gnashing of teeth, and I am cast into outer darkness, so be it.
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
process = Process.Start(psi);
process.WaitForExit(executionTimeOutSecs * 1000);
if (!process.HasExited)
{
StringBuilder text = new StringBuilder();
text.AppendFormat("Having to kill {0}, executed longer than timeout value, {1} sec.", taskName,
executionTimeOutSecs);
if (logging)
{
log.writeLogFile(text.ToString());
}
log.writeEventLogWarning(text.ToString());
process.Kill();
process.WaitForExit(1000);
}
process.Close();
Here i am getting "hasexited" false my process not exited in given time how to handle this.
|
|
|
|
|
Properly format your code snippet and people may answer you
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
process = Process.Start(psi);
process.WaitForExit(executionTimeOutSecs * 1000); // convert seconds to milliseconds
if (!process.HasExited)
{
StringBuilder text = new StringBuilder();
text.AppendFormat("Having to kill {0}, executed longer than timeout value, {1} sec.", taskName,
executionTimeOutSecs);
}
process.Close();
I think this is ok here Hasexited is retur nfalse i want to avoid this
|
|
|
|
|
I said FORMAT the code snippet not REPOST it.
Read the forum guidelines, that post at the top of this list that you have ignored.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
The code which i pasted is enough to answer
see the question "How to get answer" and try to help developer
|
|
|
|
|
Don't get cocky son. If you want to help here, follow the rules.
It is your responsibility to read, understand and comply with the posting guidelines. If you do this can be a very rewarding experience for you and us.
You were asked to format the code snippet according to the guidelines. You choose to ignore it and simple repost the same thing. You get back the same effort you've given.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Read "how to answer a question" carefully and try to help
if you dont want to help keep quiet
|
|
|
|
|
If you want help from people, it's not a good idea to tell them to keep quiet. Questions in the forums are answered by volunteers, so antagonising them doesn't help - more importantly, the regulars tend to band together, so having a go at one is a poor way to get others to help you.
|
|
|
|
|
i dont like critisizing the people that is the reason i said like that
if i know the answer sure i will give i expect other people also
|
|
|
|
|
 Man, you should have posted your code in code block like below.
process = Process.Start(psi);
process.WaitForExit(executionTimeOutSecs * 1000);
if (!process.HasExited)
{
StringBuilder text = new StringBuilder();
text.AppendFormat("Having to kill {0}, executed longer than timeout value, {1} sec.", taskName,
executionTimeOutSecs);
if (logging)
{
log.writeLogFile(text.ToString());
}
log.writeEventLogWarning(text.ToString());
process.Kill();
process.WaitForExit(1000);
}
process.Close();
But you posted the same un-formatted code in new message which is ugly one & against the rule. BTW He suggested you the same in his message like what I did now.
|
|
|
|
|
sorry really i dont know how to do all these things just i got the problem i posted
|
|
|
|
|
pprasanthk wrote: Here i am getting "hasexited" false my process not exited in given time how to
handle this
Depends on what you need.
You can wait longer or kill the process.
|
|
|
|
|
Exactly but client is doing process.kill in process.hasexited condition
is there any way to wait for exit other than calling oveloaded of process.waitforexit()
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
