CabMaster Developer is an intelligent object based application. Objects are described using parameterised formulas, and the graphical representations are deduced from this data.
Developer is a knowledge base, capable of carrying construction, design, financial, work flow and any other data types required to construct a group of objects, a single object or subsection of an object. It provides a manufacturer the ability to encapsulate, secure and refine its business processes and procedures, and in turn control all down stream activities, extending through to distribution channels. It enables companies to gain greater leverage from their plant and equipment by providing them with the ability to control downstream sales, production and distribution.
Developer is a software product which can be added on to CabMasterPro and higher level products.
Second generation applications are incapable of understanding objects and therefore rely on attaching attributes to lines. CabMaster Developer "understands" the objects it is working with, critical in ensuring that accurate information is passed onto the manufacturing environment.
Properties can be built-in or user defined. Formulas in the middleware can use either, and there is no difference in syntax.
Built-in properties have predefined names that you should not use when defining your own, user defined, properties.
Built-in properties exist at all levels and have predefined names that are documented for each built-in field.
Only Middleware developers edit the Library properties. These are overwritten with Catalog properties and together they initialise Drawing properties for a new drawing.
In the Table of Contents look under:-
Table of Contents
These two are cross linked to easily go from one to the other, and the Formula Reference documentation shows tool tips and defines the built-in names for every control.
Example Formula Reference for Machine Step page
For example, here's some of the 'Machine Step' built-in properties. Hovering over the red and yellow numbered boxes attached to each field gives a tool tip which has the built-in name for that property, and clicking on the number takes you to more information.
User defined properties can exist at these levels:
At all these levels, there can be user defined friendly pages. As described above, these are just convenient ways of editing the user defined properties. The properties themselves have names (like MyThickness or HasHinges) and values (like 16mm or yes).
For a more detailed discussion, Formula Reference > Syntax rules for user defined variable names and data types.
Library and Catalog properties are a special case, only accessed on demand whenever the search for a property gets up to drawing level and fails. As explained earlier, when this happens, the property found is copied permanently from the library+catalog into the current drawing properties as a last step in the search. Once the property has been copied into the drawing properties the library+catalog will not need to be referenced again, so the drawing can be saved and reopened without the library being available, or with a different library selected as the "current library" and the drawing properties will stay as they were when the property was first copied into place.
The catalog wraps around the library and properties are combined into one set during your session, so the "library+catalog" actually behaves as though it is one object, even though it is maintained as two files externally. This has lots of advantages for maintenance and ease of both creating families of related objects and updating the friendly pages of the whole little family in one go.
It is possible to save one or more catalogs based on a library but with different names. For example, as well as the CM-Cabinets.qim catalog, we could save a new catalog called MyCatalog.qim which is also based on the same CM-Cabinets.qil. To do this, you can just save the catalog with a different name, and the system will automatically add the builtin property _BasedOnLibrary to the drawing properties of the MyCatalog.qim catalog. This will signal to the system to open and use CM-Cabinets.qil as a based-on library when dealing with the catalog MyCatalog.qim. For more on how to do this see topic on Catalog Properties.
Sometimes the _BasedOnLibrary is also a full or relative path to a different folder. If you want to access the name of that folder for other reasons, there is a builtin middleware variable for both BasedOnLibrary and BasedOnLibraryFolder for that purpose. An example “3 Cab Library” with its little catalog can be downloaded here. Simply unpack these files to the Library folder and open a new drawing with this library. You can also open a new drawing with the other catalog (qim) present, which is a variation “basedon” the same QIL (base library) - see also Miscellaneous Functions: LibraryList and Constants.
Tool properties are also a special case. These live within each tool (such as the Textbox tool) and can be saved to QTD files for future. Use the Load and Save menu options you get by right clicking on a tool to access saved QTD files for a tool. Some tools (like AutoDimension and Capping) have a lot of details to save, so these can be quite complicated with friendly pages in front of them to change property values more easily.
All drawing files (QID), library files (QIL) and catalogs (QIM) and Templates (QIT) are compressed internally. This means that they still expose searchable properties to Windows File Explorer, and they still offer File Explorer previews i.e. they are indistinguishable from the old files but are considerably smaller.
Because of the performance of the Windows File System vs the compression algorithm, there does not appear to be any real time overhead in saving and loading these compressed files.
In some cabinets, we have multiple container sections, each importing the same thing, say a Drawer, but assigning different properties to it.
For example, here is a simple 'drawer box' imported into two sections.
It is the same drawer box, and has a friendly page to control its 'DrawerHeight' property, like the following.
When storing this cabinet in a catalog, we can also create new variations of this cabinet, with drawers of different heights again.
UserTracing is an advanced feature for various tracking/timing/troubleshooting needs. When looking at the performance of libraries and middleware generally, it can be useful to trace calls to some of the middleware functions, such as those reading files or evaluating table lookups.