Possible bug 64 bit version - RemoveForm

bhaughn

I was working in our OI10 system and may have found an issue. I'm hoping it is just how we ended up calling all of the commands. We have a console multi page screen, which has a SRP.PANEL.1. We are embedding a dynamically created window structure that contains a few shell.explorer objects. All of this works fine until we use the RemoveForm on the panel later when we destroy the window embedded in the panel to put a new one in.

When I check for handles, anything that was a shell.explorer ole control was not removed and still exists. I found this as when we added the new structure to the panel later, if anything had a similar name as the ole controls that could not be removed, they would be left out and the panel would not have the window structure I want.

I updated my code to check for handles and if they exist do a manual utility destroy on the controls that couldn't be removed to get around this, but this wasn't acting the same way in the 32 bit version of the same screen/panels.

Don't know if something changed that we need to change our code for or if something in OI10 is reacting differently, but thought I'd post here in case someone ran into this before.

KevinFournier

The short answer is no, we haven't experienced this, but we don't have any OI 10 systems in development at the moment using SRP Panel.

Just so I get a clear picture. You are creating a whole form dynamically and using SetForm to embed it into the Panel control? And when you use RemoveForm to remove it, it's leaving behind ShellExplorers? Are they being left in memory or are they visible on the panel? Is RemoveForm being called before the form is dynamically destroyed?

I'm interested to know your design goal, that is, the reason for swapping out dynamically created forms. The panel also supports AddNamedForm and other related properties and methods to support the ability to embed multiple forms but only show one at a time.

bhaughn

We're technically reading the windows structure of "N" windows, and compiling those into one window structure we use the SetForm command for. The number of windows being read is determined by user choices and can change on the fly.

We're doing this as the screen in question is a console of sorts where users select a number of gauges to be visible on the form, and we thus dynamically add those gauges based on choices. They can add and remove them on the fly. Most of the controls in each gauge are simple buttons and labels, except for one shell.explorer object per gauge to have the actual visual gauge we show the user.

When we use the RemoveForm with destroy set, we visibly see everything gone, but if we check for control handles, we can still see any of the controls that were that shell.explorer. The rest of the controls are properly destroyed. I compared to the 9.4 system, and this is only happening in the OI10 system (if that helps) with the same code.

KevinFournier

My guess is that changes in OI 10 do not let us destroy the window using the WinAPI, which is RemoveForm is trying to do. I recommend trying the following steps:

1. Set the form's VISIBLE property to 0
   
2. Call RemoveForm with the Destroy parameter set to 0
   
3. Manually destroy the form.
   

The Panel control doesn't have control over how an OI form destroys itself. All it can do is call the CloseWindow API and hope that OI 10 takes care of it. It's possible that some of OI 10's form "cleanup" logic is at the BASIC+ level, which means the form should be closed using BASIC+ routines. Thus, the above steps might have better success.