How Bentley AutoPLANT integrates a new class, methods and speckey WITHOUT editing the core program files

Posted on by

Lets assume that a new spec was created. AutoPLANT has a very clever structure to its files so that the core ones that come with AutoPLANT need not be touched. It also helps when new specs, ebs, classes etc. are added (specs beyond just adding or changing dB rows). This article outlines how to integrate a new component where a new class was created. There is already an article which outlines how to create a ‘new spec’ (a complete one which includes class/ini sections, ebs files and mdb rows) to do this AND there is an article that outlines how that last article was figured out, so that you too can do find out more complicated classes like joints etc. for yourself.

Lets assume that you have all your files / edits ready to go. A pseudo and realistic example is at the bottom.

  • class file ini sections figured out and ready
    • this groups all major pictures, method ini section names, spec key ini section names etc
  • method.ini files sections figured out
    • this lists which ebs files will get called for various functions in AutoPLANT
  • speckey.ini file sections figured out
    • This allows Bentley AutoPlant to narrow down the specs available for user selection. This is done by defining which table to look in and what values in specified fields to include. The spec row choosen by the user will populate a row in the Bentley AutoPlant database.—this allows Bentley AutoPLANT to filter and find the major and minor parameters that the user can pick from in the initial pick list and once a final list item is clicked-on the further lists all the little details that makes this component certain lengths, colors, and other attributes specific to the component the user chooses. These parameters exist in a database file or Microsoft Access mdb file
  • custom bmp pictures to help the users identify their new component at various stages like placing the initial component , editing the component and many other uses for bmps along the way
  • your menu item commands

How does one integrate this? You could edit some of the main class.ini and method.ini files etc. but this is not recommended because AutoPLANT has a better strategy built right in, but it can get confusing. Lets go over some basics as things can get very confusing very quickly but with some definitions, some understanding of how Bentley was put together as well as a real-life example should give some clarity.

When Bentley looks for files, it follows a specific search path for .ini files, pictures etc. All these .ini files and pictures are referenced at various points in .ebs and in .ini files. Once Bentley looks for a file, it first looks along the class sepcific search path for files, then up the class’s parent classes – assume it is looking for an ebs with some functions in it or a picture file. Lets also assume that these files are made in the CABLET application (RaceWays) which is a child-class of the PIPING application.

The search path – dimension 1 of 2 of where Bentley looks for files

  • It first looks in the project’s spec directory in a directory with the same name as the spec’s dB file. So if the spec is mmlights, then it looks in %APPROJDB%\mmlights
  • If it cannot find the file listed there, it then proceeds to look in the current project’s module directory. An example is %PROJDIR%\Config\modules\cablet. If it is a multi project, there is a common directory for specs and program files for all sub-projects or if it is a single project, there will be one spec directory and most likely on a network drive or the like near the project.
  • Then it if it can’t find the files, it looks in the local application modules directory c:\Program Files (x86)\Bentley\Plant V8i\Modules\cablet\
  • Then if it can’t find the files, it looks in the current project’s Base module directory %PROJDIR%\Config\modules\Base
  • Then lastly, it looks in the local application BASE module directory c:\Program Files (x86)\Bentley\Plant V8i\modules\Base

If it cannot find it, it pops up an error window and will not proceed.

Implications of search path upon integrating

When making custom edits to .ini files, ebs functions etc, place these customizations in your project’s search path – and best of all in the spec’s directory so that the .ebs, the .ini and the new pics can move along with the spec’s mob files. If one is not that brave, then place it in the project’s application directory. In the case of cablet (aka raceways) it is child app (child class) of piping so place the files in the modules\cablet directory and not piping. This leaves piping alone to be it’s own thing independent of raceways. Keep reading, as one can override piping functions/files/pics with cablet specific files, while leaving the piping app alone and untouched.

The class hierarchy – dimension 2 of 2 where Bentley looks for functions

