4 ms·

VB6 is basically as simple as a form builder to start with. You start with designing forms for every screen you need and then write logic for specific events, l

VB6 is basically as simple as a form builder to start with. You start with designing forms for every screen you need and then write logic for specific events, like a button click event etc. It was much more simpler than say a modern framework based on MVC.

douche 10y ago
I don't see why you couldn't still do this with WinForms in VB.NET or C#
- criddell 10y ago
  You can, but it's not as simple. VB6 would spit out an exe that could often be installed by just copying it to the client machine. You could also generate DLLs that other applications could easily load and use. These days you can still do it, but it's much more complicated (i.e. registration-free COM).
  - marvin 10y ago
    I'm pretty sure that Windows Forms in C# is still pretty lenient in this regard. It'll give you an .exe file that, if you only reference a single project in your solution, you can copy directly onto a target machine and run. If you're referencing multiple projects, it'll compile DLLs from them and you'll need to copy over those as well. I love Windows Forms for prototyping stuff for this reason. There's much less overhead and GUI prototyping is super fast. It falls apart if you have a complex application that needs to be maintained over time by multiple people, but it's great for just getting some simple task done. I think the current generation of web programmers miss out on some really useful tools by always thinking in terms of client/server. It's not always that you want or need a webapp to solve your problem.
  - cm2187 10y ago
    All of what you mention is doable in VB.net. VB.net introduces a few rough edges, everything is class based, you have namespaces, lambdas, etc. But honestly the step from VB6 to VB.net is a pretty modest step, and when you have tasted generics, linq and its collection extensions functions (OrderBy, First, Last, Max, etc), a consistent collection indexing (VB6 switches between 0 based and 1 based), got rid of that useless "set" keyword, made all function parameters byval by default, which avoids having to write byval before every parameter, used lambdas (there are quite many problems where it is just nice to give a callback as a parameter), type inference, initializing a variable on the same line it is declared, multi-threading, etc, you won't go back to VB6. I fully accept the non backward compatibility of the code argument. If it's a big project, and it's working, and it's in VB6, I can understand not upgrading it. But in term of functionality VB6 is way behind modern VB.Net.
    - criddell 10y ago
      It's been a while since I've dealt with them, but I know we had a bunch of DLLs written with VB6 that we could use the standard way: LoadLibrary load the DLL, then GetProcAddress to find the function, then call it. We converted some of these to VB.Net and then had to jump through a bunch of hoops (reg-free COM) to use it in that way.
      - cm2187 10y ago
        I guess it depends what you want to consume your DLL from. A .net DLL can be consumed by a .net application without any form of registration, and I would assume this would be the typical use case. It's only if you want to expose your DLL with a COM interface to be used by other languages that you need a COM registration.
        deleted 10y ago
        [deleted]
    - catnaroek 10y ago
      The step from VB6 to VB.NET is far from “modest”. There are many fundamental differences between the two. For the most part VB.NET is a strict improvement over VB6, but there are a few things VB6 does better than VB.NET: (0) Reference counting: VB6 cleans up arbitrary resources (not just memory) in a deterministic fashion. Think RAII, minus the dangling references and associated gotchas. In business application programming, not worrying whether you closed database connections in the right places is a major productivity boost. (1) Programmer-defined lower and upper array bounds. You iterate an array's index range with `For idx = LBound(arr) To UBound(arr)`. It's as clear as it gets. (2) Dyamically resizable arrays. VB6's `ReDim` doesn't give you a new array object - it really changes the size of the existing one. By contrast, VB.NET's `ReDim` is just sugar for replacing a fixed-size array with another, which is why it can only be used locally inside a method. The officially sactioned solution is to use `List`s, but `List`s can't be multidimensional.
      - cm2187 10y ago
  - ern 10y ago
    You can do this in Windows Forms. You can (or could) drag a DB connection onto a form, hook it up to a grid, and have a CRUD app out in minutes. You could even do that in ASP.NET Webforms. But for cultural and technical reasons, it is frowned upon, even when wholly appropriate.
