Useful to be known

[kulrom]

Often we are overlooking the obvious without knowing some facts/limitations about vb.NET (and not only for vb.NET but Windows too)

For instance i found that this is useful to be known for all vb.NET programmers:

• If you are using Create method of Class File - note that path names are limited to 248 characters, and filenames are limited to 259 characters.​

i'll continue the list ... later ​

Please feel free to share your research findings and experience, with other programmers from the forum.

 

[kulrom]

It is important to realize that Visual Basic specific conversion functions are more powerful than the basic Parse and Convert.To methods. For example, look at how each of these routines handles converting a selection of sample strings into integers.



String: "12,500"; "12"; "12500"; "12500.00"; "$12,500.00"; "$12,500.10"; "&HFF"

Integer.Parse: Error; 12; 12500; Error; Error; Error; (VB syntax for FF) 255

Convert.ToInt32: Error; 12; 12500; Error; Error; Error; Error;

CInt: 12500; 12; 12500; 12500; 12500; 12500; Error



As the table clearly indicates, CInt is capable of successfully parsing a much wider range of acceptable text values into integers. You will obtain similar results if you compare the corresponding functions for other data types. Another standard Visual Basic function available in Visual Basic .NET, IsNumeric, correctly recognizes the same strings as CInt() as being numeric values. If you need to convert into a type other than the ones covered by CInt, CStr, and the other pre-existing conversion methods, you can use CType. CType takes two arguments, the variable or value to be converted and the desired type.

I hope it is worth to be known ... Cheers

 

[gripusa]

though you are right but kulrom , i would recomand to use new procedures, because we are moving to now typesafe and strict conversions.
for example "12,500" is rejected by Parse method and it is perfectly suiteable rather then converting it too 12500 as done by Cint.
and if you follow the standard procedures and practices of MS it will also recomend like this.
and other problem also arises if you are mixing the langs and then interopertbility problems can aslo arise.
similarly if you ever need to port your solution to other .NEts then it will cause problems.

 

[jmcilhinney]

though you are right but kulrom , i would recomand to use new procedures, because we are moving to now typesafe and strict conversions.
for example "12,500" is rejected by Parse method and it is perfectly suiteable rather then converting it too 12500 as done by Cint.
and if you follow the standard procedures and practices of MS it will also recomend like this.
and other problem also arises if you are mixing the langs and then interopertbility problems can aslo arise.
similarly if you ever need to port your solution to other .NEts then it will cause problems.

CInt doesn't convert to 12500 and Parse does not. An Integer is an Integer and the comma is simply for display purposes. The internal representation is the same. It will always be a problem porting from one culture to another if you have numbers contained in string variables, because a comma can mean something different in different places. That's why all integer values should always be stored in Integer variables and the only time we should be converting is when the user inputs something, in which case it should be safe to assume that they are using the local culture settings for number format.

 

[gripusa]

first of all, we cant be sure that a comma is for display purpose because it is safe to assume that "12,500" could be an integer as well as currency type.so just assuming that you need to convert the values from string to integer emitiing comma with Cint is not prefered , there are alot other ways to do this thing whcih still persist the nature of the values (like u mention u ll prefer to extract the int value from the user input).
and one more thing as for as potbility is concern, what i mean for portbility is not only cultures excahnge but also language exchanges as we often delve into the situiton to write a project into multiple lango;s (oh yeah dont bother if u look the world from one corner.)
and as for as storage is concern many things are stored into the integer format like ur time but it doest mean that u try to cast them into integers, as if compilers allows u but it may lead the other guys looking at your code to some wrong direction.

 

[jmcilhinney]

The comma IS for display purposes only because, where a string would actually contain the ASCII value for a comma, I guarantee you that the internal representation of an integer does not contain a comma. The internal represenation of an integer does not EVER change, but you can set your display settings to have it DISPLAYED in a number of different ways. The comma only gets added at the point the integer is displayed if the current settings require it.

Given that culture is a subcategory of language in the Windows sense, when I say "different cultures" I include different languages implicitly.

 

[TechGnome]