For class methods if a method is defined in the sub class then it will search for the file and function defined here. If there is no method defined it then looks up the class hierarchy. If you place a component of a class, say CLASS_X, then it will look for CLASS_X’s Input Method. If CLASS_X has an Input Method then it looks for the specified file and function. If there is no Input Method then Bentley will search CLASS_X’s parent class for its Input Method, this will continue until either a method is found or the global class has been checked (in which case it assumes the method doesn’t exist and either give an error or continues depending on which method it was searching for). Some functions are only base functions inside a parent class such as update methods and that is why it finds them for sub classes even when the subclass doesn’t define them.

Implications of integrating based on class hierarchy

Place your functions that are common only up the trunk so that all classes that require it can ‘see it’ up the trunk. But beware, if you place a function with the same name as one further up the trunk, the one closet to the class will override the functionality of those closer to the trunk. In programming this is called sub-classing (which is where Bentley most likely got the name for classes – it is clear that a programmer designed this as this method is used often). One can snip functionality (make it do nothing via an empty function) or make it do something new (big or small) than it’s parent’s class with new lines of code into a function WITH THE SAME NAME. Alternatively, you can use 1 function for 2 components as long as it is closer to the trunk and along the same feeder branch.

If you use the class editor to “look” at what is happening, inside a class the methods in black bold print are the ones that are at the end of the branch – these are the ones that are referenced to the specific class. Some classes have a methods.ini file with all grey entries meaning that there are no specific methods for this class -they all refer to methods that belong directly to a parent class (the method group column will indicate which parent it is from). If you look at that parent class you will see some method’s in black.

General recommendations

Change things on a central location

It is not recommended to change any .ini, ebs or .bmp files in the c:\program files\Bentley director(ies) but it is preferred to  sub-class by placing the files in the project’s app directory or (or ideally it’s spec directory if it is very specific to one spec and it won’t be shared among specs). DO NOT EDIT the core Bentley files as if an update to AutoPLANT overwrites the .ini, .ebs or .bmp (or other files too) then all the changes can be lost.

Also changes to this area has to be disseminated to EACH computer. This is a large nightmare to distribute and ensure that the files did copy properly. Did everyone leave their computer on? Are all pushes done with an account that has allowable priviledges on other people’s computer? Is the IT department changing domains – what it is does? Are the files on the remote computers in use? This handcuffs departments to having IT’s help too much hampering both CAD and IT departments as CAD rarely has admin access to all files on everyone’s computer. Also many companies have individuals be their own administrators – what if the permissions change by accident due to a local person changing their own local permissions?

Changing things on a project or spec specific directory is easier and will produce more consistency.

Use version control on all .ini, .ebs, .bmp, .dll etc. files

Do not merely rely on Window’s backup because to get back to normal might take along time. It is best to use version control and check in small changes. This records who made the change etc. and changes to the official copy can only be done by individuals who have access to this tool. If files get changed – you can perform quickly (<10 seconds) a delta of what is checked in vs. what is really there. Oh- that is the file that was changed? Who did it? Using Windows explorer and all properties, one can quickly see the user-id of who changed it.

Other tools are required that make this SOOOO EASY.

Integration of a new spec with new classes, .ebs file should be able to be done in <20 -60 minutes after doing this a couple of times and with the correct tools that make this so easy.

Tools and philosophy

First, use an integration tool like Beyond Compare – please make a donation as it is well… a software … beyond compare (it also does more than just compare) . It is not recommended to overwrite files but integrate functions from .ebs files and sections from .ini files. If the file does not exist, create an empty one – again – do not copy files over unless you are sure you want the whole file and all the changes. It seems that when using some of Bentley’s tools it puts more .ini sections than are necessary into it’s class.ini files. This might confuse the issue especially the next person who is not expecting it.

What to communicate

