comboBox from enum?
in [CSharp]
|
Prev: xml and xml schema
Next: building process
From: Peter Duniho on 8 Mar 2010 00:26 DanB wrote: > Peter Duniho wrote: >> >> If you initialize the items in the ComboBox to the actual enum values >> (e.g. as in the code I posted earlier), then you can simply set the >> SelectedItem property to the enum value in question. The ComboBox class >> will handle the rest, without you having to explicitly call something >> like FindStringExact(). >> >> So, when the ComboBox is properly initialized, you get something more >> like this for the above code: >> >> comboBoxChartType1.SelectedItem = cutItem.seriesSet[pos].type; >> >> Likewise, this: >> >>> From box: >>> curItem.seriesSet[ pos ].type= (SeriesChartType)Enum.Parse( >>> typeof(SeriesChartType), comboBoxChartType.Text, true ); >> >> �becomes this: >> >> curItem.seriesSet[pos].type = >> (SeriesChartType)comboBoxChartType1.SelectedItem; > > Hi Peter, > Old habits. I would avoid storing data as an index whenever possible. > Now my 'type' would be a plain old int rather than a type with > appropriate baggage. What if there were a revision and a new name where > put in at position 3? If stored by name versioning is automatic. I can > change the order in my combo, add delete stuff without maintinance of > the database. Look again at the code I posted. It does not store the data "as an index". In fact, it doesn't change your design at all. It simply implements your design without all the extra, unnecessary code you were using before. As for your serialization problems, well�type safety, versioning, and data consistency requirements are a double-edged sword. It's true, you can write your own serialization that doesn't impose the same requirements on the data. But that serialization method also will fail silently if and when the data is corrupted or otherwise incorrect for your given scenario. For low-priority, low-value data that's probably fine. But hopefully you can see why a library like .NET is only going to provide serialization techniques that are more robust (albeit with their own imperfections, of course). Pete
From: DanB on 8 Mar 2010 13:53 Peter Duniho wrote: > DanB wrote: >> Peter Duniho wrote: >>> >>> So, when the ComboBox is properly initialized, you get something more >>> like this for the above code: >>> >>> comboBoxChartType1.SelectedItem = cutItem.seriesSet[pos].type; >>> >>> Likewise, this: >>> >>>> From box: >>>> curItem.seriesSet[ pos ].type= (SeriesChartType)Enum.Parse( >>>> typeof(SeriesChartType), comboBoxChartType.Text, true ); >>> >>> �becomes this: >>> >>> curItem.seriesSet[pos].type = >>> (SeriesChartType)comboBoxChartType1.SelectedItem; >> >> Hi Peter, >> Old habits. I would avoid storing data as an index whenever possible. > > Look again at the code I posted. It does not store the data "as an > index". In fact, it doesn't change your design at all. It simply > implements your design without all the extra, unnecessary code you were > using before. I see what you mean, but you threw me as you didn't cast in the top example. But this means I'd have to use the enum as is, I can't set which items and what order in the dropdown, which is what I'm after. So if I populate the comboBox by hand, I'll still have to use my code it seems. > As for your serialization problems, well�type safety, versioning, and > data consistency requirements are a double-edged sword. It's true, you > can write your own serialization that doesn't impose the same > requirements on the data. But that serialization method also will fail > silently if and when the data is corrupted or otherwise incorrect for > your given scenario. > > For low-priority, low-value data that's probably fine. But hopefully you > can see why a library like .NET is only going to provide serialization > techniques that are more robust (albeit with their own imperfections, of > course). If I change: <type>Line</type> to: <type>Lines</type> It completely fails to load. My lib would return the default. I'm not sure what the trade off is, i.e., what do I gain by this kind of crankiness? I'd think robust includes forgiveness. I consider my app data very high value, it is my clients work at risk. In all the years I've been using my lib I have yet to have a problem like loosing client data unless the file is grosly corrupted, and that is very rare. I'm figuring the easiest way to handle this is a running back up for now and if I catch in the load, let the client use the previous file. Yea, once the data is settled in, it should not really be a problem. I'm a pretty simple minded xml user as I primarily use it as a DOM database in my stuff. I'll have to see what XmlDocument is like to use instead of serialization some day. (And if this sounds like I don't know what I'm talking about, sure, I've been doing c# for less than a week. :) <http://msdn.microsoft.com/en-us/magazine/cc302158.aspx> This is so far an exercise to learn c# and this app will be a helper in my product. And that I'm using it I'll have to provide a 3.5 .NET installer for those who don't have it. But I'm trying to move into the new world. This morning I've tried an experiment by copying the exe to my wife's computer. She has a year old Vista with .NET 3.5 installed. But it fails to run on her machine. I have put a MessageBox right at the start so I don't have to worry about other why's further in the program. More TODOs! I can drop a c++ exe on her machine and it runs fine. Is this because c# programs have to be installed, or something else? Not sure as I can run it from anyplace on my machine. Best, Dan.
From: Peter Duniho on 8 Mar 2010 23:29 DanB wrote: > [...] >>> Old habits. I would avoid storing data as an index whenever possible. >> >> Look again at the code I posted. It does not store the data "as an >> index". In fact, it doesn't change your design at all. It simply >> implements your design without all the extra, unnecessary code you were >> using before. > > I see what you mean, but you threw me as you didn't cast in the top > example. No cast is needed going from the more-derived type to the less-derived type. But, as always, you need a cast going the other way. > But this means I'd have to use the enum as is, I can't set which items > and what order in the dropdown, which is what I'm after. It doesn't mean that at all. It's true that the code I posted populates the list in order of appearance in the enum. But nothing is stopping you from imposing your own order on the list. > So if I > populate the comboBox by hand, I'll still have to use my code it seems. Probably not true. But until you provide specific information, including what "your code" looks like, impossible to know for sure from this end. > If I change: > <type>Line</type> > to: > <type>Lines</type> > > It completely fails to load. My lib would return the default. I'm not > sure what the trade off is, i.e., what do I gain by this kind of > crankiness? I'd think robust includes forgiveness. Why in the world would the content of the element ever be "Lines" instead of "Line"? What value is there in allowing the latter, when the former is the only correct, expected output from your serialization code? "Robust" can mean whatever you want. But usually, "robust" means the code is hardened against bad input, not that it makes guesses as to what bad input is intended to mean. > I consider my app data very high value, it is my clients work at risk. > In all the years I've been using my lib I have yet to have a problem > like loosing client data unless the file is grosly corrupted, and that > is very rare. [...] All due respect, with a serialization technique that makes guesses as to the intent of bad input, you have no idea whatsoever whether there has been an actual problem or not. All you know is that if there has been a problem, it hasn't been obvious enough for anyone to notice. Pete
From: Tim Roberts on 10 Mar 2010 01:49 DanB <abc(a)some.net> wrote: > >This morning I've tried an experiment by copying the exe to my wife's >computer. She has a year old Vista with .NET 3.5 installed. Are you sure? HOW are you sure? >But it fails >to run on her machine. I have put a MessageBox right at the start so I >don't have to worry about other why's further in the program. Release build? Debug build? >I can drop a c++ exe on her machine and it runs fine. Not always. Try to do that with a DEBUG build, for example. Unless you were foresighted enough to statically link the CRT, you'd be screwed. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: DanB on 12 Mar 2010 17:15
Update... So I learned how to do managed c++ this morning. Even more interesting, I learned about the new 'reference handles'. % ^ So I got the MSChart up and running in an MFC dialog. Anyway, said and done, it still crashes on my wifes machine, just uncomment this line and it won't run. So it has something to do with 'Charting' as other dot net object in my MFC app don't cause a problem. CWinFormsControl<System::Windows::Forms::DataVisualization::Charting::Chart> theChart; I even tried uninstalling and reinstalling .NET, it did not fix it... Best, Dan. :( |