Probably very simple question but still trying to figure it out. I got many input doubles provided as strings in this format:
0.99
0.456
etc..
On my dev system when I convert it like:
CDbl(0.456)
It's fine, however on production I get SystemInvalidCastException.
I am not sure but I bet its about different systems symbols like dots or commas.
Is there any way to be independent from system configuration and trade my input strings to be correctly recognized as double?
I tried with this approach and seems it's working. Is this right way to do?
Double.Parse(value, CultureInfo.InvariantCulture)
Yes, it is the right way you're going.
The problem is indeed culture related. If you do not specifiy any culture it will default to the system's culture which will most likely be the reason for the code to work on one system but not on the other.
By specifying the invariant culture you ensure that the systems culture has no effect anymore on the casting.
Related
Context: a program written in VB.NET, developed/maintained in VisualStudio2012, targeting framework v3.5.
A few years ago, the program was in VB(6) and we "translated" it to VB.NET. As a result of the transformation, which was mostly automated, we still have quite a few places in the code where formatting of doubles (and dates/...) for textual presentation is processed as in:
Dim sValue As String = Microsoft.VisualBasic.Compatibility.VB6.Format(dblValue, "0.00")
Conversely, when we need to extract a Double value from such a string, we use
Dim dblValue As Double = CDbl(sValue)
CDbl "listens to" the System.Globalization.CultureInfo.CurrentCulture of the applications Thread, and this does NOT change when - during the run of the code - you change the Regional Settings through the Control Panel.
However, the VB6.Format as executed in the code starts out conforming to the currentCulture of the application (as you might expect), BUT apparently (I didn't know this, but accidentally found out) listens to CHANGES in the Regional Settings and responds immediately to any changes you make there during the program execution. This implies that the CDbl() and VB6.Format() become mutually inconsistent.
Of course, changing the Regional Settings during program execution is awkward, and moreover, if you wish to support it, you can manage it by catching the SystemEvents.UserPreferenceChanged (and -Changing) events and act upon their occurrences.
However, the "different behaviour" of VB6.FORMAT versus "normal" casts as CDbl(someString) regarding changes in the Culture/Regional Settings, strikes me as undesirable. Preferably you would have VB6.Format to comply ALWAYS with the application/thread-CurrentCulture, and you may THEN choose how you want your code to respond to userpreference changes. Furthermore, I'd like to gain some more insight in the issue.
My question, therefore, is:
Is there a way to compile/arrange/... things such that the (Microsoft.VisualBasic.Compatibility.)VB6.Format listens to the application-CurrentCulture and NOT respond - without "our consent" - to changes in Regional Settings?
Additional information:
The program is compiled with - for the visualbasic stuff - a reference in the project (VisualStudio2012) to:
C:\Windows\Microsoft.Net\Framework\V2.0.50727\Microsoft.VisualBasic.Compatibility.dll (and ...Data.dll).
Any "educational" information or suggestion is welcome. The issue is not causing any real problems in our program, but I feel that we should/might have a better understanding and maybe even methods to make things more robust.
The VB6 Format() function is actually an operating system function under the hood. VarFormat(), a function exported by oleaut32.dll. Backgrounder answer is here. The MSDN library article is here.
As you can tell from the MSDN article, the function doesn't permit specifying a culture or culture specific settings, other than the day-of-week rules. This function dates from 1996, life was much simpler back then. So what you see is now easy to explain, it cannot know anything about the .NET Thread.CurrentCulture setting.
I'm making the transition from VB6 to VB.Net (VS 2010) and have a basic rather than expansive understanding of the latter. I obviously have quite a bit of code to... I hesitate to use the word "upgrade" when "port" would be more apt given that the upgrade wizard in past versions of VS may as well have just commented out the code and said "Hey, why don't you re-start from scratch?"
In one procedure which I'm bringing across the Len() function was used to determine the length of a string variable. That still works in VB.Net (though I imagine that it's actually a call to the Strings.Len Method), but the other alternative is to just query the .Length property of the variable.
The question is which to use and why. I've looked through the relevant MSDN pages and all they seem to tell me is that the method/property exists. Nothing is said about performance issues, particularly when loops of large numbers of calls might be involved.
My question, then, is whether anyone is aware of any tested and confirmed benefit of using one approach over the other, or whether it's merely a question of personal preference. Any pointers on similar situations that I might encounter as I make the progression would also be appreciated though given the Stack Overflow guidelines it's just this one issue that I'm interested in seeing whether there's a specific answer to.
Because you're using VB.NET, your Strings can be Nothing and unless you explicitly check for that, most VB methods, including Len, will treat it the same as String.Empty i.e. "".
With Reflector you can see Len is implemented as a null check, returning 0 for Nothing and otherwise returning .Length, and the JITter will likely in-line the call.
So, if you're using other VB methods, I'd suggest using Len too, unless you know the String is not Nothing or check for Nothing everywhere.
So according to this:
Len, another classic BASIC function, returns the length of a string. System.String has the Length property that provides the same information. Is one better than the other?
Performance-wise, these two functions show little difference over 1000’s of iterations. There doesn’t appear to be any reason to prefer one over the other in this case plus there is no functional difference. I’m kind of partial to using the property value rather than the VB function since it encourages thinking of .NET strings as objects. However, at the core, it’s really only a personal preference thing.
If you trust their word, then there's your answer. Otherwise, coding up a test and iterating should give you the final answer.
I'm not sure about the specifics of the Len() method (my language of choice is C#), but I would say definitely go with the Length property. Length is a member of the System.String class, whereas Len() isn't.
My guess is that Len() is just a VB shim on top of the Length property. Someone could probably make the argument that using Len() is more idiomatic, from a VB point of view. I think I'd prefer to use the property built in to the class, rather than just use a different mechanism just because it's provided by the language.
The Len method is provided for backwards compatibility with old VB6 (and earlier) non-.NET code. There's nothing technically wrong with using it. It will work, and just as well, at that. But, it's better to use the new .NET way of doing things whenever possible. Outside of getting you more into the ".NET mindset", though, the only real tangible benefit of using String.Length is that it makes it easier to port the code to other .NET languages in the future.
In addition to #Andrew's post, the Len() is string function from Visual Basic run-time library where as Length is a property of System.String class of .net framework API.
Recently I faced problem with my old VB.Net code that was using Len() function. I upgraded my project to Core which was referencing the old VB.net dll file and it was using Len() function. I got run time compatibility error - Method not found: 'Int32 Microsoft.VisualBasic.Strings.Len(System.String)'
I have to change all such old function that Core has deprecated. So I stand by using String.Length over Len() as suggested by Steven Doggart.
I come from a C# background but am now working mostly with VB.Net. It seems to me that the above functions (and others - eg. UCase, LCase) etc. are carryovers from VB6 and before. Is the use of these functions frowned upon in VB.Net, or does it purely come down to personal preference?
My personal preference is to stay well away from them, but I'm wondering if that is just my C# prejudice.
I've come across a couple of issues - particularly with code converted from VB6 to VB.Net, where the 0 indexing of collections has meant that bugs have been introduced into code, and am therefore wary of them.
The reason that those functions are there in the first place is of course that they are part of the VB language, inherited from VB 6.
However, they are not just wrappers for methods in the framework, some of them have some additional logic that makes them different in some ways. The Mid function for example allows that you specify a range that is outside the string, and it will silently reduce the range and return the part of the string that remains. The String.Substring method instead throws an exception if you specify a range outside the string.
So, the functions are not just wrappers, they represent a different approach to programming that is more in line with Visual Basic, where you can throw just about anything at a function and almost always get something out. In some ways that is easier, as you don't have to think about all the special cases, but on the other hand you might want to get an exception instead of getting a result when you feed something unreasonable to a function. When debugging, it's often easier if you get the exception as early as possible instead of trying to trace back where a faulty value comes from.
Those options are for backward compatibility.
But, it will be better for people to use framework classes/methods to ensure consistency.
Having said that, VB6 functions are easy to understand. So, it should not be an issue for someone who has the VB background.
EDIT: Also, some of the overloads available with framework classes, might not be available with an equivalent of a simple VB6 like statement. I cannot remember of any, as of now - But this is what I think, could be a better reason to use framework classes/methods.
There will be special cases, but, Hands down, use the VB6 versions, unless you care about the difference between a string being "" and Nothing.
I was working on a big project where different programmers using both ways, the code where people used MyString.SubString(1) was blowing up while Mid(MyString,2) was working.
The two main errors for this example: (Which apply in various ways to others as well)
(1) String can be nothing and you have to check before running a method on it. Limitation of the OO notation: You can't call a member method if the object is nothing, even if you want 'nothing' or (empty object) back. Even if this were solved by using nullable/stub objects for strings (which you kind of can using "" or string.empty), you'd still have to ensure they're initialized properly - or, as in our case - convert Nothing to "" when receiving strings from library calls beyond our control.
You are going to have strings that are Nothing. 90% of the time you'll want it to mean "". with .SubString, you always have to check for nothing. With the VB versions, only the 10% about which you'll care.
(2) Specifically with the Mid example, again, 90% of the time if you want chars 3-10 of a 2 char string, you'll want to see "" returned, not have it throw an exception! In fact, you'll rarely want an exception: you'll have to check first for the proper length and code how it should behave (there is usually a defined behaviour, at the very least, a data entry error, for which you don't want to throw an exception).
So you're checking 100% of the time with the .Net versions and rarely with the VB versions.
.Net wanted to keep everything into the object-oriented philosophy. But strings are a little different than most objects used in subtle ways. MS-Basic wasn't thinking about this when they made the functions, it just got lucky - one of the strengths of functions is that they can handle null objects.
For our project, one may ask how Nothing strings got into our flow in the first place. But in the end, the decision of some programmers to use the .Net functions meant avoidable service calls, emergency bug fixes, and patches. Save yourself the trouble.
I would avoid them. Since you've mentioned them it sounds as though you've inherited some VB6 code that was possibly converted to a VB.NET project. Otherwise, if it was a new VB.NET project, I see no value in using the VB6 methods.
I've been on a few VB6 to VB.NET conversion projects. While I am familiar with the names and the difference in 0 based indexing, any code I came across got refactored to use their .NET equivalents. This was partially for consistency and to get the VB6 programmers on that project familiar with the framework. However, the other benefit I've found in refactoring is the ability to chain method calls together.
Consider the following:
Dim input As String = "hello world"
Dim result As String = input.ToUpper() ' .NET
Dim result As String = UCase(input) ' VB6
Next thing you know, I need to do more work to satisfy other requirements. Let's say I need to take the substring and get "hello," which results in the code getting updated to:
Dim result As String = input.ToUpper().Substring(0, 5) ' .NET
Dim result As String = Mid(UCase(input), 1, 5) ' VB6
Which is clearer and easier to modify? In .NET I just chain it. In VB6 I had to start at the beginning of the method, then go to the end of it and add the closing parenthesis. If it changes again or I need to remove it, in .NET I just chop off the end, but in VB6 I need to backtrack to the start and end.
I think there's value in using the .NET methods since other .NET developers that join the project later, especially those from a C# background, can easily pick it up.
Nice as the Tcl libraries math::bignum and math::bigfloat are, the middle ground between the two needs to be addressed. Namely, bignums which are in different radices and have a radix point.
At present math::bignum only handles integers (afaict) and math::bigfloat won't let you specify different radices to math::bigfloat::fromstr (ditto).
Does anyone know of a library, for any of the major scripting languages (e.g. Tcl, Perl, Python, Ruby, Lua) or less major ones (newLISP for example), which implements bignums in different radices with handling for radix point?
bignumber.js is a Javascript library that handles numbers with a radix point in bases from 2 to 36.
I couldn't find any libraries for this, but I haven't looked for long.
But you can work around the problem similar to what you would do if you want 64-bit datatypes, but only 32-bit datatypes are available. With the libraries you already have, you should be able to represent a number in base b like this:
ABCDEF.GHIJKLMN
can be split to the two bignums ABCDEF and GHIJKLMN. GHIJKLMN in fact is representing GHIJLMN / pow(b, length(GHIJKLMN)) => GHIJKLM / pow(b, 8). Now you can overwrite the operators you need which should be possible for things like +, -, *, /. If you need more things like sqrt, log or pow, this workaround will get too complex and you should really look for a library.
Your best bet is to use GMP (libgmp).
I myself have looked long and hard for a .NET version without luck.
The project I am currently working on requires a lot of hexadecimal numbers to be entered into the code.
I once saw a pic of an old keyboard with a hexadecimal numpad (has A-F letters on it also) replacing the normal numpad. Anyone know where I can get one of these?
IPv6 Buddy -keypad should work well for hexadecimal input.
http://www.ipv6buddy.com/
If you can get your hands on one of the retired space shuttles, they have one!
I have an old Heathkit learning toy with a hex numpad because the only way to program it was to assemble code by hand (it came with a 6800 manual and some notepads) into the online monitor. This was actually fun!
Mine is missing the 'D' button however.
Great idea with the programmable keypad. I think i am going to pick up one of these: DX1 input system. Works for any reconfiguring I might want to do.
Is this the one you're talking about?
funky http://www.cpmuseum.com/Exhibits/Apple%20Lane/7603/7603-0005/images/000%20Front%20View.jpg
While this has a lot of "gee whiz" appeal, I have to say:
You have two hands. Use them. A-F are all reachable with the left hand on a standard keyboard while your right hand is on the num-pad. Instead of putting muscle-memory time into some arcane Hex-pad, you'll be learning to touch-type with your left hand, which has application outside your current project.
Better yet, come up with a smarter way of getting the hex codes into your code. Write a script that extracts them from your data-source and into your code as symbolic variables... or whatever.
EDIT
Ok, I'll give you the benefit of the doubt. Lets assume you're working on a hardware project and need to provide a specialized interface for your user. Maybe a programmable keypad would fit the bill?
Not sure of the specifics right now, but I'm pretty sure you can easily write a keyboard remapper. You could remap the QWASDF keys to ABCDEF in order to type them more quickly. That way you could use 2 hands to type. Or if you are in control of the program they are being typed into, you could just translate the keys in code on the fly. You also might want to try out the Microsoft Keyboard Layout Creator