...and that was the problem: I put a NumericUpDown control in a UserControl and I give it an unique name (NUD1). When, at runtime, I create 10 instances of the UserControl, what are the unique names of the 10 NumericUpDown controls originated from NUD1?
Good assesment; the others wouldn't have a name.
also this property has a unique name... until the UserControl is one, but when I create 10 instances of the UserControl?
You'd have 10 controls without a name (the usercontrol), but with a known property that points to the correct control.
Well... it works... although I have some difficulty in evaluate the elegance of this code...
What do you think about this solution?
It'll do; seen the technique before, usually when ex-VB programmers want an "array" of controls. It adds a single pointer to the list for each control, so it's not very resource-intensive.
What you are "testing" is the IsNullOrEmpty function; I'll test with either one, fully confident that the method will behave as documented. When I test, I test my own code, not the frameworks' methods.
I guess my thought was that I testing to make sure someone didn't change the actual call to IsNullOrWhiteSpace. In theory a future dev could change my IsNullOrWhiteSpace to IsNullOrEmpty and effectively break the method by allowing it to accept an string of whitespace.
I might be being too much of a control freak though.
In theory a future dev could change my IsNullOrWhiteSpace to IsNullOrEmpty and effectively break the method by allowing it to accept an string of whitespace.
In that case, the only good test would be to compare the methods' body to the actual source-code you have now.
Don't let people change your code if they don't know what they're doing. Any nitwit could guess that if the method behaves different (translate to 'unexpected') that things will break. On a class-level, this is the L[^] from the SOLID principle. Simplest example; don't throw any exceptions that weren't already in the base-class (as the applications' try..catch constructs will not expect it, and break).
You're also testing what would happen based on the types of data that you're sending it. If, somewhere down the road, the data you're sending the method changes, you may need to document that the method can handle those changes as expected, such as sending a string of space and tab characters.
Personally, I would be checking to see if an actual string was passed in, THEN stripping the data of leading and trailing whitespace if required and then checking for an empty string. String.IsNullOrEmpty doesn't check to see if the string contains non-whitespace characters.
Personally, I would be checking to see if an actual string was passed in, THEN
The parameter only accepts strings, making this test superfluous.
Dave Kreskowiak wrote:
stripping the data of leading and trailing whitespace if required and then checking for an empty string. String.IsNullOrEmpty doesn't check to see if the string contains non-whitespace characters.
Personally, I don't care for "whitespace"; if a user wants to store three spaces, a tab and a newline, then that's what gets stored. The only place where you "might" want to check it, is when validating input. Remember the NT4-server shutdown dialog? Required a non-null "reason". Did it help? No, a single period was "reason" enough.
The parameter only accepts strings, making this test superfluous.
You would check for mull before trying to work with the string?? I don't see how that's superfluous.
Eddy Vluggen wrote:
Personally, I don't care for "whitespace"; if a user wants to store three
spaces, a tab and a newline, then that's what gets stored. The only place where
you "might" want to check it, is when validating input.
User's aren't the only source of input that makes your code go "WTE!?" Foreign systems, poor XML files, non-normallized data in a database you inherit, corruption from a poor communications channel, ... the list goes on. You can get a blank or string formatted in some way your code doesn't expect from any number of sources. I was always taught that a method should be written to defend itself against pontentially bad data.
Hi, im trying to develop a program for win98, i work with 2.0 VS 2008, in the develop machine all runs ok. at client i receive application has generated an exception that could not be handled 0xffe31701(-1894655), Thread ID=0xffe31395(1895531)
if someane knows wath can i do, please help.
and please don't start with the Win98. replace it it's not an option, its on board in a big machine.
I don't think you will get anywhere with this, Windows 98 has been dead a long time. The .NET framework was never designed to work under such an old version of Windows so it is unlikely that any .NET application will work.
One of these days I'm going to think of a really clever signature.
Version 2.0 without any Service Pack is the last version with support for Windows 98 and Windows Me. Version 2.0 with Service Pack 2 is the last version with official support for Windows 2000 although there have been some unofficial workarounds published online to use a subset of the functionality from Version 3.5 in Windows 2000. Version 2.0 with Service Pack 2 requires Windows 2000 with SP4 plus KB835732 or KB891861 update, Windows XP with SP2 or later and Windows Installer 3.1 (KB893803-v2)
Win98 only supports a limited set of the classes of .NET2.0, and only without service-packs. Your development-machine doesn't change that. And yes, when you run into a problem using ancient software, support is virtually non-existing.
Im fairly new to this so please bear with...
I'm using the tutorial @ http://www.kelvinluck.com/assets/jquery/datePicker/v2/demo/index.html
to allow the user to select dates from a calendar
however I can't seem to get it working could someone please advise if I am going about this the wrong way...
'jquery.datePicker.js & datePicker.css' can be downloaded at near the top of the page on...
1)copy the code in the '•jquery.datePicker.js ' inside my <script> tags in my view
2) copy the datePicker.css code into my css file
3) paste the following into the top of my view page:
<!-- jQuery -->
This does not work...iv tried doing the first demo and replacting the .js data inside my <script>tags wit $(function()
and then adding the following to .css
/* located in demo.css and creates a little calendar icon
* instead of a text link for "Choose date"
margin: 5px 3px 0;
background: url(calendar.png) no-repeat;
background-position: 0 -20px;
/* makes the input field shorter once the date picker code
* has run (to allow space for the calendar icon
could someone please tell me what I am doing wrong?
If you want to restrict the class so that it can only be seen by one particular external assembly, you use internal to limit the scope to the current assembly, and then you implement InternalsVisibleTo[^] to link this to the specific assembly.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
Which IP? Internal network? Public IP on the internet? "Localhost" is another name for 127.0.0.1, if one works, the other works. (Unless someone changed your HOST file)
From the network; check if firewalls are off, and try to fetch a blank HTML-testpage. Remember to set access-permissions in IIS.
If you are using local computer to access using ip address there should not be any issue only if DNS entry is set to redirect on another page. Secondly check if firewall stop your ip address from accessing the site ?
First try to simply add html page and check if it is also not working with ip address ?