I have two forms that are called as an MDI_CHILD.

When the form is "requested", it appears on the top of the parent window, which it should. However, as soon as the user enters any information on the form, via a dropdown, the form "hides" itself behind the parent leaving one to believe that it is no longer available. However if the user enters the information via the key board the form stays on the top. All the information entered is still present on the form when you move the window around to "see" the form.

Any ideas why it is moving to the back?? and how do I keep it on the top?

Just discovered that it is on any form that has a dropdown. The dropdown is using the popup feature.

Andy,

I'm not clear, is this resolved then?

dbakke@srpcs.com

SRP Computer Solutions

Don

Sorry about the confusion. The problem is not solved. I just realized that the problem is on any form we have that is called as an mdi_child that uses a dropdown that calls a popup.

Hope this makes sense.

Andy

Andy,

How about setting 'topmost' property/style in the create event - the effect is to force the window to float on top. Mmm - this may screw up the popup which is meant to sit on the calling window.

Check the parent of the Popup - is it set to the MDI child or the Frame?

Richard Bright

Andy,

Okay, I'll try to figure this out for you. I am confused, however, by some of what you are describing. You first indicate that you are launching two forms as MDI children, correct? Therefore I must assume you have an MDI Frame as well.

Then you say "when the form is 'requested', it appears on the top of the parent window, which it should." What do you mean here? The "parent" for an MDI child window is the MDI Frame itself. The MDI child window does not appear "on the top" by rather within the MDI client area. What am I missing here?

Next, when you say "dropdown", is that a synonym for a PopUp? Normally, in OI/Windows, dropdown refers to the list you get from a combobox control. I am assuming the former.

Going on my assumption, how are you launching the PopUp? Specifically what is being passed as the Parent parameter in the PopUp? My hunch here is that the PopUp function, which works like a modal dialog box, is resolving the parent to be the top most parent - which I believe is the default behavour. In this case, your original window which launched the PopUp is getting hidden because the other window (i.e. the one PopUp believes is the true parent) is forced to come forward.

Until I know more specifics, however, that's the best I can suggest as to what is going on.

dbakke@srpcs.com

SRP Computer Solutions

Don

Hopefully this will clear up your confusion. I am using in this example the report form (DTKW_DISPENSER_REPORT_INPUT) and the popup MKT_REGION. Please note that only one of the popups use the MKT_REGION and anywhere where DTKW_DISPENSER_REPORT_INPUT is used it is as an example.

We have a form called MDI_OPENING_SCREEN which is an MDI_FRAME.

When activated the MDI_CLIENT_WINDOW executes

   QUICK EVENT 

        ACTIVATED START_MDI_CHILD

        parameters ?DTKM_MAIN?,?@MDIFRAME?,??,??,??,0

A script is also executed that does a SET_PROPERTY to position the DTKM_MAIN frame in the upper left corner of the MDI_CLIENT_WINDOW which works with no problem.

The menu of the DTKM_MAIN is displayed in the MDI_FRAME. This menu contains various dropdown options. Each drop down that activates a form is set up in the following manner:

   QUICK EVENT

        ACTIVATED EXECUTE A PROCEDURE

        SYSPROG*STPROCEXE**START_MDICHILD

        parameter DTKW_DISPENSER_REPORT_INPUT,?@MDIFRAME?,??,??,??,0

        return value in

             control @SELF

             property TEXT

This loads the DTKW_DISPENSER_REPORT_INPUT form and it is the active form with the DTKM_MAIN behind this form. (Please remember that DTKW_DISPENSER_REPORT_INPUT is used as an example, each menu item calls its particular form.) This particular form has 5 combo boxes each with their own popup. Each combo box has the style as

   DROP DOWN

   VISIBLE

   each with a data base association.

   QUICK EVENT

        DROP DOWN EXECUTE A POPUP

        TESTING*POPUP**MKT_REGION

        parameters ?DTKW_DISPENSER_REPORT_INPUT?

        return value in

             control @SELF

             property TEXT

When you click on the combo box down arrow on any of the 5 boxes (we?ll use region for the example), the appropriate popup is displayed. You select the region wanted and at this point the DTKM_MAIN form becomes active and becomes the ?top? form, the DTKW_DISPENSER_REPORT_INPUT is ?hidden? behind the DTKM_MAIN. The data selected from the popup is in the appropriate box on the hidden form.

If you move the DTKM_MAIN window down or out of the way, the DTKW_DISPENSER_REPORT_INPUT is there, unactivated of course. Clicking on the form reactivates it.

We also have help screens behind each field a user can enter on any form. The help is setup as a

   QUICK EVENT

        HELP DISPLAY QUICKHELP

        TESTING*APPNOTE**REPORT_REGION

        parameters DTKW_DISPENSER_REPORT_INPUT

Any time these are activated, the same thing happens.

All forms are doing this, not just the report forms.

Should we not load the forms as an MDI_CHILD??

I really believe that it is something simple which leads to the old saying

   ?A human is smarter than a computer, but a computer is smarter

    than a programmer!?  

Interesting note ? I set up a form called ABC and had the MID_CLIENT_WINDOW call this ABC form. The ABC form has a script that loads DTKM_MAIN as an MDICHILD and the above does not happen. However, when DTKM_MAIN is closed, the ABC form does not reappear, only a blank MDI_CLIENT_WINDOW. Very interesting don't you think? Know of any way I can make the ABC form appear when the DTKM_MAIN form is closed?

Thanks for your help

Andy

Andy,

I think the problem is with the ACTIVATED QuickEvent that launches DTKM_MAIN. When you start a PopUp this creates a modal dialog box. Consequently, your MDI_OPENING_SCREEN has become inactivated.

When the PopUp is closed the MDI_OPENING_SCREEN becomes activated again. This will then call your ACTIVATED QuickEvent, which attempts to launch DTKM_MAIN. My assumption is that DTKM_MAIN is a non-multiple instance window. Since a new instance cannot be launched, the existing DTKM_MAIN is brought to the front instead.

You really ought to move your logic into the CREATE event of MDI_OPENING_SCREEN in order to avoid this constant attempt to launch your DTKM_MAIN.

dbakke@srpcs.com

SRP Computer Solutions

Thanks Don - That worked like a champ.

I knew it had to be something simple.

Andy

Richard

Thanks for the input.

See Don's last response to me.

Andy

View this thread on the forum...