|
Hi guys,
I am building some components for my windows app, one of which contains a SplitContainer. Once i put the control into the host form, i can't do anything with the controls in my custom control. I'd like to enable some re-arranging functionality inside this, i.e. the ability to drag the split bar.
Could anyone give me points in the right direction? I'm not entirely sure what i'm looking for.
Cheers
Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
|
Hi Everyone,
I have a few doubts regarding Exception Throwing. I read from documentation that while designing methods in a Framework, exceptions are the primary means of reporting errors in frameworks. However is Exception Throwing always the better way to communicate errors? Consider a scenario, where we have to validate the Input parameters of a method , when the input validation fails , which mode of approach is more suited – throwing an ArgumentException or returning an error code.
|
|
|
|
|
If you return an error code, you are putting the emphasis on somebody actually reading the error code and doing something with it. At some point, somebody has to say "this is wrong, I need to do something". This is obviously an exceptional case, hence you should really consider designing with an exception.
However, it is perfectly valid to have some logic in your code where you may attempt to do something if the condition fails. For instance, if you are saving an item to a database for a user, it is better to write to an alternative database if you can't get to the master and then synchronize the two later on, than to just fail and tell the user that it's tough but you can't save their work.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Hi Pete ,
I agree to your point... But microsoft itself is coming up with method that contradicts exception throwing as way of reporting errors.... For ex:- new methods like bool.TryParse , Dictionary.TryGetValue Method etc which does not throw exception , they return boolean value indicating the status of conversion instead of throwing exceptions...
|
|
|
|
|
That's OK for low-level operations, where it is sufficient just to know whether an operation was successful or not without the overhead of raising an exception if it wasn't. However for higher-level business logic operations e.g. saving some data to a database, more detailed error information would be required by the code consumer if something went wrong. Raising exceptions is a good way of providing this information.
Paul
|
|
|
|
|
Yes they introduced the TryXYZ methods but this is not a contradiction because there are a lot of scenarios where you have a string with user input and have to know if it is an int. And if it is not this is not a real exception. Using exceptions for user input checking is not the right way to go. Exception should only be used in real exception cases.
-^-^-^-^-^-
no risk no funk ................... please vote ------>
|
|
|
|
|
The Tryxxx pattern doesn't contradict exception handling at all. This pattern is designed for very fast testing in cases where you can take an alternative path if the value isn't valid.
For a more detailed explanation of the TryParse pattern, take a look at this blog entry:
http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx[^]
Taken from the comments on this entry:
Parse says it’s going to parse something. “Failure” means it couldn’t parse it. So exceptions from Parse could include exceptions because what you passed to it wasn’t parseable. The return value is the result of the operation—the parsed value.
TryParse says it’s going to try to parse something. “Failure” means that it wasn’t even able to try to parse the thing. Thus the only kinds of exceptions you’re going to get out of TryParse are things like OutOfMemory from JITting or allocating buffers before it even gets a chance to look at the string to be parsed. (You wouldn’t expect to get an exception because the value wasn’t parseable…the point is the method said it was going to try, and it did try. It did what it said it would, so no exception needed.) TryParse really has two results—was the thing parseable, and if so the parsed value.
|
|
|
|
|
Hi,
exceptions are fine in that they allow you to perform a sequence of operations and get
informed automatically if something went wrong in the middle. The main idea is normally
things run fine and an Exception is the exceptional case.
on the other hand you may have a lot of methods whose main purpose is to check something
that may or may not be true. Examples are IsNumeric, TryParse, IsNull, ...
Here the caller expects a pass/fail result, and the probabilities may not be very different;
so the caller does not want the overhead of exceptions, he wants a bool (or possibly
an int or enum as a result code, as in ShowDialog).
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
So the typical Design can be ErrorCodes as error indicators for functions that do Checking and validations, where are processing related functions can have exceptions as error indicators
|
|
|
|
|
Yes.
The only thing is you must make sure you check the values returned; it would be very
wrong to ignore an error code, that is one of the very good reasons to use exceptions
in general, return codes in special cases only.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Just throw the Exception, it allows you to easily provide additional information about the problem.
|
|
|
|
|
There's a lot of ways to check for errors. Exceptions are probably the last line of defense against bad stuff coming into your code. And they should be used as part of defensive programming.
At some point in your code, you need to figure out what to do about some problem otherwise the user in confronted with something like "Invalid parameter something in somemethod" which is probably not a positive user experience.
It is a good idea to catch input errors as soon as possible. The .NET framework provides this functionality with validators. You can attach a validator to a user control and check the input values long before an exception would be even necessary. You might want to look at An Introduction to Validation Controls[^]. The .NET Framework provides several built in controls to do basic validation for both ASP.NET and Windows Forms.
You can also build your own validators as shown in Validator Control Samples[^].
In addition the Validation Application Block[^] will provide a way to declare your validations without a lot of code. The Enterprise Library Validation Application Block provides a library of classes, called validators, that supplies the code for validating .NET Framework data types. For example, one validator checks for null strings and another validator checks that a number falls within a specified range.
Exceptions are really important for you to use in keeping your code clean and to define the expectations that your code has to anyone who is calling your method. But you should do validation on user input too to weed out any bogus values before they get to your code.
But let's say that your code does get into a bizarre state that you did not anticipate. And that the code throws one of those exceptions. You'll want to figure out what to do about it so that your users or system engineers can understand the problem and fix it. This means that ultimately you should catch your exceptions and provide yourself and your IT department with instructions that are actionable, either in a log file or in a user error message. You should provide the user with some way to fix the problem.
Exceptions are just the first part to writing your program so unexpected values don't break it. And you should catch all your exceptions to provide your user with something other than, "Oops. Something unitelligible failed."
Find more support for your software development efforts at Innovate-On[^]
|
|
|
|
|
HI All,
I HAve Added Web Reference to A VC.Net (VisualC++/CLR) Project.
After I Have added Successfully a Web Reference.I Have to Change the
URL Behaviour Property to "Dynamic" but I Havent Found Such Property of
Web reference.
IF we Add A web reference to C# project & Open The Propertied Dialog Box
of Web reference ,It will Show U A property "URL Behaviour" Where we can Change Dynamic or Static.
But for CLR Projects I Havent seen That property.
plz suggest me is there is a method where i can Change the URL Behaviout to Dynamic.
Thank You
Nagaraju
|
|
|
|
|
Hi,
I have created a COM Visible .NET dll that is deployed on a Citrix server (regasm.exe). What the dll does is that it calls a web service on a remote machine.
Everything works fine running as an administration, but running as a "normal user" the COM Client can´t create the .NET dll.
What could be wrong? Could it be a sequrity issue?
Br,
Jonas
|
|
|
|
|
Did you put it in the GAC?
|
|
|
|
|
Is it possible to get code comments included in the generated WSDL file ?
|
|
|
|
|
Hi,
I have a .net application that does a lot of number crunching and I run it on a 64-Bit machine with quad CPU. The machine has 4GB RAM.
When I compile the application to explicitly target x86 machine the application runs faster than when I compile it to target x64 machine. The difference is around 50% !!!
I don't change anything in the application except the target machine.
The application is a pure .net application.
Any idea, what is the reason for this?
Ami
|
|
|
|
|
Hi,
can you tell more about your app, what it is doing, what the most common data types are?
why would you expect it to run faster? is your data basically 64-bit wide? 32-bit? 16-bit?
is it text processing?
what language are you using?
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Hi,
The common type is double, which is 8 bytes long.
The application does a lot for number operations (simple adding, multiplying, etc.)
I expect the x64 version to run at least as fast as the x86 version.
I am using C#.
Ami
|
|
|
|
|
Hi Ami,
assuming the calculations outweigh the memory transfers and general program flow,
I expect no difference whatsoever between a 32-bit and a 64-bit version of your app:
they both will spend their time mostly on processing 64-bit data that sits in the
float registers and/or the data cache.
So if your 64-bit app is slower, something definitely is wrong. Are you comparing equal
things (e.g. both release builds, identical jobs)?
If you have been trying to optimize things by using multiple threads, then maybe the two
systems you compare are not equally happy about your threading approach. If this applies,
it has to be looked at more thoroughly... As a first measure, you could reduce to one thread
and compare these (again expecting equality).
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Hi Luc,
Luc Pattyn wrote: So if your 64-bit app is slower, something definitely is wrong. Are you comparing equal
things (e.g. both release builds, identical jobs)?
It is the exact project (Release mode), the only difference is the target CPU x86 or x64.
Luc Pattyn wrote: If you have been trying to optimize things by using multiple threads, then maybe the two
systems you compare are not equally happy about your threading approach. If this applies,
it has to be looked at more thoroughly... As a first measure, you could reduce to one thread
and compare these (again expecting equality).
I am using some multithreading, I'll try to do it in one thread and check the results.
Thanks for the advice.
Ami
|
|
|
|
|
Just wanted to know if shutdownTimeout has any edge over the traditional executionTimeout at least with respect to ASP.NET.
I have my application wait for a slow network response. But sometimes when the servicing network is slow, the front-end web application goes astray. Here is my query:
Can I be able to keep my ASP.NET worker process alive in a particular session from within? I am sure that one possible reply would be that this would open up loopholes for hackers to break into. But I can ensure that this code resides well within a httpmodule and parsed only one genuine needs.
|
|
|
|
|
Have you resolved this?
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
I'm going to bind data set to combo boxes. Data set is compound from 2 tables and joined by relation. The declaration is as follows:
Private tablePRAgent As PRAgentDataTable<br />
<br />
Private tablePRAgentLocation As PRAgentLocationDataTable<br />
<br />
Private relationPRAgentPRAgentLocation As DataRelation<br />
The table PRAgentDataTable has main rows with details in table PRAgentLocationDataTable. So first combo is bound to PRAgentDataTable and second - to PRAgentLocationDataTable, by relation. Filling adapters (and in consequence combos) while I add clause "WHERE col=@parameter" ends with "exception of type 'System.Data.ConstraintException'". When there is no WHERE clause everything goes right.
How could I overcome this problem?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
