15,885,767 members
Sign in
Sign in
Email
Password
Forgot your password?
Sign in with
home
articles
Browse Topics
>
Latest Articles
Top Articles
Posting/Update Guidelines
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
quick answers
Q&A
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View C++ questions
View Javascript questions
View Visual Basic questions
View Python questions
discussions
forums
CodeProject.AI Server
All Message Boards...
Application Lifecycle
>
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Work Issues
Design and Architecture
Artificial Intelligence
ASP.NET
JavaScript
Internet of Things
C / C++ / MFC
>
ATL / WTL / STL
Managed C++/CLI
C#
Free Tools
Objective-C and Swift
Database
Hardware & Devices
>
System Admin
Hosting and Servers
Java
Linux Programming
Python
.NET (Core and Framework)
Android
iOS
Mobile
WPF
Visual Basic
Web Development
Site Bugs / Suggestions
Spam and Abuse Watch
features
features
Competitions
News
The Insider Newsletter
The Daily Build Newsletter
Newsletter archive
Surveys
CodeProject Stuff
community
lounge
Who's Who
Most Valuable Professionals
The Lounge
The CodeProject Blog
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
help
?
What is 'CodeProject'?
General FAQ
Ask a Question
Bugs and Suggestions
Article Help Forum
About Us
Search within:
Articles
Quick Answers
Messages
Comments by Jeremy Hutchinson (Top 5 by date)
Jeremy Hutchinson
4-Oct-11 14:51pm
View
Deleted
You are correct. It does take time to evaluate the expression. I rigged up a quick little test to see how much time and found it was quite significant.
I set a property 1 million times:
String based OnPropertyChanged took ~4 milliseconds
Expression based OnPropertyChagned took ~5000 milliseconds
So for a class with 50 properties the expressions could add a quarter of a second to a full refresh of the object. Thank you for pointing this out, I wonder if my users will notice when I remove all those expressions later this week.
Of course leaves me in the awkward position of 5ing your post and downvoting my own (if I can).
Jeremy Hutchinson
20-Sep-11 12:41pm
View
Deleted
It's more a comment than a alternative.
You are right, this does raise some problems with the consuming code. If it is your code, you should probably use the same GetProperty(() => obj.FnordDesc).Name instead of using the "FnordDesc".
If it's not your code, you just broke the consuming code anyway, and the user will need to hunt through their code for any reference to FnordDesc and change it to FnordDescription. You probably haven't created any additional work for them because you probably would (should) have change your event raising code to PropertyChanged("FnordDescription") when you changed your property name.
Jeremy Hutchinson
6-Jun-11 9:38am
View
Deleted
Reason for my vote of 1
It's not catching the the exception. It just finalizes without letting the caller know something went wrong.
Jeremy Hutchinson
17-May-11 11:14am
View
While I generally agree it is good practice to use && over & where appropriate (there's places where it's not), it is certainly not required. In a case like this were you are just comparing strings it is not going to have any noticeable effect on performance and amounts to a style issue.
If I were going to correct a style issue, the first thing I would change is to put braces around the else code to make it clear that the Focus and selection setting happen for both paths, which may or may not be what was intended.
Jeremy Hutchinson
6-Dec-10 13:55pm
View
Deleted
http://sqlserverpedia.com/blog/sql-server-bloggers/sql-server-%E2%80%93-stored-procedure-optimization-tips-%E2%80%93-best-practices/
Dave? Is that you? I doubt it.