It does use some of the common controls, which require a separate OCX. And the text editor is a custom control that I wrote, as VB doesn't have a built in rich text editor that could provide the functionality I needed.
But those aren't the real reasons this would be difficult to port to dotNET. The real problem is that there are so many changes from VB6 to dotNET, even simple things like how screens are updated, how toolbars work, how interactions with mouse and keyboard are processed. If I really wanted to port it, I'd probably be better off writing all the user interface parts from scratch using the original as a guide. Some of the routines behind the scene also would require significant work, as dealing with classes and objects changed drastically too.
On the plus side, there are a lot of things in dotNET (VB, C# or any of the languages) that are significant upgrades in capabilities that would eliminate a lot of the things I had to do by making API calls or other programming tricks to get VB to do some of the 'high performance' things. While I feel good that I was able to leverage VB6 to create a really good tool, it would be nice if I could do those things using built-in features.
Anyway, I'm always looking for a good challenge, and I think now is the time to dive into C# and finally learn it. So helping with Visual AGI is something I think I have interest in.
(As a side note, when I first began working on WinAGI, I originally had "VisualAGI" as the title. But then I found the other "Visual AGI" program that was in progress, so I decided to choose a different name. While I used AGI Studio as the starting point, my goal all along was to create an environment that 'felt' like any other Visual Studio developer tool. So the possibility of bringing some of WinAGI's features to the new Visual AGI feels like coming back full circle.)
