Using the BDN Wizards in Visual Studio 2005 on Windows 7 64-bit

Windows Environment Variable MS

Unknown said:

issue: Cannot open the include file mdl.h (and many others)

Unknown said:

Cannot open the include file microstationapi.h

When you run the development environment batch file mstndevvar.bat it uses Windows environment variable MS as the base to set the include folders. When you install the SDK, the installer adjusts that batch script to point MS at the correct location.

The Wizards are a freeware add-on from Bentley Systems. Because they are copied, rather than installed, they don't know where MicroStation is located. We need to define, at Windows level, the location of the \MicroStation folder using environment variable MS. In addition to MS, there are a number of other Windows environment variables you may find it convenient to define.

Once MS is defined, you can use it in both bmake projects and in Viz Studio projects. Add the following to the Additional Include Directories setting of Viz Studio when building an MDL project …

$(MS)mdl\include

Add the following to the Additional Include Directories setting of Viz Studio when building a MicroStationAPI project …

$(MS)mdl\include
 $(MS)mdl\MicroStationAPI

Int64 types

Unknown said:

#error: Define the Int64 types

This has nothing to do with Windows 64. MicroStation V8 uses 64-bit integers irrespective of the operating system. Both Windows 32-bit and Windows 64-bit provide the __int64 data type, and so does MDL. The MDL #include files need to know whether you're developing using bmake or Viz Studio so they can either use the available 64-bit data types or defined their own.

When you write a bmake script and %include mdl.mki, it pulls in the relevant definitions.

#define winNT

When you're building with Viz Studio, you need to #define winNT early on in the #include chain. Some MDL header files do that for you — for example, msmfc.h. Add that symbol to the Viz Studio pre-processor list, or put this definition in one of your headers (e.g. stdafx.h, if you're using a precompiled header) before including the Bentley headers …

#if !defined (winNT)
 #define winNT
 #endif

Unknown said:

#error: this gen_dloadlib.h intended only for winNT

With winNT defined, you should find that most of those errors disappear.

Visual Studio for MicroStation

We wrote some articles about Viz Studio and MicroStation development that are published on our website.

Regards, Jon Summers
LA Solutions

Mike,

The wizards provide the set of files that you need to work with to develop applications.  The build is still done using Bmake and the developer shell that is provided with the MicroStationSDK installation.

HTH,

Unknown said:

The build is still done using Bmake

Perhaps it's not clear that Viz Studio is used mostly as an editor. 

Does the developer still need to open the Bentley development shell manually?  Or, has the Wizard modified the Viz Studio build command to invoke the Bentley development shell? 

The wizard is intended to create the source files that are needed to get started.  The compiling is to be done in a developer shell that the user opens.  No the wizard does not open a developer shell nor invoke any compiling tools.  With that said there is a special case of the AddIn wizard which can be used to build .NET assemblies from with in the IDE.  

HTH,

Thanks guys for the information.  I was teaching yesterday and again today but I'll definitely try this out over the weekend.

I have read thru some of the articles on Jon's site and thru a number of discussions/tutorials on BeCommunities.  Getting back into MDL (after many years) is a bit frustrating.  The coding side doesn't worry me, it's all the set up to get everything working.  Some of tutorials/test I've run have worked out but some have not.  My ultimate goal is to work with ProjectWise in MicroStation.  The rest of my app is in VBA.  I'm trying to understand the whole picture of when to use MDL, MicroStationAPI, Microstation Addins, etc.

I've thought about attending Developer conference but it doesn't look like it's going to cover what I need.  Anyway, I press on...

Thanks!

Mike,

I am sure that at the Developer Conference we can answer all of your questions.  There are some sessions that will have some open time and there is always the in between time.

Hope to see you there.

I'm back in the office and looking thru the info you guys provided.   Let me recap in my words to make sure I'm understanding what you said:

Compiling Apps created with the MicroStation Wizards

In VS I can create a new project using the wizards. 
However I don't do the build for those projects in VS (this is definitely not obvious) but instead use bmake
bmake is run by being in the MicroStation Dev shell, navigating to the project folder and then running bmake

I saw in a post how someone tweaked mstndevvars.bat to launch VS so he could compile there.

Is that an okay way to work?

 It also seems like much of Jon’s answers are trying to set it up so it can be built in VS, which would be my preference if that works.

Windows Environment Variable MS

Jon Summers

  "Once MS is defined, you can use it in both bmake projects and in Viz Studio projects.  Add the following to the Additional Include Directories setting of Viz Studio when building an MDL project …"

