I have reviewed your code and I seriously recommend you do not follow this course of action:
str = str.Replace(arr(i), "X" & <converted number>)
you see, you search and replace the entire original string and hope it will change just the instances you want to deal with.
Consider the situation where you have the following X values in succession:
X0.036
X0.9
The first X is converted from 0.036 to 0.9144, you find 0.036 and replace it with 0.9144. Your file now looks like:
X0.9144
X0.9
Then when processing the second X, you determine that 0.9 should be replaced by 22.86. Your file now looks like:
X22.86144
X22.86
What actually happens in your case is a related condition. The code encounters X0.9 and causes all values in the file to become X22.86, so the later values of
X0.9375 become
X22.86375. They are subsequently not subject to replacement because Find:X0.9375/Replace:X23.8125 fails to find any occurrences
-
Your algorithm would be better off splitting the string into an array then altering the individual array elements, then rejoining them. Additionally, your algorithm relies on spaces to delimit all the values. Given that is cannot be guaranteed that a space will precede every newline i do not recommend you persist with space as [the only] delimiter
I offer some other comments on your code:
Your functions and subs do not have access specifiers (public/protected/private etc). You should endeavour to learn the differences and use them appropriately
Your code relies on implicit conversions permitted when Option Strict is off, but some people feel that Option Strict Off promotes sloppy programming and increases the risk of software bugs developing. Though a personal decision, there is more to be gained from following a stricter and more specific mindset when programming, particularly with migration to other languages. To enable Option Strict, set the appropriate combo box in the project's compilation properties
The code makes inconsistent use of .NETcore and MS.VB compatibility methods; you say string.Replace, but Split(string). Again, largely the opinion of the individual, some people feel that using the provided compatibility methods is a cling to legacy VB and should be discarded if the individual wishes to progress to other .NET syntaxes such as C# or future revisions of VB where the legacy code is deprecated, or indeed if the goal is simply to more accurately embrace the OO underpinnings of any .NET syntax.
You can have the compiler assist you with this if you choose; in a project references, remove the reference to Microsoft.VisualBasic.dll and legacy syntax becomes a compiler error.
Note; there are some features provided by the legacy libraries that may not be present in .NET core. One example I can think of is reading of CSV files; I use a third party library rather than the readers in Microsoft.VisualBasic because I first had the need to read CSV when working in C#
All in, a good and creative solution for the problem, simpler to look at than my regex offering and more compatible with very early versions of the framework! Well done 