VB.NET Module Request Thread last updated on 2003-11-04 09:21:05

Posted by member 73429 on 2003-10-22 16:54:19

I'd like to try to write a litestep module. Can it be done in VB.Net, and does anyonw have some example code?

Thanks

Posted by member 99 on 2003-10-24 02:41:25 link

I suspect that it's probably possible to write a module in VB.Net, but having no experience with VB or .NET, I wouldn't know for sure. Unfortunately, I would expect that it would be rather difficult if you don't know how to tell if it's possible, since to my knowledge it has never been done before.

As for example code, some source code is included with modules or available from the auther, other stuff can be had at shellfront.org, but most of it will be in C or C++. I'm pretty sure there isn't any module code available in VB, but I could be wrong.

Posted by member 31 on 2003-10-25 12:07:13 link

Actually modules have been written in VB before. But only for vb activex dlls. You have to use this module to load your vb activex dll.

http://www.shellfront.org/modules/vbmodulo.zip

I do not know if that will work for VB.NET however.

Good luck.

Posted by member 74896 on 2003-10-27 16:49:58 link

Do you know the name of one of those VB modules by chance? I looked at the source for vbmodulo and I'm not sure how to set up !bang commands. An if anyone is interested, I'm going to try and port a program I wrote a while back to litestep. It basically lets you write scripts (in vbscript or javascript) that take control of the keyboard and mouse. Very versatile macros if you will. It works in almost all normal applications, and some full screen games. If I can get it working as a module I'll probably need a few testers, if anyone is interested.

Posted by member 69852 on 2003-11-01 16:57:16 link

Hi,
I am a vb.net guy and I have been looking around for an answer to the same question. I tried using modulo but it is so far out of date that it cannot be used with the latest ls builds. I looked at what it did (a wrapper for an api that is out of date) and could not repair it because I do not have the source for vblsapi.dll I tried contacting the author. It seems that he has moved.

I understand that there were plan to enhance LS to give it a COM interface so people would be able to load activeX components into LS. The post I read was that those plans had been abandoned by the dev team because COM was just a bear to work with (not so but that what I read).

So, in a nutshell, vb guys are SOL with the idea of writing modules for LS. I suppose we could always learn C++ :_)

Posted by member 69852 on 2003-11-01 17:15:31 link

Me again :) I forgot to mention... .NET user controls (what we used to know as ActiveX controls) are only supported on Windows Forms, they are not supported in the active desktop or iexplorer window. This presents a little problem because without a .NET windows form, you don't have a container to host the object. I am pretty sure you cannot write an ActiveX control with .NET but you can with all the version 6 languages.

I am of the opinion that the ultimate solution would be to build LS using the .NET framework and to port all the core modules to .NET.

Having done several conversions to .NET, I don't think it would be that much of a big deal even if LS is written in C++. Litestep would become a wide open shell for anyone wanting to work on it in almost any language. For that matter, Litestep would become backwards compantible with COM almost by default. This is something the LS dev team should really consider doing if they want Litestep to leap over all other shells and live on as the ultimate shell that it is.

Posted by member 2018 on 2003-11-01 18:46:38 link

0.24.7 is a rewrite to get rid of all the COM in LS version 0.24.6 has lots of COM but nowhere in .net level stuff.

Posted by member 69852 on 2003-11-02 13:36:34 link

Yep, that's what I read somewhere. There is no mystery about .NET in fact, the latest version of .NET was to introduce major enhancements for C++ along with J#. Porting LS to .NET wouldn't be a big effort and it would make the development and support for LS alot easier.

On another topic but one that is very close to the initial question spawning this thread is the fact that one doe not need to write a .NET module at all for Litestep. I am a SW development project manager with time on my hands. I would certainly like to offer a hand to the dev team should they want to consider the .NET porting option.

After some more reading, I came across a module called SendMessage on Shellfront.org. In theory, one could use this module to remote a .NET windows form or service app. using a set of messages that would emulate bangs.

Right now, I think this is the only way to work with .NET apps.

Posted by member 36955 on 2003-11-02 20:26:14 link

the only thing about porting it to .net is that first of all, it would be a lot of work to do right now, while the core is still in the process of getting redone... its a possibility once .24.7 final comes out, but there is a second problem... most users dont have the .net framework installed, and as far as i know (i could be wrong) programs written with .net need it to run... installing it would be an unneeded hassle for most users, especially ones who just want to try out litestep, something that they can finally do now with the new litestep installer. so while it might offer benefits in terms of which languages litestep modules can be written in, it would decrease usability for new litestep users by a significant amount. it might be nice if something like vbmodulo was built into the core, although once again, that wont be likely for a few months at least

Posted by member 35 on 2003-11-02 21:40:33 link

besides i think that one of the ideas was to be able to compile ls 0.24.7 on others compilers beside microsoft visual c++ (at least it was mentionesd somewhere)

Posted by member 503 on 2003-11-04 09:21:05 link

Changing LS to use .NET would be a major job in and of itself. The real problem, however, is that all of the popular modules would also have to be rewritten. There aren't enough coders/time for that.