.Initialize not running on one particular shared database

UPDATE2: The problem has returned in the new shared shared database! Not solved. Bummer.

UPDATE: This problem is solved, but I thought I would leave you this message in case it is of any interest. I deleted and detached the database from the server, then shared it again. After doing that, the .Initialize function ran normally.

============
.Initialize does not run in my Navigator shared database when opening. (I put a console statement as the first line of the procedure and in another test, as the only line in the procedure, but no message appears in Console.) This is true whether PanX is already running or not. Console displays this message:

Timer _Temp_3384110 error:rectangletweak( function error – negative rectangle height.

That’s not a timer I started. Other databases do not have a problem with their .Initialize function. If I run the .Initialize procedure after the db is open, it works without a problem.

BTW, the same message appears if I start PanX with terminal.

BTW, I had an old version of Navigator that showed some annoying behaviors, so I created a new database, copied all the forms and procedures, dumped the old Navigator as a shared database and deleted from the server, and named my new db Navigator. Navigator had server variables, but I don’t see how that can be an issue. True?

Update 3: Now I have gotten this error, which may be to be related to the console statement:

Does your .Initialize code contain a rectangletweak( function?

No, it does not have a rectangletweak( function.

I found a rectangletweak function in the OpenASyncProgressWindow procedure and commented that out. That did not resolve my failure to initialize in my Navigator database, but maybe that procedure has an issue that explains the error message above.

With further testing, when I comment out line 73 (or 72), which says

availableArea = rectangletweak(availableArea,"widthfromcenter",windowWidth,"+heightfromcenter",-200)

from the OPENASYNCPROGRESSWINDOW procedure in the _DialogAlertLib, the .Initialize function runs properly. It seems to have fixed the problem that I started this post with. I don’t confess to know why this works, but it seems to.

I’ve got a 1080 by 1920 screen, with the dock on the bottom. I can use the formula wizard to display the available screen size.

rectanglesizestr(info("availablescreenrectangle"))

On my computer, the available height is 994 points.

Based on the error you are getting, it would appear that the height of your screen is much smaller than that, less than 500 points. That seems impossible. Could you try this formula and let me know what the screen height is?

Perhaps also try this formula, which returns the total screen size, including the dock.

rectanglesizestr(info("screenrectangle"))

On my computer this returns:

0,0,1080,1920

The code in question is looking for a spot to display the small progress window that appears when synchronizing a database with no visible windows. This code assumes that the screen is at least 400 points high, which I thought was a safe assumption. The error message you are encountering seems to indicate that this is NOT a safe assumption, which leaves me rather amazed. Or maybe there is a bug in rectangletweak(, I will look into that, but that is a pretty well tested section of code.

Ok, I have verified that rectangletweak( is valid and that the line of code you commented out will work for any screen height 200 points or more. So I am now even more curious to know what the results are for info(“availablescreenrectangle”) and info(“screenrectangle”) on your computer. If these functions didn’t work, I would think you would be encountering other problems like dialog placement, but I guess there aren’t many standalone dialogs (not attached to a window) in Panorama any more. Also, I take it that this problem has occurred on more than one computer?

Are you using Spaces? Perhaps that has some effect on these functions – I don’t use that feature.

On my computer, which is using Spaces, the results of the two functions are
23,0,1065,2048 and
0,0,1152,2048
There are certain no computer used by me or in the firm with a screen height of less than 500 pixels.
The problem I first reported still occurs intermittently. Commenting out line 72 as described above seems to prevent it from occurring, even though that does not seem to make sense.
I guess we should move on to something else, since this issue is under control.

I’m definitely going to make a change, can’t leave that error in. I was hoping your results might inform how I proceeded, but they don’t. I was kind of thinking maybe the function would return a height of zero, failing completely.

The code that is in there now is trying to center the progress window on the screen so that it looks nice. I’ve added a check for this error, and if that happens, it will just place the window near the upper left corner of the screen. Not as cosmetically pleasing, but vastly superior to an error message.

I’ll bet the intermittent nature of this is due to the fact that this code is not called every time the database opens, only if it needs to be synchronized or updated. In fact, I think it doesn’t always happen if synchronization is needed, only if it is a fairly large amount of data that needs to be synced, enough to make it worth displaying a progress window. So most of the time, you won’t see the problem.

Hmm, now that I have written that down, I wonder if the line you commented out had anything to do with it. In fact, I see the problem – it’s not that line, the problem is two lines below that. I forgot that there is another case where it displays the progress window – if the tool bar is hidden. You have the tool bar hidden on some of your databases, don’t you (I think I’ve seen that in some of your screen shots). In that case it is trying to center the progress window in the current window, and most likely in this particular case the window is less than 200 pixels high. That would immediately cause this error, but it would be very intermittent, as I mentioned in the last paragraph.

So, now I think I’m pretty confident I really know what is going on, and I have made the fix. I also added additional instrumention, so in case I’ve botched the fix, the needed data will be in the log.

In the meantime, I’ll bet you’ll eventually see this error again. Or, if you want, since you’ve already updated the OpenAsyncProgressWindow procedure, you can do it again to put in the fix – here is the revised code, starting from line 67:

let availableArea = getdictionaryvalue(taskInfo,"WINDOWRECT",rectanglesize(0,0,0,0))

zlog "caller provided availableArea: "+rectanglestr(availableArea)

try
    if rheight(availableArea)<220 or rwidth(availableArea)<windowWidth+20
        zlog "availableScreenRectangle: "+info("availablescreenrectangle")
        availableArea = rectangletweak(info("availablescreenrectangle"),
            "widthfromcenter",windowWidth,"+heightfromcenter",-200)
    else
        availableArea = rectangletweak(availableArea,"widthfromcenter",windowWidth,"+heightfromcenter",-200)
    endif
catch
    availableArea = rectanglesize(100,200,400,windowWidth)
endcatch

zlog "adjusted availableArea: "+rectanglestr(availableArea)

The next line after this is:

let openProgressWindowNumbers = getformoption("_DialogAlertLib","Progress","clonewindownumbers")

I’m not sure what line number that is in the code you have.

I am so glad you figured that out. What you wrote seems explain everything I have observed. The window involved (in the Navigator database) is small:

![Screen Shot 2020-08-26 at 9.20.15 AM|522x320, 50%]

The toolbars are never visible; I always turn them off. There is almost no data in there; although this is about to change, but it has been updated with minor changes occasionally. (I am going to use the database to collect some data on usage–when a user does a certain activity, that gets logged here.).

I will amend the OpenASyncProgressWindow procedure as you suggested. Thanks!

I amended by OPENASYNCPROGRESSWINDOW procedure. To distribute this to others, can I just update their procedures? Will this be included? Or should I distribute a copy of the complete PanoramaX package?
UPDATE: updating procedures did not update this particular procedure. So I will distribute PanX to everybody.

Correct, because that procedure is not in your database, it is in Panorama’s libraries. Normally that is not modified by users, and there is no provision for distributing changes made to those procedures other than copying the entire application as you did.

Another way to look at it – when you use a new generation to update procedures, only procedures in THAT database are updated. If you’ve changed a procedure in another database, you must do another new generation for that database. If the database isn’t shared, there is no mechanism to send procedure changes to other users. Library databases, which are internal to Panorama, aren’t shared.