As I was reading, apparently the ability to group up classes similar to the .NET namespaces has been underlying all along. I don't think you can mix them inside each other like you can in .net, but that's not an important feature anyways.
I've never seen anyone do this though. Are there any known examples of this? For example the System.IO and System.Diagnostics groupings would be a common request.
So, I've built my own set of class collections for commonly used functions. All of them use the API to duplicate the .NET functions.
Is anyone interested in contributing classes to this project? Any interest in seeing this as open source?
I figured that some members here may be very against the notion of .Net, but this can help bring fresh code examples over into vb6.
The purpose of this is for back-porting the majority of .NET code to VB6. I realized that much of the common .NET classes can be done in VB6 with the API, rather than calling an Interop dll through.NET.
So I built a back-porter to help convert .net to vb6. While the vb6 classes are extended with .net capabilities to meet half way. The results are very good so far, and much less time consuming than porting it all by hand.
Thank you guys, I do remember this project from way back. However, only a few classes are common enough to be practical, and not many are using the API to duplicate functionality.
Most importantly it is not organized in the .NET-like way. Although I did find a few tidbits to use in my project. Thanks.
For example, "System.IO.File" should be easily available. When I type System dot, I should get intellisense to display the available nested classes, functions, and properties within the container class. Then choose IO, press space to prompt intellisense to display the classes/properties inside IO. Then choose FILE to prompt intellisense to display the functions file functions available inside etc.
I don't think many people knew/know how to do this.
I don't think many people knew/know how to do this.
Can you do this in VB6 w/o run-time overhead?
The only thing I can come up is a predefined=true class named System that has a property IO that returns a predefined=true class named IO that has a property File etc.
The only thing I can come up is a predefined=true class named System that has a property IO that returns a predefined=true class named IO that has a property File etc.
cheers,
</wqw>
Good question, I have not tested this with a perf counter against a regular classs set up. There are two options, one of which allows for quicker intellisense, or less overhead. I believe that the overhead happens at load time when the class is initialized, for example in a module. Clearly, not all projects would require all of the classes, so I am trying to make an addin that can automatically remove unused classes. The idea is that the full project is made available as a template to start from. Then the add-in will remove unused classes.
The way I am making the class collection is with the class builder to generate the code automatically. Though not hard once you learn how to manually write it. For example, from the menu click: Project - Add class module - vb class builder - Add new class button. Then select that class, and add another class to it, to nest within the parent container class.
Note: the second nested child class dialog window will have the available tab option called "Object creation".
Child class options:
A. Slower parent startup and faster property access.
B. Faster parent startup with slower property access.
Here is a basic starter project with a nested StopWatch class in the .NET style. So you type System.Diagnostics.StopWatch.StartNew to use the initialization method.
You can bring this further into the module and define Diagnostics at the public scope, ie
Public Diagnostics as new Diagnostics
That allows you to type
Diagnostics.StopWatch.StartNew
And so on.
Remember to define your functions/sub as Friend not public/private.
User defined types should be in the scope of a public module, so they can be seen by your nested private class functions.
Then you can use them as the structures to return multiple values from a function return, or pass them ByRef as parameters to return a group of values essentially.
Somebody seems to be far off in the weeds or something.
The way VB6 namespaces work follows COM/MIDL conventions for type libraries. The top level of the namespace is the type library name. Next comes the module, interface, or coclass name. Then comes the member name.
So you could define a type library and name it SHLWAPI, within that you could define a set of modules (e.g. Strings, Paths, Registry, etc.) and then within that you could define the function calls (e.g. ChrCmpI, IntlStrEqN, etc.).
After compiling the MIDL to a TLB your VB6 Projects can reference it. Then in code you can type things like:
Code:
If SHLWAPI.Strings.ChrCmpI(Char1, Char2) Then
I don't have a clue why you'd want to define a bunch of classes containing static instances of other classes just to expose the functions defined in a flat DLL. That is pretty convoluted, confusing, and unnecessary. Just create a typelib and be done.
If such functions need wrapper logic to be more usable in VB6 then the answer is very simple. You write and compile a VB6 ActiveX DLL containing classes with Instancing = GlobalSingleUse. This is probably a lot closer to what the Tower of Babel (.Net "Framework") actually is: a big pile of DLLs.
Sure, that's true you could create a typelib, but that defeats the purpose, being able to mute unused classes from a default template. Thanks for the related yet peripheral info. It seems like a bit of extra work which now exposes it as a reference, which is not desired. Feel free to post a sample project for this secondary solution though.
I think TTn's idea is valuable. If all the features of dotNET are implemented in exactly the same way in VB6, it must be a very interesting thing. On the one hand, we can continue to dig the potential of VB6, on the other hand, we can back-port the majority of .NET code to VB6, thus expanding the VB6 code resources. Now, on the Internet, there are too few valuable resources about VB6. Many times I have to search Delphi and dotNET source code and then convert it to VB6 code.
In addition, this idea/project is suitable for multiple people to participate in, suitable for the power and advantages of the VB6 community. Many people complain that they are unable participate in the development of RC5, then these people can fully participate in the TTn's project, through the folk-power (VB6 community power) to develop a framework that can compete with Microsoft .NET Core. Actual action is much better than complaining.
Nice, thanks! There are a few API's in the hwoarang link that I will be using for data types. Some from the Corlib project too. Thanks again guys.
When I complete these common net types I will post the template project v1, and then we can enhance it from there, if anyone is interested. I am still learning a few details in how to set things up without the builder. Luckily I have the books to help a bit. My goal is to get the conversion as exact as possible with only minor differences when time appropriate.
The back-porter still needs some work for various project file types. I can't convert it all in one pass of the project without being specific to the different file types. There may be better ways to do this too, so I need to take extra time figuring out what the best practice should be versus what works for now.
Nested classes in VB6, a house of bricks.
Although the class builder in VB6 isn't stable enough to work with, so I recommend initializing your classes manually.
This is a work in progress, so some areas may be underdeveloped or blank, while others are a little more refined.
For example, see the classes for Process, File, Directory, MessageBox, and Screen.
The Screen class required a Rectangle class and a Point class to be made, like the .NET class counterpart.
More imports are planned of course.
Please contribute if you have any good API samples that will help duplicate .NET imports/namespaces.
Advantages
1. Compatibility. I would like to facilitate easier conversion/s between VB.NET and VB6.
The goal is to add unique code resources and concepts that have been developed in .NET over the years
2. Speed. Convert some net desktop code that is best suited for quick/direct desktop operations using the API.
3. Longevity. Maintain compatibility regardless of the net framework version installed, now and in the future.
4. Flexibility. New classes and/or features can be added or removed easily depending on your expertise.
Different templates (that appear in the "New Project" dialog window) can be made to group up classes as needed.
5. Robustness. Murphy's law applies to Visual Studio and the net framework.
Visual Studio NET also requires a full installation of a very particular framework to target with.
Great, maybe you should post a new thread about this project in the CodeBank.
Ok cool, I didn't know if anyone would be interested. We can mirror the project at the codebank then. I was thinking of using this thread as a place for new classes to be introduced over time. That way issues or missing features could be worked out together in the community. I'm almost finished the dialog classes, OpenFileDialog, SaveFileDialog, FontDialog, ColorDialog, and PrintDialog.
I've been working on replicating the concept. I'm working on 2 solutions, pure VB6 replacement classes, and dynamic interop. The classes seem to provide the best open solution for sharing, so i've been working on a layer where VBA serves as the code repository for the class namespaces. That way the developers project doesn't have to be bogged down with unused namespaces, until one is typed in. It is added to the project automatically and ready with intellisense. I just completed a similar feature for auto API insertion, where declarations, types, and constants are quickly shared between the VBA/APC object model, and the VB6 model with an addin.
Reply With Quote
Originally Posted by wqweto
