Tag Archive: Cincom ObjectStudio


Software developers are lucky people. There are many different application development environments available to choose from these days. Lots of them are well suited to getting work done quickly—if your database and object design can follow their simple rules.

On the other hand, software developers are often not that lucky in their projects. Out of all the projects they’ve worked on, how many were pure “green field” development, where they had full control over all aspects of their database and object model? How many had to connect new processes or requirements to existing data stores whose schemas could not be changed or were ill-documented (or both), or else had to interface with a DBA group who had their own rules about naming? This is a situation where Smalltalk can really shine.

System>>whenIdleSend:to:args: – Blessing or Curse?

Microsoft Windows has one thing in common with Smalltalk: It works by sending messages. A Windows message can also be “posted,” i.e., it is put at the end of the Windows message queue, and the sender doesn’t wait for a synchronous response. The idle queue in Cincom® ObjectStudio® classic was designed in part to mirror this activity in Windows. While the design as a whole is very useful and sometimes plain necessary, it can be overused.

In ObjectStudio classic, it was pretty standard to delay some action using System>>whenIdleSend:to:args:. The VM made sure that the message was executed after the current code was executed, but before ObjectStudio became “idle” It was also assumed that those messages were to be executed in the same order in which they were added to the queue. Since most applications never used multiple, native threads, the assumption was correct. Unfortunately with ObjectStudio 8 and the so called “Multi-Proc-UI,” these assumptions are not 100% correct any more.

GLORP Database Converters

While working on the new Cincom® ObjectStudio® mapping tool that generates code for the object-relational mapping framework GLORP, we built some GUI for handling database converters.

Let’s take a quick look at today’s GLORP database converters. Database converters are used for converting back and forth between database and object representations. They are used by Direct Mappings where one column of a table is mapped with one instance variable of a class.

A Direct Mapping in GLORP is normally coded like this:

(aDescriptor newMapping: DirectMapping)
              from: #catalogID
              to: (table fieldNamed: ‘CATALOG_ID’).

Depending on the information in the table and class model descriptor, GLORP automatically assigns a database converter to the mapping. In this particular case, since catalogID is a string and the field CATALOG_ID is defined as a varchar:, 255 GLORP will assign it the DelegatingDatabaseConverter named stringToString. So if you want different behavior, you can write your own converter and assign it to the Direct Mapping with the converter: setting method.