• nope (unregistered)

    "Visual Basic .NET is actually not a terrible language" - aaaaaand you lost me.

    it is.

  • (nodebb)

    For fun, take that (or any VB.NET that compiles), and reverse into C# ---- <GRIN>

  • RussellF (unregistered)

    Two corrections to this post: At the time when "Bob Flemp" (not his real name, obviously) wrote this, we did not have what I would consider proper version control. I had to go through a long office-politics struggle to get it implemented (what I eventually ended up doing was telling my boss that we should get a real QA guy rather than have the programmers test each others' code -- I knew that any competent QA guy would see the benefits of real version control, and this got me an extra ally in my efforts to get it implemented). Also "almost all of the exceptions being thrown would be real exceptions that we need to handle properly" is backwards. Since the file will almost never exist, almost all of the exceptions are "file doesn't exist" exceptions. The problem (well, a problem) with this is that throwing an exception is computationally expensive, and this setup means that an exception will be thrown almost every time this method is called.

  • Industrial Automation Engineer (unregistered)

    Lucky you. My inherited (VBA-)code is littered with "On Error Goto ErrHandler" and the anti-pattern "While True .... (break on some conditon(s)) ... Loop It's a complete WTF that derserves its own article.

  • MaxiTB (unregistered)

    I'm confused - File.Delete() does NOT return a status code, it throws exceptions. Kill is basically just a wrapper around File.Delete().

    https://docs.microsoft.com/en-us/dotnet/api/system.io.file.delete?view=net-6.0 https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualbasic.filesystem.kill?view=net-6.0

    In regard of VB.net - all .net languages are based on the .net framework. The whole idea was one unified ISO-standardized framework (runtime, type system, libraries) for all languages in contrast to Java which followed the one language to replace everything approach.

    So yes, in a sense you can write perfectly solid and clean VB.net code with similar quality standards to C# (in some regards features are not implemented) using the same packages as long as they are CLScompliant (attribute for case insensitivity).

  • RussellF (unregistered) in reply to MaxiTB

    You're right about Delete not returning a status code, but you're wrong about Kill being a wrapper for Delete. Kill functions quite differently; for one thing, it allows wildcards to delete multiple files at once; for another, it can throw a FileNotFoundException, which Delete can't.

  • FRIDTJOF WEIGEL (unregistered) in reply to RussellF

    "Computationally Expensive"

    Sure. Deleting a file is more expensive -- the exception won't make a difference. The "try 10 times" nonsense? Probably part of trying to run the code on a network. The sequence was probably -- delete didn't work until some time after the call returned when running on a share (may have been NFS). The rename didn't work until after the file was erased. So, try and try again, for up to a second. The "t" nonsense -- suppress the error if so demanded.

  • MaxiTB (unregistered) in reply to RussellF 
        Public Shared Sub Kill(ByVal PathName As String)
        If PathName Is Nothing OrElse PathName.Length = 0 Then Throw New System.ArgumentException("The path is not of a legal form.")
        Dim str_parent_dir, str_file_to_delete As String
        Dim last_ch, i As Integer
        Dim di As DirectoryInfo
        Dim tmpFile As FileInfo()

        last_ch = PathName.LastIndexOf(Path.DirectorySeparatorChar)
        If (last_ch = -1) Then
            str_parent_dir = Directory.GetCurrentDirectory()
        Else
            str_parent_dir = PathName.Substring(0, last_ch)
        End If

        str_file_to_delete = PathName.Substring(last_ch + 1, PathName.Length - last_ch - 1)

        di = New DirectoryInfo(str_parent_dir)
        tmpFile = di.GetFiles(str_file_to_delete)
        If Not (tmpFile.Length = 0) Then
            For i = 0 To tmpFile.Length - 1
                File.Delete(str_parent_dir & Path.DirectorySeparatorChar.ToString() & tmpFile(i).Name)
            Next
        Else
            Throw New System.IO.FileNotFoundException(" No files found matching: " + PathName)
        End If

    You were saying?

  • MaxiTB (unregistered) in reply to RussellF

    To clarify my initial statement: Kill() is a wrapper for VB6 Kill() around File.Delete(). Sorry for the my shorthand form, I often skip details like that because usually I get the feedback I already put to much feedback into my responses.

    And no, Kill() can throw new FileNotFoundException(), however it's not consistent between runtimes. The posted code up there is the Mono implementation (which is in line with the .net framework implementations), on the other hand the .net core implementation of Kill() throws new FileNotFoundException() when no file was deleted.

    https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.VisualBasic.Core/src/Microsoft/VisualBasic/FileSystem.vb

    But both use File.Delete internally and as you state correctly, the wrapper implements the directory lookup of VB6 Kill().

  • SD (unregistered) in reply to Industrial Automation Engineer

    It could be worse. Did they ever remove 'On Error Resume Next'?

  • ObJection (unregistered)

    VB .NET and C# do have a lot of similarities, but they are definitely not the same. Anthony D. Green has an exhausting (albeit slightly out-of-date) list of differences from little things like when field initializers run to major things like the difference between Select Case and switch.

    https://anthonydgreen.net/2019/02/12/exhausting-list-of-differences-between-vb-net-c

  • Loren Pechtel (unregistered)

    While this has problems I don't think it's nearly as evil as it's being portrayed.

    I believe this is operating in a network environment where another program is also messing with the situation.

    First, scanning the directory doesn't work--you're getting an out of date picture. Somebody tried it and discovered it can't be trusted.

    Second, the fast retry actually does make sense--I've done something similar pulling the wool over the eyes of a program that had no idea networks even existed. No, that job "Next" you thought you had has never existed, your state files do not contain the information you think they do. The program was happily looking at a totally potemkin directory--a program that expected everything to be entered manually actually had all it's data created elsewhere.

  • SomeGuyOnTheInternet (unregistered) in reply to Loren Pechtel

    I agree with this. My guess is that this code was originally written in VB6 (or earlier) and it could be twenty years old - the three-letter type prefixes suggest that. Any code that manages to survive that long can't be too bad, and to judge it by the coding standards of today is a bit churlish.

    Moreover, Microsoft going to the great lengths that they did to keep old VB6 code working with minimum changes when they made the seismic change from vbrun to .NET Framework is one of the great triumphs of that company.

  • Old timer (unregistered)

    If, at some stage, "easy to port VB6" was an objective, it was a pretty lame half-assed attempt.

    Not like 'easy to port c', which was a real objective, with the global aim that a c programmer should be comfortable in the new environment, and that the new environment should do as a c programmer would intuitively expect.

    The universal response of the VB6 community was that the porting tools were ineffective, with the real work still to be done, and that except for trivial demonstrations, VB6 applications would have to be rewritten -- probably in c#, because when a re-write is required, selecting a lame half-assed target would be a mistake.

  • Anonymous Coward (unregistered)

    I have seen this behaviour from Windows in C++ code, where the attempt to rename a directory fails. A temp directory is created, a set of files written, all file handles closed and the rename from the temp directory to the required directory which has been checked and does not exist fails. I believe that the problem is the anti-virus taking time to scan the written files which locks the files and prevents the rename. It is then necessary to wait until the AV has finished its work before the rename succeeds. The only solution was to have a retry count with a sleep to rename the directory. The retry loop is only needed on Windows. The Linux version works without needing the retry loop.

  • clubs21ids (unregistered)
    Comment held for moderation.
  • Anonymous Coward (unregistered)

    As other commenters pointed out, this is obviously a copy/paste from legacy Visual Basic into a Visual Basic .NET application with minor changes. If .NET standards were applied, then the code could be placed in a translator and spit out an (almost) one-to-one C# equivalent. Typically when doing legacy conversions from VB6 or earlier, I will rewrite it in Visual Basic .NET first then convert the VB.NET to C#; I do this because generally all I need to do is import the Microsoft.VisualBasic namespace to get the legacy code to run and then I can make minor changes until the legacy code is updated; the final step in C# is the translation and typically some optimization (like LINQ for readability or maybe minor refactoring).

    However, I'd like to point out that even the refactored code could be improved. I would suggest using Path.ChangeExtension method for the filenames, change the global variables to be arguments in the method, change the method from a sub routine to a function that returns a String, return the destination filename on successful attempt of renaming the file.

  • (nodebb)

    VB.NET and C# both run on the .NET framework. I hate it when idiots saw VB.NET is terrible. I use C# on daily basis but have but have worked on a lot of VB.NET stuff also. VB.NET is still better than Ruby and Python :)

  • james davis (unregistered)

    Crypto Recovery Services Crypto Recovery Services, Houston, TX. 1 talking about this. How to recover lost, stolen, hacked, forgotten and scammed crypto currencies from fraudulent investment platforms Website: www.cryptoreclaimfraud.com

Leave a comment on “Rename This”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article