UI Component Not Hiding

[Neil Morrison]

Hi all,

I've been doing some cleanup of older logic in our system - we used to depend on various Ole bits and pieces (OLE Controls and registry access).
We no longer use this so wanted to remove them from our dependencies before it was forced on us.

I've included a simple export of an example that reproduces the issue.
The issue is most likely the way we do something but haven't had much luck yet figuring it out.

The issue, we define a standard Abt UI part with a shell. We also have another part which is visually not on the shell but on the freeform (we do this as we can switch between components).

The panel in question has 2 components on it - a blue form and a yellow tree view control. The tree view control is marked as hidden.

During the openedWidget event we change framing specs and set the appropriate mapped states. The panel's parentView is changed to now be the shell window.

The window but are presented by a grey window (this is actually the hidden tree control!!!) - should be yellow!!!  It should be showing the blue panel.

Press the button the hide the tree view and voila the blue panel shows.

This behaviour works when we have the ObsoleteOle stuff loaded.

Issue is most likely to do with how we wrangle the change in parenting etc.
Can someone shed some light on how this should be done properly?

Thanks

Neil Morrison

[Neil Morrison]

Bit more digging - all starts working as soon as you load AbtRunOleApp (and associated dependencies).
If you load it's dependencies but not AbtRunOleApp it doesn't work!!
Still digging

[Marcus Wagner]

Hi Neil,

my first suspicion: Windows resource inheritance, from the beginning, 3.0. You mentioned an unexpected coloring, this inspired me.

Once one had to register a color palette, usually in the first shell, silently providing its properties to all children, created later in the execution path of the program.

So as you remove such a shell, all silent consumers become suddenly unsupported.

My tip: just look into any such resources provided by the shell which is going to be removed and care about to cover possible deficits elsewhere.

It does not have anything to do with the functional OLE support, which has to go. Look into open widget events or widget creation blocks while creatign the widget hierarchy.

This happens even below the Abt layer built upon that. That once was a windows builder area before.

If you could move the palette handling elsewhere (even if such a place is to be hidden again), the OLE part can go.

This behaviour or principle once was important, having very scarse graphical resources (in the hardware), which became more or less irrelevant.

Kind regards

M

[Neil Morrison]

Hi Marcus,

Thanks for feedback - I think my comments on colour may have drawn your attention from issue. I had used colour to highlight the issue (don't need the colours).



If you look at the sample I have a frame/shell and a separate panel on the freeform area.
When the window opens it changes the parent of the panel to be attached to the shell window and resizes (framingSpec) for the panel and the child components appropriately.
The yellow icon tree control is marked as hidden so should end up with a window the blue component showing.
What we actually see is a grey window with scrollbars which is the icon tree control (which is hidden). It seems that opening of the shell is creating the icon tree control visually even though it is supposed to be hidden.

What we see

When we use the Widget inspector the grey component is the icon tree control, which has been created visually (partially at least - not showing as yellow). This component should be hidden from view.

What we should see


With the AbtRunOleApp installed the shell becomes enabled for Ole embedding (which we no longer need and want to remove from our build) - with it not present in our image you get the grey window!

Hope that explains the issue a little better

Regards,

N

[Marcus Wagner]

Hi Neil,

sometimes I am uncentrated, sorry. 

I can reproduce the effect now. I will respond my findings, hopefully soon.

Strange...

Kind regards

M