Cursor Trapping Panels

[James-S]

When using a layout widget type overlaying another layout widget type, I can click on buttons or other clickable widgets on the parent layout. I do not see any layout properties which would trap the mouse interactions to the overlaying layout.

This is problematic as buttons on the parent immediately return to the RPG program without forcing the user to press a button to close the overlay layout.

Any ideas would be appreciated.

Thanks!

[Scott Klement]

What do you mean by "a layout widget type overlaying another layout widget type"? You mean you defined two layouts located in the same spot on the same screen? Why would you do that, are you trying to make layouts work like windows?

[James-S]

Hi Scott. Thanks for the reply!

We have panels which allow the user to do what we call "Advance Search". Unlike a grid filter, we use this to limit the data loaded into a grid. These "Advance Search" panels are hidden until the user clicks an "Advance Search" button which then an onclick property runs a JavaScript to make the panel visible. What I see is the buttons on the primary panel are still active and the user can bypass the "Advance Search" panel by clicking a button outside the popup panel.

Including myself, we are still learning web design. Maybe our brains are still trapped in the old DDS overlay windows. :)

I found this example on the web. Notice the screen behind the "popup" is disabled and obscurred. This is what we are hoping to get our screens to do. Maybe this takes more HTML/CSS expertise than we have at this point.

[Scott Klement]

Hi James,

So the part that says "City Market Mail" is a layout instead of a window? (Unless I'm misunderstanding your description.)

In web programming, you can have multiple elements on the screen that you can tab to, put input into, etc. Even if they are physically on top of one another on the screen, you can still use them all. (This is just how web works, and isn't something we can change.)

I would recommend that you use a Profound UI feature called a "window". To do this, create a new record format for your "City Market Mail" content. Set the screen-level properties of this format to "show as window = true", and make sure the "mask screen" setting is unset (or set to true, which is the default for a window). With these settings, if you display the window (with EXFMT, or similar) it will overlay the existing screen, but it will "mask" the underlying screen which blocks input to any of the other widgets. This gives you exactly the same functionality you get with green-screen DDS window formats.

However, from your description, it sounds like you're not doing that, but instead putting a layout widget on the screen. Not sure where this layout is (since a layout isn't a record format, its just a widget, i.e. one screen element that can be combined with many other screen elements within a record format.) Is there some reason why you need to do this instead of creating a window as described above?

If you really do need to make a layout act like a window instead of coding an actual window, it may be possible -- but this will be more advanced coding than making a window format. I can describe this further if you need it -- just let me know.

[DanD]

Unsure if this is the same type scenario that you have. I have an application which has 3 layouts within a panel that all contain the same layout properties (left, top, height, width). The "visibility" is controlled by an "indicator" (bound variable) for each layout.

The "indicator" can be set via the RPG program - or within js for various events.

This will cause one of the 3 layouts to be visible & only allow the interaction with that layout. Unlike your example, however, since the layouts are all the same size, to the user, it simply appears as a "new screen" instead of a "window". In this particular application, it made sense (and it is not the easiest thing for me to make changes to, so it isn't what I'd necessarily recommend).

If you want a pure "window" effect, you'd likely want to define a new record format (or a new screen altogether) that has the "assume", "show as window" & "center window" properties set. This will make it show as a "window" & not allow interaction with the background.

Please note that when I was working on separate programs that worked with displaying "windows", I had an issue when a window was being displayed over a window (submitted to Profound as issue #4238 (Window disappears when second window is overlaid)).

There appears to be an activation group issue when the program that displays the second window is defined with dftactgrp(*caller).

When they were looking into it, I discovered that the solution to this is to define the rich display file with usropn

dcl-f pgm2df workstn usropn handler('PROFOUNDUI(HANDLER)');

Before any IO:

Code: Select all

If not %open(pgm2df);
   Open pgm2df;
Endif;

and before returning

Code: Select all

If %open(pgm2df);
   Close pgm2df;
Endif;

Hopefully this helps

[James-S]

I apologize for not replying to these responses from a few months back. I didn't realize responses had been posted. Need to check my notification settings.

I still have the issue with allowing interaction over the popup. I definitely will check out the "window" options.

Thanks!