|
Sander Rossel wrote: I'm thinking this isn't ideal in terms of complexity and readability, IMO any generic solution beats writing endless switch-statements or having to update code in multiple places when introducing a new field or whatever. Even if it's bordering on your personal definition of complexity and readability. The other solution probably wouldn't win a prize either
Sander Rossel wrote: I'm more or less forced to use a dynamic later on as it's quite impossible to get the values of TElement and TKey from object . Can you elaborate?
|
|
|
|
|
Sascha Lefévre wrote: Can you elaborate? Sure.
Consider this
MyClass<SomeClass, string> result = SomeFunction("Name", Queryable.OrderBy, q => q.Name);
comboBox.Items.Add(result);
comboBox.Items.Add(SomeFunction("Date", Queryable.OrderBy, q => q.Date));
comboBox.Items.Add(SomeFunction("Age", Queryable.OrderBy, q => q.Age));
object ordering = comboBox.SelectedItem;
MyClass<SomeClass, ...?> result = (MyClass<SomeClass, ...?>)ordering;
dynamic ordering = comboBox.SelectedItem;
ordering.LinqFunction(ordering.Predicate);
|
|
|
|
|
Makes sense. But is there a specific reason why you didn't use a signature like this:
MyClass<SomeClass> ordering = SomeFunction(string caption, Func<IQueryable<TElement>, IQueryable<TElement>> applyPredicate) { ... }
And then use it like this:
comboBox.Items.Add(SomeFunction("Date", source => source.OrderBy(q => q.Date)));
MyClass<SomeClass> ordering = (MyClass<SomeClass>)comboBox.SelectedItem;
ordering.ApplyPredicate();
|
|
|
|
|
Yep, I need the q => q.Date part seperately
Although you do make a good point. I'll see if I can change the code tomorrow so it would work as you propose. It would certainly make that easier.
|
|
|
|
|
Another part of my app got slightly more complex, but I was able to implement this solution and overall reduce complexity (I hope)
|
|
|
|
|
That's great! Glad I could help a minuscule amount
You recommended the XtraGrid to Eddy Vluggen - may I ask why you don't use it in this project too? (I'm about to use it myself for the first time and I would be interested what reason there could be to not use it)
/Sascha
|
|
|
|
|
Sascha Lefévre wrote: That's great! Glad I could help a minuscule amount I'm pretty sure you're helpful at bigger amounts than that (in fact this was more than minuscule already!)
Sascha Lefévre wrote: You recommended the XtraGrid to Eddy Vluggen - may I ask why you don't use it in this project too? I used the XtraGrid (and more XtraControls) at my previous job. I'm now at a new job, working for a customer who sticks to as much "vanilla .NET" as possible. If I could I'd get those XtraControls right in there, but it's not my call
And the job initially involved just some bugfixes for a few weeks. In HTML and CSS. With AngularJS. But in reality I've been doing WinForms for over a month now
|
|
|
|
|
Sander Rossel wrote: But in reality I've been doing WinForms for over a month now Probably they've realized there's someone who knows what he's doing in WinForms and need to capitalize on that before you leave
|
|
|
|
|
Actually they didn't know. I quit my last job (three months ago) because I wanted to do something else than WinForms.
The company I work for now doesn't do WinForms at all. They assured me I'd never do WinForms again!
So then this customer called "We need a programmer for some quick bugfixes asap! We need a HTML and CSS expert!"
A colleague and me would do the job. Then they called again "Actually, we need someone with AngularJS skills."
I actually spend an entire day learning AngularJS, because I didn't know it yet (my colleague does know it).
But the day before we'd get started they called again "Actually, do you have a WinForms programmer? We need it more than the web stuff!"
And so here I am doing WinForms programming again. Not quite what I had in mind, but it's only for a few weeks
|
|
|
|
|
Ah, I see - it's that client who exactly knows what he needs!
At least your time spent learning AngularJS won't have been wasted once you're done with this
By the way, you said somewhere in this thread that n-order-sorting is being done with additional entries in that ComboBox. But at least now that you have this solution in place it would be easy to allow the user to flexibly chain sorting columns. Not that I want to lengthen your time with WinForms though
|
|
|
|
|
I say kudos for cleverness! Your solution is hard to read/understand (at least for me) but I like it since it makes me break it apart. If I still don't understand it, I'd have to run it in a debugger. Just leave decent documentation for the next guy.
"Go forth into the source" - Neal Morse
|
|
|
|
|
kmoorevs wrote: Just leave decent documentation for the next guy If I told you you could call it like this, would you know enough?
SomeFunction("Name", Queryable.OrderBy, q => q.Name);
|
|
|
|
|
Sander Rossel wrote: would you know enough?
I wouldn't. I don't do lambdas. Or Linq.
|
|
|
|
|
|
I do C# ; it's kids these days who don't.
|
|
|
|
|
You do C#, but not LINQ and lambda?
How do you work with collections, write out each foreach loop every time?
|
|
|
|
|
Foreach is inefficient, for loops rule.
|
|
|
|
|
I think/hope you're missing a joke icon
|
|
|
|
|
"Maxthon has found dangerous code on this page.
Click OK to stop loading the page, or Ignore if you're an idiot."
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
It's pretty clever.
Although I am stuck on why you don't sort on the column headers, and eliminate the problem?
Also, my first thought would have been to simply enumerate the columns to load the Combo..
Your solution has the added advantage of a simpler way to select a hidden column, as well as
a more complicated pre-defined sort.
I am not sure that the Descending option needs to be in the Combo.
Sort by: [Name ^] [x] Descending
Given that I am not familiar with WHY your UI is the way it is, I am not qualified to recreate it.
But I do prefer naturally adaptive code (reading the columns from the dataview).
No need to remember anything...
|
|
|
|
|
Looking at your code my subconscious started hearing the song "Simply Irresistible," starting at the verse: "methods are inscrutable"
cheers, Bill
«To kill an error's as good a service, sometimes better than, establishing new truth or fact.» Charles Darwin in "Prospero's Precepts"
|
|
|
|
|
|
How's that the same? My solution is type safe and has design time error checking
I simplified it a bit by the way.
|
|
|
|
|
It is the same in that it accomplishes the desired functionality in the app.
You were asking where to draw the line on readability and simplity. If you give a junior developer an API with .OrderBy(string) and then the one you posted, which will they understand immediately?
|
|
|
|
|
Put like that you make a good point.
The question is are you willing to trade type safety for a simple API? OrderBy(string) may be a simple function, but there's no way in telling what string values are valid and when their validity expires.
|
|
|
|