Visual Studio compiling

I have exactly same problems. Have been looking for a good example/tutorial to explain that, but have not found anything.

Russ said:

This system seems way over complicated

It's not complicated, but it is definitely confusing.

Here's a comparison of Visual Studio and Bentley Make that may help.

Russ said:

VCVarsQueryRegistry2010.mki

I don't see that on my MicroStation V8i SS1 computer either. But I'm happy with Viz Studio 2005 and Viz Studio 2008.

Regards, Jon Summers
LA Solutions

Unknown said:

It's not complicated, but it is definitely confusing.

Hehe, making their own port of the make system, their own compiler and linker and extending the C lang just for plug-ins takes the cake for complicated. I can only imagine the man hours that could have been saved by just embedding the python interpreter instead. :)

All right, as I had previously thought I have to compile the DLL using VS and then using the resource compiler. I hope (and I am pretty sure) I can do this while avoid using bmake.

I'll stumble along with 2010 then, if I can get it working I shall share my secrets.

Russ said:

Making their own port of the make system, their own compiler and linker takes the cake for complicated.

BMake has been around since the introduction of MDL twenty years ago. At that time there was no other consistent way to build C applications. Visual C++ did not exist.

BMake works with numerous operating systems, from MS-DOS through most UNIX flavours to Windows. As a general purpose make tool, it works with numerous languages — not just C — including .NET and Java.

Russ said:

Extending the C lang just for plug-ins takes the cake for complicated.

How else would you do it other than by extending an existing language? Python, C++, C and any other language you care to name know nothing about application-specific domains. Do you lay the same charge against, say, Visual C++ — it has those needless extensions to C++ to provide Windows functionality? MicroStation VBA extends Microsoft VBA to make it useful in MicroStation. Excel VBA extends Microsoft VBA to make it useful in Excel.

Russ said:

I can only imagine the man hours that could have been saved by just embedding the python interpreter instead.

Python didn't exist twenty years ago. Why would it be an improvement over the tried-and-tested make? Where would you embed the Python interpreter?

Russ said:

I am pretty sure I can do this while avoid using bmake.

Of course you can. All the Bentley tools are in the \mdl\bin folder. You'll need to invoke rcomp.exe and rlib.exe and possibly some others.

But don't forget to set all the environment variables, macro definitions, include paths and other things that BMake would have done for you. Good luck!

Regards, Jon Summers
LA Solutions

Unknown said:

BMake has been around since the introduction of MDL twenty years ago. At that time there was no other consistent way to build C applications. Visual C++ did not exist

How about a simple build script using what ever c compiler was used back then, or even plain old make itself? Other programs don't and never seemed to have required a program specific build system (and including packaging their own compilers, linkers, modified C language etc etc), take unix/linux kernel modules as an example. Take Adobe SDK as another. There must have been a good reason to, surely?

Regardless, it is no excuse for such a system to exist twenty years later! And it is complicated.

Unknown said:

How else would you do it other than by extending an existing language? Python, C++, C and any other language you care to name know nothing about application-specific domains. Do you lay the same charge against, say, Visual C++ — it has those needless extensions to C++ to provide Windows functionality? MicroStation VBA extends Microsoft VBA to make it useful in MicroStation. Excel VBA extends Microsoft VBA to make it useful in Excel.

I was referring to modifications of an existing language, not the providing of libraries/APIs. Seeing as MDL is C 'based'.

Unknown said:

Python didn't exist twenty years ago. Why would it be an improvement over the tried-and-tested make? Where would you embed the Python interpreter?

Hehe, true it didn't exist 20 years ago.

Unknown said:

But don't forget to set all the environment variables, macro definitions, include paths and other things that BMake would have done for you. Good luck!

I'm already prepared for the worst ;).

Russ,

Did you take a look at this old posting ?

communities.bentley.com/.../using-visual-c-express-edition-to-build-mdl-applications.aspx