The comma is not necessarily for display only... there are cultures out there that use the comma as the decimal denoter.... and the . as a thousands separator..... So maybe the correct mumblings should be that the thousands separator should only be utilized during display, and in of itself should _not_ be saved as part of the data.

That said.... some times, you are going to get a comma in there.... Consider this, the user has the ability to enter a dollar amount for the max credit a given customer has. Idealy a masked text box would be used, formatted $#,##0.00 ... if the user enters 12345 the display we should get in the text box should b $12,345.00. Now to store this we only want to store 12345.0 .... which means the text box contents (a string) needs to be converted accordingly.

So sometimes it isn't the storage that gets in the way, but the UI can just as easily create complications.

Tg

 

[JuggaloBrotha]

an integer will never contain any decimal's or the equivalent as integers are whole numbers only, if you need to store whole numbers plus parts of a number then you would be using the Decimal, Single and/or Double variable types not Short, Integer or Long

with that said if you have a string "12,345.25" and you convert it to integer it'll be 12345 no comma's, no decimal points as those violate the integer type

as jmcilhinney pointed out... integer's can be displayed in many format's (including commas and decimal points) but that's only how the integer is displayed single, double, decimal, short, long can also be displayed in these same format's

The comma is not necessarily for display only... there are cultures out there that use the comma as the decimal denoter.... and the . as a thousands separator..... So maybe the correct mumblings should be that the thousands separator should only be utilized during display, and in of itself should _not_ be saved as part of the data.

That said.... some times, you are going to get a comma in there.... Consider this, the user has the ability to enter a dollar amount for the max credit a given customer has. Idealy a masked text box would be used, formatted $#,##0.00 ... if the user enters 12345 the display we should get in the text box should b $12,345.00. Now to store this we only want to store 12345.0 .... which means the text box contents (a string) needs to be converted accordingly.

So sometimes it isn't the storage that gets in the way, but the UI can just as easily create complications.

Tg

12345.0 the .0 is display only and not stored with the integer, 12345 is the only contents of the integer

 

[TechGnome]

12345.0 the .0 is display only and not stored with the integer, 12345 is the only contents of the integer

Ugh! I give up.... my point was missed.

Take 12345.67 and stuff that into your integer and smoke it.

You still want to store 12345.67.... and not 12,345.67......

Or better yet, take Kulrom's earlier example: "$12,500.10" and stuff it into an integer.... you CAN'T.... it generates an error (according to his table there) and for good reason....

The point I was trying to make is that you can't just blindly convert things... you have to know what you are doing with it.... but ..... garh! forget it.


Tg

 

[JuggaloBrotha]

Ugh! I give up.... my point was missed.

Take 12345.67 and stuff that into your integer and smoke it.

You still want to store 12345.67.... and not 12,345.67......

Or better yet, take Kulrom's earlier example: "$12,500.10" and stuff it into an integer.... you CAN'T.... it generates an error (according to his table there) and for good reason....

The point I was trying to make is that you can't just blindly convert things... you have to know what you are doing with it.... but ..... garh! forget it.

Tg

ok, yes we are talking about the same thing then i must have mis-interpreted what all was being said and yes if there is a decimal point that needs to be stored then integer isnt a good selection

 

[kulrom]

Well, it seems like you have missed what JM told you above, that it depends on the local culture settings for number format. However, i just wanted to point out that Visual Basic specific conversion functions are more powerful and flexibile than the basic Parse and Convert.To methods that doesn't mean we should use them of course, especially if we know that it will return wrong result. The point was that they wouldn't throw an exception and i thought it would be useful to be known.

Try this on your machine and compare result/s with mine ones.

 Dim i As String = CInt("12.5") 
Dim q As String = CInt("12,5")

MessageBox.Show(i) 'result of conversion was 125

MessageBox.Show(q) 'result of conversion was 12

Maybe you will catch the idea.

Whatever, i want to say again:
Please feel free to share your research findings and experience, with other programmers from the forum

Cheers

 

[kulrom]

http://www.codeproject.com/gen/work/standaloneprogrammer.asp