Using System.Windows.Forms in VBA

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

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

1. IJW or CWinFormsControl in MFC
2. Hosting the Common Language Runtime
3. COM InterOp

Dan

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).

Unknown said:

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.

For reference, the new Bentley Map V8i (SELECTseries 2) 08.11.07.425 release posted last week on SELECTservices no longer requires embedded passcodes for .NET addin or native C/C++ code development. The Bentley Map product line now consists of...

• Bentley Map Enterprise V8i (SELECTseries 2) - standalone installation only, new product offering
• Bentley Map V8i (SELECTseries 2) - standalone or layered MicroStation installation, replaces Bentley Map and Bentley PowerMap products
• Bentley Map PowerView V8i (SELECTseries 2) - standalone installation only, replaces Bentley PowerMap Field

...with additional details available in the "Product Editions" section of the products readme file as well as the Bentley Map V8i (SELECTseries2) FAQ document.

That is great news! But not enough for me, becasue most of my clients have or will buy PowerDraft (V8i) or PowerMap (V8i), not Bentley Map.