Log In    |    Knowledge Base    |    4D Home
Tech Tip: The Ins and Outs to using a User Startup Method
Published On: January 6, 2012
Your current browser may not allow you to download the asset. We recommend Mozilla Firefox or Google Chrome.
Log In

The database method "On Startup" is universally used to contain application initialization code or call startup Project Methods to accomplish the task of executing application initialization code. Regardless of where the code is executed, the common purpose is to initialized variables to establish a known state upon which all subsequent execution is based.

What is less commonly practiced is the use of the "second" or "alternative" way to initialize an application's startup state, a User Startup Method. For those unfamiliar with the User Startup Method there are two ways it can be set, first in the Manage users and groups dialog, see image below, and from the command Set user properties. What is the big difference between the two? The User Startup Method runs immediately after the On Startup method.

When the 4D Password system is activated, a User Startup method can be assigned to each user. When the 4D Password system is not activated, only the User Startup method assigned to the Designer is called.

Assigning a Project method as a Designer's User Startup Method can be very handy. Say the goal is for the Designer alone to have access to the design environment at startup. An easy thing to do would be to place the TRACE command in this method that the designer would have the option from the Debugger to drop into the design environment or to continue on.

The drawback to using User Startup methods is both a minor and a major one. The minor drawback is for the designer as the entire On Startup method will have run to completion and the goal might have been to break into the design environment before the On Startup method had run. This drawback can be overcome by the placement of some trapping code in the On Startup method that the designer can activate.

The major drawback is that without paying careful attention to the contents of the User Startup method, code can exist that negates the assumptions made regarding the startup state of the database. That could make it very difficult to isolate bugs that seem to be contrary to expected state of the database.

The point is to verify that when User Startup Methods are used that any code that is executed is within the scope of that user and not in the global scope of the entire database application.