From what I've seen, if MS is defined by mstndevvars.bat then it's only good within the Dev Shell and won’t be available in VS (with the possible except of launching VS from within the shell).  I could define MS on my own in the Windows Environment variables but I have 3-4 versions of MicroStation running and need to compile in at least 2 of them which means I need to keep it easy to change between versions which seems to bring me back to having MS defined in mstndevvars.bat.

Int64 types

  Jon Summers

  “When you write a bmake script and %include mdl.mki, it pulls in the relevant definitions.”

#define winNT

I included winNT in the Microsoft looking version of stdafx.h (there are two stdafx.h files in the project created by the Wizard) and that seemed to cure most of the issues.

Still getting an error

There is one error that still comes up when building in bmake or VS.

mfc\MDLProjWiz2hosted.cpp(130) : error C2664: 'mdlDialog_closeCommandQueue' : cannot convert parameter 1 from 'GuiWindowP' to 'DialogBoxA *'

void MDLProjWiz2HostedDlg::OnCloseButton()

    {

    // TODO: add your control notification handler code here

     mdlDialog_closeCommandQueue( m_pParent ); <<<<< line with the error

    MDLProjWiz2HostedDlg::OnDestroy();

    }

Jon - What are you using in order to get such nice looking replies?  I tried building a reply in Word with colors and nice formatting but even using the rich formatting and the Paste from Word option it didn't bring over the formatting.

Mark Anderson wrote:

       "I am sure that at the Developer Conference we can answer all of your questions.  There are some sessions that will have some open time and there is always the in between time."

I would love to see a class that includes the following:

Walks thru the recommended way of setting up Visual Studio to work with MicroStation development.

When do you have to use bmake and when can you build with Visual Studio

Discusses MDL, MicroStationAPI and Add-ins and talks about which are recommended for different type tasks.

Hands-on exercises with building each of the different types

It would be great to have a class like this early in the time schedule so that the other sessions would be more understandable for those that are new to MicroStation development or like me haven't done MDL in quite a while.

Unknown said:

However I don't do the build for those projects in Viz Studio but instead use bmake.
bmake is run by being in the MicroStation Dev shell, navigating to the project folder and then running bmake

Unknown said:

I saw in a post how someone tweaked mstndevvars.bat to launch VS so he could compile there

mstndevvars.bat sets up the Windows environment for development.  Whether you use bmake or Viz Studio, the compiler  must be able to find (a) your source files (b) MicroStation header files (c) Windows header files if building a native-code app. and the linker must be able to find (d) MicroStation library (.lib) files and (e) Windows library files. 

The way both tools do that is to look in the values provides in compiler and linker switches. bmake is easier to understand if you've been using it for a while and are unfamiliar with Viz Studio. bmake has macros that provide input to the C++ command-line switches — they're cryptically named and undocumented. For example, the following bmake statements add an include path to the C++ compiler switches …

dirToSearch = $(MSMDE)mdl/MicroStationAPI/ 
 %include cincapnd.mki

Unknown said:

if MSis defined by mstndevvars.bat...

It is defined by mstndevvars.bat but only if not already defined.

Unknown said:

I could define MS on my own in the Windows Environment variables but I have 3-4 versions of MicroStation running

In which case it's a good idea to use mstndevvars.bat to define the environment. I create a Windows account for each version of MicroStation, and set the environment there. But I have the luxury of running my own show and can implement that policy without an IT department looking over my shoulder.

Unknown said:

mfc\MDLProjWiz2hosted.cpp(130) : error C2664: 'mdlDialog_closeCommandQueue' : cannot convert parameter 1 from 'GuiWindowP' to 'DialogBoxA *'

You're running into name conflicts between MDL and Windows SDK header files. DialogBoxA and DialogBoxW are Windows class names that are referenced by the compiler following a call to DialogBox. DialogBox is a Windows SDK macro that calls one of the real classes depending on the value of _UNICODE. There's a clash between the Windows DialogBox macro and the MDL DialogBox struct name.

The C++ pre-processor has invoked that macro and converted an MDL DialogBox* to a Win32 DialogBoxA*.  Because those are two different types, the C++ compiler subsequently complains.

Are macros evil?

Macros are evil, though. You really shouldn't use them unless you have no other option. They ignore scope rules, pollute the namespace, and lead to very cryptic errors.  This is a perfect example: the Win32 macro causes havoc with MDL function names.