|
Uhhh...Yoda just read that and went "What?"
If you're asking me to rewrite the code for you,that's not going to happen. I've got my own code to write and I've got a few hours work left before I can go to sleep tonight.
|
|
|
|
|
no need to rewrite the code, the original was this error No overload for 'splitter1_SplitterMoving' matches delegate 'System.Windows.Forms.SplitterCancelEventHandler' you fix this ?
|
|
|
|
|
No, I can't. You typed the code and I can't see it. The error is telling you that you've got the method header parameter list for "splitter1_SplitterMoving" wrong.
|
|
|
|
|
|
your link posted nearly identical to my questions, your example changes the mouse pointer while dragging splitBar, my questions changes the color tranparen for splitBar while dragging splitBar. Thank you send me the link for referenceing
|
|
|
|
|
You're welcome.
This space for rent
|
|
|
|
|
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
|
|
|
|