deleted 10y ago
[deleted]

douche 10y ago

I don't see why you couldn't still do this with WinForms in VB.NET or C#

criddell 10y ago
You can, but it's not as simple. VB6 would spit out an exe that could often be installed by just copying it to the client machine. You could also generate DLLs that other applications could easily load and use. These days you can still do it, but it's much more complicated (i.e. registration-free COM).
- marvin 10y ago
  I'm pretty sure that Windows Forms in C# is still pretty lenient in this regard. It'll give you an .exe file that, if you only reference a single project in your solution, you can copy directly onto a target machine and run. If you're referencing multiple projects, it'll compile DLLs from them and you'll need to copy over those as well. I love Windows Forms for prototyping stuff for this reason. There's much less overhead and GUI prototyping is super fast. It falls apart if you have a complex application that needs to be maintained over time by multiple people, but it's great for just getting some simple task done. I think the current generation of web programmers miss out on some really useful tools by always thinking in terms of client/server. It's not always that you want or need a webapp to solve your problem.
- cm2187 10y ago
  All of what you mention is doable in VB.net. VB.net introduces a few rough edges, everything is class based, you have namespaces, lambdas, etc. But honestly the step from VB6 to VB.net is a pretty modest step, and when you have tasted generics, linq and its collection extensions functions (OrderBy, First, Last, Max, etc), a consistent collection indexing (VB6 switches between 0 based and 1 based), got rid of that useless "set" keyword, made all function parameters byval by default, which avoids having to write byval before every parameter, used lambdas (there are quite many problems where it is just nice to give a callback as a parameter), type inference, initializing a variable on the same line it is declared, multi-threading, etc, you won't go back to VB6. I fully accept the non backward compatibility of the code argument. If it's a big project, and it's working, and it's in VB6, I can understand not upgrading it. But in term of functionality VB6 is way behind modern VB.Net.
  - criddell 10y ago
    It's been a while since I've dealt with them, but I know we had a bunch of DLLs written with VB6 that we could use the standard way: LoadLibrary load the DLL, then GetProcAddress to find the function, then call it. We converted some of these to VB.Net and then had to jump through a bunch of hoops (reg-free COM) to use it in that way.
    - cm2187 10y ago
      I guess it depends what you want to consume your DLL from. A .net DLL can be consumed by a .net application without any form of registration, and I would assume this would be the typical use case. It's only if you want to expose your DLL with a COM interface to be used by other languages that you need a COM registration.
      - deleted 10y ago
        [deleted]
  - catnaroek 10y ago
    The step from VB6 to VB.NET is far from “modest”. There are many fundamental differences between the two. For the most part VB.NET is a strict improvement over VB6, but there are a few things VB6 does better than VB.NET: (0) Reference counting: VB6 cleans up arbitrary resources (not just memory) in a deterministic fashion. Think RAII, minus the dangling references and associated gotchas. In business application programming, not worrying whether you closed database connections in the right places is a major productivity boost. (1) Programmer-defined lower and upper array bounds. You iterate an array's index range with `For idx = LBound(arr) To UBound(arr)`. It's as clear as it gets. (2) Dyamically resizable arrays. VB6's `ReDim` doesn't give you a new array object - it really changes the size of the existing one. By contrast, VB.NET's `ReDim` is just sugar for replacing a fixed-size array with another, which is why it can only be used locally inside a method. The officially sactioned solution is to use `List`s, but `List`s can't be multidimensional.
    - cm2187 10y ago
- ern 10y ago
  You can do this in Windows Forms. You can (or could) drag a DB connection onto a form, hook it up to a grid, and have a CRUD app out in minutes. You could even do that in ASP.NET Webforms. But for cultural and technical reasons, it is frowned upon, even when wholly appropriate.

deleted 10y ago

[deleted]