[Widgetry] some small glitches ?

Hi,

Well widgetry certainly makes it much more easy to write complexe Gui's then Wrapper.
And allthough the new XP look only changes things in a minor way Wrapper suddenly looks very dated.

I still have some issues though.

1) The TreeView showRootImage:  message does not seem to have any effect on making my root invisable.

2) When flying over an unselected TabControl the widget sharing its frame (the empty space in the right upper corner) dissappear but re-appear when I select a tab.

Rgrds,

Maarten,

Maarten,

>1) The TreeView showRootImage:  message does not seem to have any effect
>on making my root invisable.

This is correct. This message only controls the image, not the root itself. To
have the TreeView show or not show the Root object, you need to tell the Tree
object dispalyRoot: <aBoolean>

>2) When flying over an unselected TabControl the widget sharing its
>frame (the empty space in the right upper corner) dissappear but
>re-appear when I select a tab.

Do you mean the scroll buttons? I'm not sure I see what you see here.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Hi Samuel,

Maybe with the enclosed images it is easier to understand.

Rgdrs,

@+Maarten,

 

> Maarten,

>
> >1) The TreeView showRootImage: message does not seem to have any effect
> >on making my root invisable.
>
> This is correct. This message only controls the image, not the root itself. To
> have the TreeView show or not show the Root object, you need to tell the Tree
> object dispalyRoot:
>
> >2) When flying over an unselected TabControl the widget sharing its
> >frame (the empty space in the right upper corner) dissappear but
> >re-appear when I select a tab.
>
> Do you mean the scroll buttons? I'm not sure I see what you see here.
>
> And So It Goes
> Sames
> ______________________________________________________________________
>
> Samuel S. Shuster [|]
> VisualWorks Engineering, GUI Project
> Smalltalk Enables Success -- What Are YOU Using?
>
>

Maarten,

>Maybe with the enclosed images it is easier to understand.

Ah. I see. You are putting a pane in the display space of the TabControl.

There may be a way around this. I suspect that in your createInterface, the
CheckBox is added before the TabControl. This puts the CheckBox behind the
TabControl in the Z order. Thus, when the TabControl wants to refresh its tabs
(which covers ALL of the tab area for the width of the TabControl, not just the
area where Tabs appear), it blots out the CheckBox.

Try moving the adding of the CheckBox after the TabControl.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Is there a way to control the z order once the panes are added.  I  
had tried putting some forms on top of each other, then making one  
visible and the other invisible.  This worked, but if the invisible  
one got some background changed that caused it to paint, the visible  
one had to paint too, but sometimes only a part of it.  I just  
stopped trying to stack them, but you may want to have a think about  
this.  Also, I think I noticed that if I made a form invisible, but  
called isVisible on something in it, which returned true.  Don't  
think this is quite right.

One more thing, if you add components to a Form using the  
#addComponentsFromClass: or #addComponentsFromInterface: methods, the  
hostPane hierarchy is not set correctly, and a widget in the form  
cannot ever get access to the top most Panes or Windows.

Mike

On Jul 31, 2007, at 10:41 AM, Samuel S. Shuster wrote:

Mike,

>Is there a way to control the z order once the panes are added.  I  
>had tried putting some forms on top of each other, then making one  
>visible and the other invisible.  This worked, but if the invisible  
>one got some background changed that caused it to paint, the visible  
>one had to paint too, but sometimes only a part of it.  I just  
>stopped trying to stack them, but you may want to have a think about  
>this.  Also, I think I noticed that if I made a form invisible, but  
>called isVisible on something in it, which returned true.  Don't  
>think this is quite right.


The ability to modify the Z order is on my list of things to do. It will be a
while.

>One more thing, if you add components to a Form using the  
>#addComponentsFromClass: or #addComponentsFromInterface: methods, the  
>hostPane hierarchy is not set correctly, and a widget in the form  
>cannot ever get access to the top most Panes or Windows.

Well, hostPane for a the panes that circumstance is the form itself. #topPane
sould always point to the top Window once the form is added to the world.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Yeah, calling topPane or mainWindow should get you up to the top.  This does not work from a widget within the form, that was put there through the #addComponentsFromClass: methods.

Mike,

>This does not work from a widget within the form, that was put there  
>through the #addComponentsFromClass: methods.

Right. This is because those components are added to the form, and at that time,
the form is the hostPane. During the adding operation, you can't talk to the
topPane, because, well, there is none.


                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?