.Initialize and forms

Running 10.2.0.b24 on Monterey I’ve run into what appears to be a new version of an old error but this time I’ve tracked down the source.

In the ServerMonitor offered on the Database Exchange, the .Initialize includes a formxy 0,0

I have ServerMonitor in my login items so it launches when the machine starts. In that case, it results in an error: ‘.Initialize Error (ServerMonitor) FormXY statement must be used when form view is active.

The file has only one window, a form, that is set to open when it starts.

If I Quit Panorama and launch the file, it starts Panorama and opens the file without the error so it seems limited to machine startups.

In March, Robert Ameeti reported a bug in startup of the .Initialization procedure as reported by NSNotify: ‘SetFormOptions failed because database “” does not contain a form named “”.’ In that case the prime suspect was in setting the form color based on the monitoring status: FormColor rgb(65535,1000,1000)

Other than the formxy and form color there are no other references to the form.

I’m guessing these are related issues though and that the initialization is getting out ahead of the drawing of the form - but only on full startups.

I would remove this code from the .Initialize procedure.

First of all, a better place for form initialization code is in the Form Event Procedures code. You can set code to run each time a form opens, not just when the database opens. This also would avoid the problem that would occur if the form wasn’t open at all.

Secondly, you don’t need this code at all. Panorama automatically resets the upper left hand corner of the form to 0,0 each time a form is opened. So this statement is redundant.


If you DO put code in an .Initialize that requires that a certain form be open and active, then you had better include code to check to make sure that that assertion is true. There’s no guarantee what the active window will be when the .Initialize code runs, just that it will be a window in the database.

By the way, the code that calls .Initialize is open source, you can look at it, it’s the INITIALIZEDATABASE statement in the _DatabaseLib library. To save you the trouble of looking it up, here’s the relevant code:

if listwindows(targetDatabase)<>"" // could get called from clientopenshareddatabase with no windows
    try
        if catcherror(false(),procedureexists(targetDatabase,".Initialize"))
            zlog "===== Start .Initialize procedure ("+targetDatabase+") ====="
            topdatawindow targetDatabase
            zlogobjc "CodeTriggers","RUN CODE --> .Initialize ("+targetDatabase+")"
            call ".Initialize"
            zlog "===== End .Initialize procedure ("+targetDatabase+") ====="
        endif
    catch
        nsnotify ".Initialize Error ("+targetDatabase+")",
            "TEXT",info("error")
    endcatch
    try
        openauxiliary targetDatabase
    catch
    endcatch
endif

The code you posted includes a couple currently (B24) undocumented statements: zlogobjc and openauxiliary.

Well, it is internal Panorama code. Most statements do get documented, even many that are really strictly for internal Panorama use get at least a mention saying that, but not everything.

Hmm, I see that I actually intended to document the openauxiliary statement, the documentation is written but didn’t get included into the help file. For now you can view this documentation by viewing the source of this statement. I’m afraid it’s not very exciting, but it does provide an easy way to open any auxiliary databases associated with an open database if they happened to have gotten closed.

As for zlogobjc, it is used to generate log output if the Debug Instrumentation CodeTriggers option is enabled. This statement is only for internal ProVUE use. The Debug Instrumentation CodeTriggers option is a very cool new feature that was added over the summer, see Including Procedure Triggers in Debug Instrumentation at the bottom of the Debug Instrumentation help page to learn about it.