It was for 2008 but could be modified to work for 2010.  VCExpress is not the same as VisualStudio Professional so the registry stuff is slightly different and you will need to fix that part up.  The other strategy that I have seen used is to build the dll and then make the resource file (.ma) that we use for GUI and to load the dll from.  And if all this is really not to your liking take a look at AddIn applications that use the .NET system and yes you can build them in the IDE.

HTH,

Unknown said:

It was for 2008 but could be modified to work for 2010.

But what about VCVarsQueryRegistry2010.mki? As Russ notes this is included by one of the other .mki files but is not delivered with the SDK.

Regards, Jon Summers
LA Solutions

If you build with Visual Studio Express it would not help you since the registry entries are different.  In the blog posting I thought I covered the basics of what you need to put together to create your own set of entries that will keep the process happy.  By simply defining build with VS2010 you would need to have VisualStudio 2010 not the express tool.  Building with 2010 opens up a new set of issues as to the correct compiler settings etc.  AFAIK we have not certified building with 2010 yet.

HTH,

Unknown said:

The other strategy that I have seen used is to build the dll and then make the resource file (.ma) that we use for GUI and to load the dll from.

This is the method I intended to use. As I understand, to support earlier versions of microstation this would be required.

Unknown said:

And if all this is really not to your liking take a look at AddIn applications that use the .NET system and yes you can build them in the IDE.

With .NET am I provided with equivalent MDL commands, or just limited to the same API as VBA (COM)?

Unknown said:

Building with 2010 opens up a new set of issues as to the correct compiler settings etc.

I'll have a play around, see if I can get any thing compiled using 2010. If not, I'll try with Express 2008 and then work my way forward. (hey, I got to learn the compiler settings sometime!)

Thanks Gentlemen.

DllMdlApp Resource

Russ said:

As I understand, to support earlier versions of microstation [the resource (.ma) file) would be required.

The .ma file contains the DllMdlApp struct. This tells MicroStation what DLL you want loaded when you key-in MDL LOAD MYAPP …

#include <rscdefs.h>
enum DllResourceIDs
{
  DLLMDLAPP_Russ = 1,
};
DllMdlApp  DLLMDLAPP_Russ =
{  //  MDL Application name   VC++ DLL in MDLAPPS or %PATH%
   "myapp",                   "myapp.dll"
};

Command Table Resource

Your MDL resources will probably include a command table, because this makes your application more like a built-in tool.

For example, a command table lets your user start a command from a key-in, icon, function key, menu or queued from a VBA macro.

Message List Resources

Your MDL resources may include message lists. Of course, you can also have message lists in Viz Studio resources. However, message lists in an MDL resource provide a benefit: they work with your commands.

It's also easier to create multi-lingual applications using MDL message lists. Viz Studio makes it hard to create a multi-lingual application. The well-thought-out MDL technology makes it easy to have several language-specific message lists.

Dialog Resources

You can choose whether to use MDL dialogs or Viz Studio dialogs (there are several to choose from, such as MFC or WTL) or both.

The foundation of MDL dialogs — the Dialog Manager — is elegant. It permits program variables to communicate seamlessly with items in the dialog. MDL dialogs lend themselves easily to modeless operation. The big pain of MDL dialogs is the lack of an IDE.

Viz Studio dialogs do have a good IDE, but the foundation is inelegant. You have to write code to pass program data between your variables and the dialog items. This is irksome in a modeless dialog because it's hard to know when something has changed.

In general, use MDL to create modeless dialogs that need to communicate with your application variables. Modeless dialog don't obstruct the user, who is familiar with the idiom because so many MicroStation dialogs are modeless. Use Viz Studio dialogs to benefit from the wealth of user interface components and the good design tools.

AddIn Commands

Russ said:

With .NET am I provided with equivalent MDL commands?

There are examples delivered with the SDK (e.g. TextMod) that show how to create a command table for your .NET AddIn.   The command table is an XML file.  This has shortcomings compared to MDL commands, but they're better than the nothing available in VBA.

Regards, Jon Summers
LA Solutions