Hi
I would like use objects from System.Windows.Forms (.NET library) in VBA. Is this possible? If yes then there are any problems with propagate mvba to others users?
Regards
Pawel
Unknown said: Hi I would like use objects from System.Windows.Forms (.NET library) in VBA. Is this possible? If yes then there are any problems with propagate mvba to others users? Regards Pawel
hi,
You mean to create all controls which I need as Windows Control Library (eg. in C#) (controls derived from controls in System.Windows.Forms) and register in system? There is any problem with propagate mvba with controls like this?
Yes, you can do that... Look at here
Problem is that you need .NET framework installed on end user's system, but this is no problem after XM, because it is a part of MicroStation's installation.
Also problematic may be design time, because VBA will not know other types used in controls.
Why not create .Net Addin insted? It is simpler, faster, more nice, because .Net supports VisualStyles, which will be not used in VBA, so your controls will look like old style windows...
Dan
Thanks for reply!
And I agree with Dan at all! But I have to create my application for Power series (PowerMap, PowerDraft), where Addin is not allowed without code.
Unknown said:Why not create .Net Addin insted? It is simpler, faster, more nice, because .Net supports VisualStyles, which will be not used in VBA, so your controls will look like old style windows...
Joerg Teresniak said:One argument against the NET-Addin approach is a mixed V8.05 / V8.11 environment. Using a MicroStation 8.05 Interop DLL you can create a mixed NET+COM+VBA solution which runs with both MicroStation releases.
OK, but in VBA, you have a very small level of code protection. VBA password can be easily removed, while for .Net are available many obfuscators, which makes .Net code readable only as IL.
In native application you can also use .Net form. There are at least three options to implement .Net form in V8.05
Unknown said:OK, but in VBA, you have a very small level of code protection. VBA password can be easily removed, while for .Net are available many obfuscators, which makes .Net code readable only as IL.
Native code develoment is surely the most powerful solution. Unfortunately, writing software in C++ is not as easy as in C# or VB[.net] :(
Aha, so you mean VBA only as loader to process... OK, it is possible ofcourse, but good only for in-house applications (which do not use ToolSettings dialog or Dockable dialogs).