In my case, the spec gen is not working. This is the proper way to create a catalog and distribute specs to others, but this is not possible, therefore a document with detailed instructions for integration was made

  • where the .ini are and where along the search path these go
    • class.ini  and/or
    • methods.ini  and/or
    • speckey.ini  and/or
    • joints.ini  and/or
    • etc. etc.
  • where supporting files are like the Excel worksheet that mimic the .mdb files and ONLY include relevant tables with relevant tables (you can use copy and paste between Excel an .mdb files to add new rows)
  • what the commands are for potential menu items, the preference to the menu hierarchy for the new specs. and the name
  • what the .bmp files are and where to copy them
  • what the .ebs files are and the functions to integrate or new files that should be put into place
  • other files to move into place (i.e. .lsp file)
  • any other instructions to autoload this or that (i.e. .lsp files)
  • any custom fields that need to get added to the PIPING table by the Admin team
  • any other instructions

This way, someone who does specs differently can integrate.

Only use the class editor to make new class.ini, methods.ini or speckey.ini files. There are many bugs in the class editor so after class initilization make ALL changes by hand in the ini files directly. DO use the class editor to ensure things were integrated properly though be restarting it.( In short; Initialize and Check using the Class editor, do not edit)

Testing

Any changes to .ini files requires that AutoPLANT/AutoCAD be restarted. The same goes for the class editor – it must be restarted.

Any changes to .ebs files can be done on the fly. Any introductions of .ebs and/or bmp files might require that AutoPLANT/AutoCAD be restarted to take effect.

Example:

Integration of a new series of lights

Menu Items:

Make a menu item that will load a page of lights. Don’t make it a scrollable list – this is ONE more step for the designers to place things. Sometimes it is unavoidable but do keep this in mind when specifying your speckey.ini filters.

  • suggest adding a menu item  / structure under a sub-menu Raceways->Lights
    • in the [at_elect.cuix ] menu file
  • request a menu item called Stantion Lights
    • macro command: ^C^C(at_Component_insert “AT_CABLET” “ELB_LUMINESCENTL420_LW”)
    • small icon: LTLWPD15
    • large icon: LGWPD15
  • etc etc. (other menu items)

files to move into place

Please ensure there is a directory structure to contain the following files in the following locations. These files are found in \\projdrive\1234567-Area-00\masterRepository\AutoPlant Demo Project\DEMOPROJECT, the paths are the same in project root as the ones created below.

  • %PROJECT_ROOT%\ Config\modules\CableT\pictures\Elect_lighting_parent_class.bmp
  • %PROJECT_ROOT%\ Config\modules\CableT\pictures\Luminescent Stanchion C1.bmp
  • %PROJECT_ROOT%\ Config\modules\CableT\pictures\Luminescent Stanchion S3.ebs
  • Copy the Copy the file %PROJECT_ROOT%\Merge\ELB_LightingAnnotations.lsp to to central location \\projdrive\1234567-Area-00\central_lisp_files directory
  • etc. etc.

Using Beyond Compare open on the left, the source \\projdrive\1234567-Area-00\masterRepository\AutoPlant Demo Project\DEMOPROJECT\modules\cablet\class.ini file and load on the right side of Beyond Compare the destination merge file at %PROJECT_ROOT%\Config\modules\CableT\class.ini and carefully merge left to right, the following sections

  • [ELB_LUMINESCENTBL420_LW]
  • [ELB_LUMINESCENTBL420_HW]
  • [ELB_LUMINESCENTBL420_WM]
  • [ELB_LUMINESCENTBL420_ST]
  • [ELB_LUMINESCENT_FL]

Using Beyond Compare open on the left, the source \\projdrive\1234567-Area-00\masterRepository\AutoPlant Demo Project\DEMOPROJECT\modules\cablet\methods.ini file and load on the right side of Beyond Compare the destination merge file at %PROJECT_ROOT%\Config\modules\CableT\methods.ini and carefully merge left to right, the following sections

  • [ELB_LUMINESCENT_BL420]
  • [ELB_LUMINESCENT_BL420_WM]
  • [ELB_LUMINESCENT_BL420_ST]
  • [ELB_LUMINESCENT_FL]

etc. etc. for .ebs and other progamming/text files that need to be merged.