CabMasterPro User Guide
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 AMS 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.
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). See the Formula Reference for a more detailed discussion of the 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.
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.
With v12, 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. They are really indistinguishable from the old files, other than they 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.
