search

twinbasic / twinbasic

284 stars 23 forks source link

Support migration of VBA Userforms #584

Open bclothier opened 2 years ago

bclothier commented 2 years ago

The proposal is that one day tB could support importing of VBA projects that contains userforms into a tB project. As new VBA projects are created & maintained, the ability to support this would be a great to attract new users to tB and provide them with an alternative. However, to entice them, we need to be able to support their investments in userforms to make it easier to migrate the VBA project.

Based on the following comment, this needs to be opened as a separate issue and tracked separately.

I'm sure there is lots of overlap with VB6 forms, but I remember how quirky the UserForms implementation is from when we were looking at the runtime type library generation of them in RD... so it probably needs further consideration. I agree though, it would be nice to be able to import VBA UserForms into tB eventually.

Originally posted by @WaynePhillipsEA in https://github.com/WaynePhillipsEA/twinbasic/issues/567#issuecomment-997681144

mburns08109 commented 2 years ago

Wouldn't this ask simply be a part of the "100% backward compatibility" policy, since VBA can support userforms?

mansellan commented 2 years ago

Wouldn't this ask simply be a part of the "100% backward compatibility" policy, since VBA can support userforms?

Depends how you measure "compatibility". MSForms is an external library from VBA, In theory you can reference it from VB6 (or any other COM language), in practice that never works. It's a special little soldier.

Kr00l commented 2 years ago

Wouldn't this ask simply be a part of the "100% backward compatibility" policy, since VBA can support userforms?

I don't think so. With VBA you can't make EXE or DLL. So that's only VB6 compatibility. Remains only the outsourcing of a UserForm VBA project to a tB Add-In. But that's something new anyway, thus no "compatibility" in the real sense.

mburns08109 commented 2 years ago

Wouldn't this ask simply be a part of the "100% backward compatibility" policy, since VBA can support userforms?

Depends how you measure "compatibility". MSForms is an external library from VBA, In theory you can reference it from VB6 (or any other COM language), in practice that never works. It's a special little soldier.

OK, having never tried using that library outside of VBA in an Office project, I'm unaware of any limitations or issues using that as an external library (mostly because I never found reasonable documentation for the userform library/object model at the time it would have mattered to me). What have you seen in that regard? are there just some userform dependencies on the Office COM components or something that makes it fail outside of that execution context?

A9G-Data-Droid commented 2 years ago

I have seen plenty of "enterprise applications" developed in Excel that don't really need Excel at all. That's just the "IDE" for VBA that is most common. I would love to have a simple path to convert these things in to standalone applications that no longer need an Office host.

KDGundermann commented 2 years ago

as soon as Wayne has an API for creating Forms I may give it a try to develop a converter for MSAccess Form -> TB Form ( Sorry I have never developed in VB6..)

greatquux commented 2 years ago

I just recently ran into an issue with one of our clients who's still using VB6. Out of nowhere they found VB6.EXE crashing when compiling their project, and it took a few days but they were able to track it down to one User Form which someone created years ago, and only wound up using on one form in the project, which would seem to be antithetical to the need to have a user form. They were able to just reimplement it with its constituent controls and get by the error. I only bring this up since it might be complex to get user controls working if they can cause VB6.EXE to crash!