Window Scrolling Issue

[neonate]

I have a form named “Book Detail”. The form properties are set to have a fixed window size (cannot change window size). Additionally, the scroll bars property for vertical and horizontal are not checked in the form properties.

I have field named “Description”. I have it set to allow vertical scrolling. As a test, I have filled the field to have more text than can be displayed so one would need to scroll down to see the entire text.

If I click, hold, and drag down to select all of the text, the scroll bar appears and everything works as expected.

If, while when I’m dragging downward, I have the cursor outside and below the window, the entire form scrolls and I can only view part of the form. A user would have to quit and restart the database to see the entire form. Note: the form background is white; my desktop is the pinkish/bluish area.

The form window should end slightly below the bottom of the buttons on the bottom row, but now shows blank space. I thought, because I had a fixed window size, this would not happen.

Is there anyway I can stop this behavior? Or is this some Apple feature?

Hope I explained this with enough clarity. Any help is appreciated.

UPDATE: Just found this from 7 years ago. I s this still this workaround?

How to recover from dragging a form's contents off-screen?

[pcnewble]

@neonate

Is there anyway I can stop this behavior? Or is this some Apple feature?

It often happens to me, including with Panorama’s own windows (especially help) and i wish I knew how to prevent it.

[admin]

It often happens to me, including with Panorama’s own windows (especially help)

Based on the discussion from 2018, I don’t see how this could happen with the Help window. And in fact, I cannot duplicate this with the Help window. How are you getting this to happen? I have never seen this problem in the Help or any other of Panorama’s windows.

As I commented in the older thread, I don’t believe ProVUE can fix this. The best solution is to make sure that any text box that might contain an overflow of text has a scroll bar.

If a window does get scrolled, you can fix it with the code

formxy 0,0

You could make a global hotkey with this code.

[pcnewble]

The only example that I can replicate at the moment is to drag downwards in the topics text list (in the text area, not the scroll bar) to scroll it downwards. Once the mouse pointer is past the bottom of the list or to the RH side of the help window (not just the topics text list), once it can no longer scroll the list itself it scrolls the whole form out of the current viewport. This isn’t really what I was thinking of, however, and is solved by closing the help window and opening help again, whereas I have previous encountered windows which will not revert to the top LH corner being (0,0) until Panorama is restarted. I’m guessing this depends whether the window concerned is opened as a clone or not.

@admin

If a window does get scrolled, you can fix it with the code

formxy 0,0

Indeed. My Form Event Procedure for most forms includes:

formFRONT:
    formxy 0,0
    return

which means that clicking away from the form and back to it again resolves such problems.

A form I’m currently working on contains a text list which fills the whole form apart from a search box and a couple of buttons at the top. There is an elastic window object to ensure the text list always fills the window when it is resized in either axis, therefore the form has no scroll bars but the text list has a vertical scroll bar. If I use up, down, page up, page down, home and end keys (on a MacBook keyboard: up, down, fn-up, fn-down, fn-left and fn-right respectively) to scroll as I usually would most windows, it scrolls the list as intended provided either the text list or search field has input focus. But if, after first opening the form but before clicking any objects I use page down to attempt to scroll it, the whole form scrolls away out of sight as if it had a vertical scroll bar, which it doesn’t. In that case, of course, as many page-up presses as there had previously been page-downs will restore the top LH corner to 0,0. But it is suboptimal for it to be possible to scroll a form that has no scroll bars by any means except programmatically using formxy.

In that same form in my database I can replicate the same behaviour as occurs with Help when dragging inside a text list.

Although I use the trackpad when using a MacBook on its own, on my desktop machines (including, most of the time these days, a MacBook in clamshell mode) I have always used a graphics tablet instead of a mouse. Although this suits me better in most respects, one disadvantage is that there is more chance of a click being interpreted as a drag, and it is drags which seem to cause this problem in Panorama which I have not encountered in any other MacOS application.

[admin]

Once the mouse pointer is past the bottom of the list or to the RH side of the help window (not just the topics text list), once it can no longer scroll the list itself it scrolls the whole form out of the current viewport.

Ok, I can duplicate this with the Help window, but only if I actually drag the mouse outside of the entire window. It doesn’t do it unless the mouse actually goes outside of the window. Also, if I don’t release the mouse, I can drag back up and it will scroll back into view again. However, if I let everything scroll offscreen and release the mouse, the only way to fix it is to close and reopen the window. (Ok, reviewing the original post from @neonate, he did say that he had to drag outside the window.)

I can see one reason why I’ve never seen this problem - I never scroll a list or matrix this way, in Panorama or any other program. I either grab the scroll bar and drag it, or I use the scroll wheel on the mouse (actually a gesture on my Magic Mouse, or on a trackpad).

I have not encountered in any other MacOS application.

You probably don’t have any other application that allows a window to switch between scrollable/nonscrollable on the fly, in Panorama’s case simply by clicking a checkbox. Apple really didn’t design their window system for this possibility. In pretty much any other application, a window either has scroll bars or it doesn’t, but you can’t choose on the fly.

Having scroll bars is not what makes a window scrollable. To make a window scrollable, you must add another component called an NSScrollView, then all of the other components are placed inside this view. Other apps that don’t have scroll bars also don’t have an NSScrollView. But Panorama windows always have an NSScrollView, even if there is no scroll bar. This is because at any moment you might click the checkbox and add a scroll bar, or you can even enable the scroll bar programmatically at any time.

Theoretically Panorama could rebuild the entire structure of the window when you enable/disable scroll bars. It would have to completely destroy all of the window contents, and then rebuild from scratch either with or without the NSScrollView. Back in 2012 or 13 when I was implementing form window I considered doing this, and decided it would be too complex. In addition to the complicated logic of switching back and forth (which would also always have to happen when switching into Graphics Mode, which always has scroll bars), every bit of form logic would have to have adjustments to account for whether an NSScrollView was present. Super high chance of additional new bugs with those adjustments, which would probably need to happen in dozens of places in the code, or maybe even hundreds of places. So I decided to simply always have an NSScrollView, whether or not scroll bars are visible. The downside is the edge case you have identified, but in my opinion this is worth it.

[neonate]

@admin

The downside is the edge case you have identified, but in my opinion this is worth it.

I agree. Thanks for following up with this.

[epansoft]

This issue happens in any form with text editors or text list objects including:

- Panorama X Settings, Site License, Server Administration, Memory Usage

- Form Blueprint & Field Blueprint

- Items under the Construct menu

- Open View & View Search under the View menu

- Find/Select & Find/Replace under the Search menu

- Items under the Morph & Analyze menus

- Items under the Program menu

- Items under the Help menu

However, this problem does not occur in any text editors in form properties or field properties.\

Adding the following code in .Initialize procedure will be the simplest solution for now. (It would not work in dialog windows since starttimer stops working whenever any dialog is open.)

starttimer "form00","code",{if info("formxy")≠point(0,0) and info("horizontalscrollbar")+info("verticalscrollbar")=0 formxy 0,0 endif}