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


After searching all over the BeCommunities site I found information that explained how to install the Wizards.  

The short description of what I did was:
Unzip the Wizards, which yields the following folders: ControlFiles, MDLProjectWizard, MicroStation AddInWizard, MSTNToolWizard
I placed the folders in a folder I created: d:\mdlWizards (this was my choosing, not per directions)

I then tweaked each of the .vsz files (in the ControlFiles folder) to look something like this:

VSWIZARD 7.0
Wizard=VsWizard.VsWizardEngine.8.0
Param="WIZARD_NAME = MDLProjectWizard"
Param="ABSOLUTE_PATH = d:\mdlWizards\MDLProjectWizard"
Param="FALLBACK_LCID = 1033"

I then copied all the files in the ControlFiles folder to C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcprojects (which would be different for people running 32-bit Windows or a different version of Visual Studio, I'm running VS2005)

I then launch Visual Studio 2005 and select New, Project. Select Project Type Visual C++ and then pick one of the three Wizards: MicroStationAddInWizard, MDLProjectWizard, MSTNToolWizard.

When I select a wizard and click OK it creates the project files. I then attempt to Build and that's when the trouble starts. I've tried each Wizard and each project doesn't build for different reasons. Below is what happened for MSTNToolWizard1 (default name of the project that I kept when using the Wizard). After attempting to fix each issue I tried to Build the project and got new error messages.

MSTNToolWizard1
issue: Cannot open the include file mdl.h (and many others)
resolution: right-clicked on Project in the Solutions Explorer and selected Properties. On the Properties I went to Configuration Properties > C/C++ > General and added C:\Program Files (x86)\Bentley\MicroStation\mdl\include into the "Additional Include Directories" field.

issue: I get the error message #error: Define the Int64 types.
resolution: In bentleytype.h where the error appears there is an #else / #endif section that just has the error message. I'm guessing this is because I'm on a 64-bit computer. I would think we could still build since VS is 32-bit. I commented out the #error ... line and then copied the typedef __int64 statements from the top section. This was a total guess so this may be wrong but it got me past the compiling aspect of this error. Any one know what should be here?

issue: I get the error message: #error: this gen_dloadlib.h intended only for winNT
resolution: I have no idea how to get around this so I just commented out the error for now. Any ideas how to do fix this properly?

issue: Cannot open the include file microstationapi.h.
resolution: Added C:\Program Files (x86)\Bentley\MicroStation V8i (SELECTseries 1)\MicroStation\mdl\MicroStationAPI to my Additional Include Directories in the Project Settings

issue: Cannot open include file MSTNToolWizard1ToolCmd.h
resolution: Not to sure what to do with this one since the file doesn't see the file doesn't exist anywhere. I commented out every where it was included for now. Anyone know what to do with this?

issue: CMD_MSTNTOOLWIZARD1_ACTION_PLACE (and others) undeclared identifier
resolution: I'm guessing these are suppose to be in the MSTNToolWizard1ToolCmd.h I couldn't find in the last issue.

At this point I quit, figuring I need to get the correct answers for the above issues first.

Any thoughts on any of this would be much appreciated.

Thanks,

Mike

 

 


Parents
  • 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();

        }

     

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

     
    Regards, Jon Summers
    LA Solutions

Reply
  • 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.

     
    Regards, Jon Summers
    LA Solutions

Children
No Data