Why? Just why?
-
I know, lets keep re-comparing strings as it's cheap and easy. Thank you VB6; the gift that keeps on giving.
Public Function sConvertCase(sInString, lType As VbStrConv) As String
Dim sReturn As String
Dim lPos As Long
Dim lStart As Long
Dim lNext As Long
On Local Error Resume Next
sReturn = StrConv(sInString, lType)
If lType = vbProperCase Then
'check for This-That, O'Sumin ,McSumin, von Sumin, MacName (must be input as MacN...)
lPos = 0
Do
lStart = lPos + 1
lPos = InStr(lStart, sReturn, "Mc")
lNext = InStr(lStart, sReturn, "Mac")
If lNext > 0 And (lNext < lPos Or lPos = 0) Then
lPos = lNext
End If
lNext = InStr(lStart, sReturn, "O'")
If lNext > 0 And (lNext < lPos Or lPos = 0) Then
lPos = lNext
End If
lNext = InStr(lStart, sReturn, "Von ")
If lNext > 0 And (lNext < lPos Or lPos = 0) Then
lPos = lNext
End If
lNext = InStr(lStart, sReturn, "-")
If lNext > 0 And lNext < lPos Or lPos = 0 Then
lPos = lNext
End IfIf lPos = 0 Then ElseIf Mid$(sReturn, lPos, 1) = "-" Then Mid$(sReturn, lPos + 1, 1) = UCase$(Mid$(sReturn, lPos + 1, 1)) ElseIf Mid$(sReturn, lPos, 2) = "Mc" Then Mid$(sReturn, lPos + 2, 1) = UCase$(Mid$(sReturn, lPos + 2, 1)) ElseIf Mid$(sReturn, lPos, 3) = "Mac" Then If Mid$(sInString, lPos, 3) = "Mac" And Mid$(sInString, lPos + 3, 1) = UCase$(Mid$(sInString, lPos, 3)) Then Mid$(sReturn, lPos + 3, 1) = UCase$(Mid$(sReturn, lPos + 3, 1)) End If ElseIf Mid$(sReturn, lPos, 2) = "O'" Then Mid$(sReturn, lPos + 2, 1) = UCase$(Mid$(sReturn, lPos + 2, 2)) ElseIf Mid$(sReturn, lPos, 4) = "Von " Then Mid$(sReturn, lPos, 1) = "v" End If Loop While lPos > 0 End IfDone:
sConvertCase = sReturn
End FunctionHoly crap. Here's what you do. Install Strawberry Perl on that machine, and have that function shell out to a perl one-liner. It'll still be more efficient and less dain bramaged.
-
Holy crap. Here's what you do. Install Strawberry Perl on that machine, and have that function shell out to a perl one-liner. It'll still be more efficient and less dain bramaged.
mikepwilson wrote:
Install Strawberry Perl
No, I don't think so...
mikepwilson wrote:
less dain bramaged
you were saying? :laugh:
-
mikepwilson wrote:
Install Strawberry Perl
No, I don't think so...
mikepwilson wrote:
less dain bramaged
you were saying? :laugh:
I dunno man, consider it. Perl is the language for programmers who have actual work to get done.
-
You thought that code was bad?? How about this[^] little gem, written in C#?? I hate hearing crap about VB being the sole domain of horrible code.
A guide to posting questions on CodeProject
How to debug small programs
Dave Kreskowiak:wtf:
What do you get when you cross a joke with a rhetorical question?
-
I can't see how it's connected to VB6 (or any language for that matter)...It's a pure human problem...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
Actually string handling in VB6 is particularly dire. The "natural" syntax encourages you to build strings from smaller ones, but the implementation just reallocates. I remember seeing some code building particularly long strings that had exponentially increasing performance time on long input - entirely due to naive string-handling. There are workarounds, but the language has to take some blame here.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
You thought that code was bad?? How about this[^] little gem, written in C#?? I hate hearing crap about VB being the sole domain of horrible code.
A guide to posting questions on CodeProject
How to debug small programs
Dave KreskowiakNot the sole domain, but a particularly frequent one due to some bad language design decisions. JavaScript is similarly plagued, and of course one can always create bad code in any language, just some make it the default way of working for many.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Actually string handling in VB6 is particularly dire. The "natural" syntax encourages you to build strings from smaller ones, but the implementation just reallocates. I remember seeing some code building particularly long strings that had exponentially increasing performance time on long input - entirely due to naive string-handling. There are workarounds, but the language has to take some blame here.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Erm, isn't it the same as natural string handling in C#? Yes, I do know you should use a StringBuilder, but a new coder would not necessarily know that.
