|
Hi,
I have currently migrated my application from 2.0 to 4.0. What i suggest is try to build your code from target framework 4.0 to 2.0, also setting up the cpu type as x86 for 32 bit platform.
Also, if there are some client side validation, you need to do settings in pages element attribute controlRenderingCompatibilityVersion=2.0 in web.config for the asp.net controls.
-Mayank Pant
|
|
|
|
|
Don't know why you're telling me this. I know how to convert code. If you meant to tell the OP how to do this, they won't get any notifications that you replied to another person.
This space for rent
|
|
|
|
|
Pete ! my bad.
I just replied to your thread. That was not my intentions.
Thank you for correcting me .
|
|
|
|
|
Hello friends ! Now, I do not Convert 2.0, I'm using 4.0, but still you see the error of my attachments SplitterPaint_[^]
|
|
|
|
|
Why not go and ask the person who wrote the article?
|
|
|
|
|
The error I got by simply pasting the code into a blank project was
Quote: Error 1 The name 'Color' does not exist in the current context
That went away when I included
using System.Drawing;
In a subsequent comment you stated Quote: the original was this error No overload for 'splitter1_SplitterMoving' matches delegate 'System.Windows.Forms.SplitterCancelEventHandler'
Nothing in the code you have posted nor in the link you provided produces that error - you will need to show us that code if you expect some help
|
|
|
|
|
I declare libraries needed then but not run. you see my attach file SplitterPaint_[^]
|
|
|
|
|
I don't download unsolicited files from unknown sources. You can post code here or use something like imgur to show an image.
|
|
|
|
|
I checked and normal download you can tell me why you can not download ?
|
|
|
|
|
Because I do not download rar or zip files from unknown sources. If I was at work then it would be prevented by the firewall rules in place, at home it is a personal decision. It's a policy that might explain why up to now I have not been affected by any viruses
|
|
|
|
|
To start, I'm a fan of the out keyword. I like being able to return a true/false to indicate that the function completed successfully and pass additional information or result sets through a function arguments. I've seen many times during code analysis that Visual Studio gripes about out parameters, CA1021 to be precise. I understand the point that the devs were making when they state that using out and ref requires an understanding of pointers but in that context, shouldn't they also try to discourage using delegates, since delegates are pointers to functions? Which are we supposed to believe? Personally, I see the out keyword as better choice in some task specific uses and that writing a custom result class rarely has any measurable benefit.
I would like to hear what the experts think of this. Is out okay or should its use be avoided?
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Instead of an out Boolean to indicate success/failure, throwing exceptions provides more flexibility and scalability
|
|
|
|
|
Sorry I didn't clarify in the question, but I didn't indicate that exception handling was implied. There are cases where success doesn't mean that the function ran without error and that using out could make the function more useful.
Example
public bool IsProductOnSale(guid productId, out Guid[] productResellerIds)
{
}
It's not the best example without a better understanding of the overall context. I'm just saying, if you have what you need already, why write multiple functions for what could be handled in one?
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Why not returning the array instead and interpreting an array-length of 0 as "product is not on sale"?
(The method should be renamed then of course.)
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
I thought it was a bad example. I'm just trying to start a discussion on the use of out and not focus too much on implementation specific code.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
clapclap wrote: Instead of an out Boolean to indicate success/failure, throwing exceptions provides more flexibility and scalability
This is a very bad practice. Exceptions are just that, when something exceptional happens. Exceptions are very expensive operations, they take a long time to create, have you seen all the information that is involved when an exception occurs? Using exceptions to control things you expect to happen, or can predict will happen, is very bad practice.
|
|
|
|
|
I find the argument that devs need skills to use out and ref a bit lame.
We're professional programmers and we write for other professional programmers. I really hope professional programmers grasp the concept of reference and value types or we're going to have bigger problems than out and ref.
That said, I still don't think the use of out and ref is particularly good design.
As a rule a function should do one thing only, that means it probably produces at most one value (in some cases that value is a complex object containing many properties).
Functions that are pure (i.e. have no side-effects) are easier to grasp, change, and maintain as well, using out or ref is a side-effect. Having pure functions is a more functional approach to programming (which we can't or should fully implement in C#, but still has benefits).
In most cases I prefer validating all input thoroughly, if success do the thing else return and show the user the validation results. If the thing still fails there must be something really wrong. Returning a bool won't do, an Exception is the way to go.
Of course the TryParse/TryWhatever and DivRem methods are acceptable exceptions to this rule. Mostly because it's convention, the alternative would be something like "if (int.CanParse(value)) int.Parse(value)".
In the case of DivRem the remainder is used to calculate the quotient and while you have the remainder anyway it would be a waste to throw it away just because returning two values is "bad design".
Personally I've never needed out or ref 
|
|
|
|
|
I see your point when you run comparisons against the functional programming paradigm. In the question, I should have expanded to include that the function's success/failure result was outside of exception handling. The function should, by all means, throw exceptions but the usage of out really does seem best fitted to TryParse style functions where I want to know if the function did what it was supposed to do before I try to do anything with the result. With TryParse, it almost seems like it was designed to swallow certain exceptions and return false if they occur.
Let me see if I can give a better example. Let's go with an web environment that supports both internal and external user logon.
using System.DirectoryServices.AccountManagement;
public static class AuthorizationManager
{
public static bool UserHasAccess(string userName, out UserPricipal user)
{
}
}
The function basically answers two questions, is the user an internal user by populating the user parameter and that the user has the required access.
I am seeing similar approaches to this in the black box code of the Cryptography namespace. Like with RandomNumberGenerator.GetBytes(byte[]) where you pass a instantiated array of bytes to the function and it populates all the elements with random values. Why is this method used instead of byte[] rndAry = rand.GetBytes(n);? The deeper I delve into C# and .Net, the more contradictions I find.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Foothill wrote: Let me see if I can give a better example. Let's go with an web environment that supports both internal and external user logon.
I'm not sure I get what your function is doing. If the user has no access what happens to the principal (null, default/anonymous implementation)? Can the method return true and still set principal to null or return false and set the principal anyway? What if you decide for an anonymous principal (or whatever) instead, will it always return true? I'd have to read the documentation and trust it's correct (and I never trust documentation).
I'd expect (and prefer) something like the following, although I'm not sure how this would work out in actual code:
public static UserPrincipal GetPrincipal(string userName)
{
if (UserIsAuthorized(userName))
{
return new UserPrincipal();
}
else
{
return null;
}
}That code makes it pretty explicit that there is or isn't a UserPrincipal for a userName. The function now does one thing (retrieve the principal if it exists) and the function name makes it clear. There is also one less variable to worry about (which eliminates the questions I raised earlier).
Foothill wrote: The deeper I delve into C# and .Net, the more contradictions I find.
Many people worked on it and all had their own ideas and experiences. That .NET does it like this doesn't mean it's good or makes sense. Or maybe it does, but we don't know why
I'd prefer the byte[] rndArr = rand.GetBytes(n); approach, but you might have guessed that
|
|
|
|
|
Ah, so even though I can find Microsoft code that does it, doesn't mean that it's encouraged or the best way to go about things. One takeaway that I am getting is that you should always write your code so simple that it lends to documenting itself even when you are writing companion documentation. I guess the out and ref keywords really are throwbacks to the old WIN32 API design style.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Foothill wrote: Ah, so even though I can find Microsoft code that does it, doesn't mean that it's encouraged or the best way to go about things
Even though Microsoft preaches best practice they don't always practice it themselves 
Foothill wrote: One takeaway that I am getting is that you should always write your code so simple that it lends to documenting itself even when you are writing companion documentation
That's an awesome takeaway! 
|
|
|
|
|
Sander Rossel wrote: That's an awesome takeaway!
Just one of many, OG is giving me some great info on intricacies of exception handling below. There seems to be a leaning that out is only useful with TryParse style methods where you know exactly how a function could fail and you are given a choice how to handle it without having to surround the function with try...catch blocks.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Foothill wrote: byte[] rndAry = rand.GetBytes(n);
Easy enough to implement with Extension Methods.
I might as well put some in my utility library. They likely will be useful.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Foothill wrote: With TryParse, it almost seems like it was designed to swallow certain exceptions and return false if they occur.
Yes it does seem that way, but that's not how TryParse works and it's important to understand that. As I mentioned above, exceptions are incredibly expensive and you should not be raising them lightly. The "Try" in TryParse doesn't mean there is an internal try\catch around the parse, it is there to indicate that it will try to do the work, but the work might fail. With Parse on its on there is no "might fail", with Parse we are saying that this operation is going to work because we know the text is of the correct format.
If you disassemble the code behind int.TryParse you will see that it verifies programmatically that the text can be converted to an int and if it detects otherwise it returns false - no exceptions or thrown or swallowed. int.TryParse is an incredibly frequently used function and if it generated exceptions internally then the resulting code would have incredibly poor performance.
|
|
|
|
|
Ah, that makes sense. TryParse is a very simple interface to what seems to be a complicated mechanism under the hood. Thanks for explaining it in greater detail.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
