Are there any performance issues with MDIchild windows

rogercurtishall

Someone has claimed this in regards to using windows opened via START_MDICHILD vs. those opened using START_WINDOW. Does anyone know if that is true or not?

DonBakke

Some has claimed what?

rogercurtishall

That OI windows opened as MDI childs do not perform as quickly as windows opened otherwise.

DonBakke

I've never heard of that being an issue before. However, Start_MDIChild is a wrapper around Start_Window so if you were to call it several times in a loop then eventually you would see a performance difference. But for regular launches of a window I have serious doubts there is a measurable difference. I think all Start_MDIChild does is call Start_Window with the optional arguments so that it knows how to configure the form correctly.

If someone is certain they are seeing a difference, I suppose it could be due to the MDI handling in general.

rogercurtishall

Hi Don. Thanks for that info.

What else do I need to do besides running Start_MdiChild to get a window to open within the desired frame? Some windows seem to do this, but changing the Repository 'EXECUTE' call from Start_Window to Start_MDIChild is not opening the frame and putting the window within it.

DonBakke

Roger - I'm not certain how to create an MDI Child without using Start_MDIChild. This isn't common knowledge or documented anywhere. If I were eager to figure it out, I would create hooks for Start_Window and observe the incoming parameters to see if they reveal anything. I'm somewhat certain this is a stylebit change in the window's structure, and this cues the MDI Frame into opening it within the frame.

Having said that, why are you going down this route? Have you confirmed that there is a noticeable difference in performance? The hook technique can also be used to benchmark performance. This is what I recommend you focus on before wasting a lot of time experimenting with a workaround that might not even be necessary (or do anything).

rogercurtishall

I am not trying to create an MDI child w/out using Start_MDIchild. I am trying to figure out why some windows don't seem to work when I change the logic from Start_Window to Start_Mdichild. The frame is not opening and the windows are not being centered within it. I have been looking at the windows and the program logic and I don't see why that is.

DonBakke

I see. Well this is a different problem than what this thread started out to be. I take it that when these windows are not being opened in the frame that they also do not call their own CREATE event handler?

rogercurtishall

All these windows, both those that open within the frame and those that don't, have Create event handlers.

DonBakke

My question was whether these problematic windows are calling their CREATE event handlers, not whether they have one. Just trying to help you isolate the problem.

BTW, hooking can also be used to determine if there is a speed bump along the way. You can track to see how far the call stack goes when creating these problematic windows. Of course, this is only necessary if your CREATE event doesn't get called.

rogercurtishall

The create events are being called in these windows.

DonBakke

To recap: you have windows that are called via Start_MDIChild, they execute their CREATE event handlers, but they are nowhere to be found on the desktop or within the MDI Frame.

In the CREATE event handlers, what are the values of the VISIBLE, PARENT, and MDIFRAME properties?

rogercurtishall

Are all of these properties for the window being launched?

DonBakke

Yes. I'm hoping these might reveals clues as to what is happening.

rogercurtishall

Visible = 0 for both windows, good & bad, at the start of their Create events and the MdiFrame & Parent properties are the same for both, meaning the same window frame and parent being .MDICLIENT.

DonBakke

Those are track for me. If the windows are not visible, are you doing anything to set the VISIBLE property to 1?

rogercurtishall

Not for the window, at least not in the commuter module.

DonBakke

I think it makes sense to make this visible in the commuter module and see if that does anything.

rogercurtishall

I am looking at the commuter modules for other windows which work, and they don't set Visible to 1. To me, that suggests this must be happening somewhere else. I am not seeing how though.

DonBakke

I'm not suggesting we will have arrived at a solution, but it will tell us something if setting the VISIBLE property to 1 actually displays the window. Have you at least tried this?

rogercurtishall

That does work, but it is not centering it within the frame like the other windows.

DonBakke

Okay. That tells us that Start_MDIChild itself is not your problem. There is something else, most likely in the application logic, that is the problem. I'll leave that to you to unravel.

rogercurtishall

Actually, I think I just found it in the Promoted events. There is a lot of logic which only works for DBW and NDW windows, and the problems windows all have odd, non-standard names.

DonBakke

I was guessing it was in a promoted CREATE event handler.

rogercurtishall

The problem starts there, but I see the same issue in other events having to do with other stuff like swapping the push buttons used for the child windows. Thanks for your help.

rogercurtishall

Hey Don. Towards changing one of these currently non-MDI child windows into such, I have created a new DBW window with its own commuter module, and changed all the window events to specify that. Then I changed the launch program to call Start_MDIchild with it. The window's commuter module is not being hit though. Is that because all the control events on that window specify the old program? If not, what else could cause this? Thanks.

DonBakke

I want to make sure I understand a few things...

Towards changing one of these currently non-MDI child windows into such, I have created a new DBW window with its own commuter module, and changed all the window events to specify that.

I take this to mean you made a copy of an existing window for the purpose of it becoming an MDI child. You also created a commuter module for this new window.

Question: In what way are the window events calling this commuter module? Are you using the "Call Commuter Module" feature of the QuickEvents? Are you calling the commuter module directly through a script event handler? Something else?

Then I changed the launch program to call Start_MDIchild with it.

Is this being called from a menu item or a button on the MDI Frame?

The window's commuter module is not being hit though. Is that because all the control events on that window specify the old program? If not, what else could cause this?

I don't have enough data to answer this, but an answer to my above question about how you are calling the commuter module would help. Is the name of it the same as the form? Are there hardcoded references to the original window?

BarryStevens

Normally mdi_child windows cascade when called, you must have a centrewindow call somewhere, so maybe check there.

rogercurtishall

These windows are using script events, so I changed the ones for the window I saved as Dbw_Mywindow, including Create, to follow the same pattern as other windows which open as MDI children. In other words, the Create script has:
declare function Dbw_Mywindow_Events
Return Dbw_Mywindow_Events( "CREATE", CtrlEntID, CtrlClassID, CreateParam )
The windows are launched by clicking buttons on another window which is inside the frame. The are no hard-coded references to the old window.

BarryStevens

what does your Start_MDIChild params look like.

Is this OI9 or Oi10?

For one of the forms in question, in form designer, change the visible property to 1 and see that it does display. If so, then your promoted create or commuter create is not setting it.

BarryStevens

Return Dbw_Mywindow_Events( "CREATE", CtrlEntID, CtrlClassID, CreateParam )

Is this returning a 1