Migrating toolboxes to VC++

I currently have a toolbox that houses over 180 applications written in MDL, which I compile for use on 2004, XM and V8i as a single MA & DLL application.  This toolkit is used in dozens of offices scattered through as many countries and is therefore easier to version, maintain and transport as a single MA & DLL.

Recent comments on this site lead me to believe that I should think of porting the application over to VC++ using the MicroStationAPI.  However, I am yet to see any example that uses toolboxes or for that matter, is anything but a 'one-off' add-in application.  Is this viable?  Am I able to write anything but add-ins if using the API?

I am quite happy to keep using MDL (I have been doing so since the release of V4), with the occassional reference to the MicroStationAPI for V8i specific code (i.e. font management), but wonder at its longevity.  Could somebody please comment (my last post (RE: Element Templates) went begging, even from the staff at Bentley, forcing me to use an intermediate XML file for importing the templates).

Parents
  • MDL & the MicroStation API

    Micheal:
    I currently have a toolbox that houses over 180 applications written in MDL. Recent comments on this site lead me to believe that I should think of porting the application over to VC++ using the MicroStationAPI.

    You can port your applications to C++ using MDL. Most of MicroStation's API continues to be provided by the MicroStation Development Library. You call and link to MDL functions through C++ just as easily as you make a call to the Win32 API.

    The confusingly-titled MicroStationAPI is a C++ interface. It was introduced with MicroStation XM and extended with MicroStation V8i. Since your libraries must run with MicroStation V8.5 then stick with MDL for now.

    Some functionality has moved from MDL to the MicroStationAPI — the Font Manager being one area of change. But the Font Manager has been in turmoil for several years anyway. In those cases you have to bite the bullet and write some #ifdef version tests to select the appropriate code base.

    Some of the newer features of MicroStation, such as extended attribute data, are accessible only through the MicroStationAPI. But since you want to maintain compatibility with earlier versions, the inability to use those features is moot.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

Reply
  • MDL & the MicroStation API

    Micheal:
    I currently have a toolbox that houses over 180 applications written in MDL. Recent comments on this site lead me to believe that I should think of porting the application over to VC++ using the MicroStationAPI.

    You can port your applications to C++ using MDL. Most of MicroStation's API continues to be provided by the MicroStation Development Library. You call and link to MDL functions through C++ just as easily as you make a call to the Win32 API.

    The confusingly-titled MicroStationAPI is a C++ interface. It was introduced with MicroStation XM and extended with MicroStation V8i. Since your libraries must run with MicroStation V8.5 then stick with MDL for now.

    Some functionality has moved from MDL to the MicroStationAPI — the Font Manager being one area of change. But the Font Manager has been in turmoil for several years anyway. In those cases you have to bite the bullet and write some #ifdef version tests to select the appropriate code base.

    Some of the newer features of MicroStation, such as extended attribute data, are accessible only through the MicroStationAPI. But since you want to maintain compatibility with earlier versions, the inability to use those features is moot.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

Children
  • Hi Jon,

    Thanks for your thoughts.  While aware of most of what you've mentioned, I was more interested in some answers concerning the use of toolboxes within the API and whether it can be used to create anything but add-in DLL's.  If this is possible, which it should be using toolstrips etc, I will leave the 2004 & XM versions in maintenance mode and push forward with the V8i development.  I am trying to upgrade the entiire company (survey and mapping) to a single platform and take advantage of the GeoCoord API, new to V8i, which would simplify most of what we do.  I just need a nudge in the right direction, so a picture is worth a thousand words (unless those words are code snippets or where to find them).

    Micheal

  • Micheal:
    I was more interested in some answers concerning the use of toolboxes within the API and whether it can be used to create anything but add-in DLL's. If this is possible, which it should be using toolstrips etc, I will leave the 2004 & XM versions in maintenance mode and push forward with the V8i development. I am trying to upgrade the entiire company (survey and mapping) to a single platform and take advantage of the GeoCoord API, new to V8i, which would simplify most of what we do.

    When you implement an application in a DLL, you move all the .mc code into the C++ arena. That's not to say you have to write object-oriented code — C++ is quite happy with existing procedural code. Nor is it to say that you must discard any existing resources — you can continue to use:

    • MDL message lists
    • MDL menus
    • MDL dialogs
    • MDL icons
    • ...

     

    The above continue to work as before, down to the hook functions you must publish and link to your dialogs & widgets.

    However, you can also use Visual Studio to create your own MFC (or ATL) dialogs. This works find for modal dialogs. For modeless dialogs you should inherit from one of the CBxxx dialogs.

    We've written a couple of pages about Visual Studio and MDL and Windows and MDL

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

  • Sorry Jon, I mustn't be explaining this too well.  I ported my old .mc code to .cpp (as described in your last) upon the release of V8 a few years back and now maintain a single toolkit (albiet three versions of it, for 2004, XM and V8i) in MA & DLL format.

    I was wondering if there are any advantages of going to a full .NET solution (i.e. native dialogs, classes etc) as I am still able to include the MicroStationAPI from my current codeset.  My question related to toolboxes because I have yet to see any examples or references to them in any .NET posts and they seemed a logical place to start, with 180 odd applications in a single MA/DLL.

    If it is not necessary to rewrite for improved performance or any other advantages in .NET, do you know of any examples of:

    • native dialogs being used within the mixed codeset (so I can use the greater variety of windows dialog items rather than writing my own generic items, such as a date-time picker (although it was a fun distraction)), and
    • how to use windows icons rather than those in a .r resource file (to 'doll-up' the look of the toolkit with icons that have more than 16 colors).

    Micheal

    AAMHatch

  • Micheal:
    My question related to toolboxes because I have yet to see any examples or references to them in any .NET posts.

    Toolboxes in MicroStation are defined by an MDL resource (.r). They kick off one of your commands (or a MicroStation command), and are intrinsically bound to MicroStation. But maybe the Bentley developers will come up with a way of creating a dockable toolbox using Visual Studio.

    Micheal:
    I was wondering if there are any advantages of going to a full .NET solution (i.e. native dialogs, classes etc). If it is not necessary to rewrite for improved performance or any other advantages in .NET. The greater variety of windows dialog items.

    If you're proficient with C++ then AFAIK Visual Studio provides all the user interface components available in .NET to Visual C++ developers. The advantage of .NET is its rich set of languages and components, which provides great programmer productivity. The one thing that .NET will not provide, compared to C++, is better performance.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions