Problems with view editor

Bug reports for OA:
1. If a shell does not have a preferredExtent, you get a walkback when
dropping it on another view as a reference view (Alt drop). The work-around
is to add a preferredExtent (but it took a while to figure out).
2. When an existing shell is opened in the view composer, the hasBorder and
hasCaption values are treated as true even if they are false. The
work-around is to check and uncheck the #hasCaption value.
3. I've got a situation where the #exit menu in in an outer shell's menu bar
is being received by a reference view child causing the reference view to
close leaving the parent view still very much present. I'm not able to
generate a simple case for it, however, so if it's not a know problem then
it can wait till I find out more.
Thanks,
James Foster

P.S. Will we see anyone from OA at Smalltalk Solutions?

James.

Thanks for the bug reports.

> 1. If a shell does not have a preferredExtent, you get a walkback
> when dropping it on another view as a reference view (Alt drop). The
> work-around is to add a preferredExtent (but it took a while to
> figure out).

Recorded as issue #2228. I guess we'd never really expected Shells to
be used as non-top level windows (at least not without some additional
work). If you are using them like this then beware of other tricky bugs
creeping out of the woodwork.

> 2. When an existing shell is opened in the view
> composer, the hasBorder and hasCaption values are treated as true
> even if they are false. The work-around is to check and uncheck the
> #hasCaption value.

Recorded as #2228.

> 3. I've got a situation where the #exit menu in
> in an outer shell's menu bar is being received by a reference view
> child causing the reference view to close leaving the parent view
> still very much present. I'm not able to generate a simple case for
> it, however, so if it's not a know problem then it can wait till I
> find out more.

It's not a known problem, but that is probably because (as I mentioned
above) we hadn't really intended that standard Shells be placed inside
other views (either as references or not). If you can come up with an
easily reproducible case then I'll record it for future investigation.

> P.S. Will we see anyone from OA at Smalltalk Solutions?

No, I'm afraid not. With limited time and budget available for
attending transatlantic conferences we've been less keen to take part
since StS became part of LinuxWorld.

--
Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

Andy,

Thanks for the comments. I'll go back and see about refactoring things
without using Shells that way. I suspected I stumbled into doing something
non-standard and very much appreciate being pointed back to the well-worn
path!

James


"Andy Bower" <bower@object-arts.com> wrote in message
news:5966g3F2jtnc2U1@mid.individual.net...
> James.
>
> Thanks for the bug reports.
>
>> 1. If a shell does not have a preferredExtent, you get a walkback
>> when dropping it on another view as a reference view (Alt drop). The
>> work-around is to add a preferredExtent (but it took a while to
>> figure out).
>
> Recorded as issue #2228. I guess we'd never really expected Shells to
> be used as non-top level windows (at least not without some additional
> work). If you are using them like this then beware of other tricky bugs
> creeping out of the woodwork.
>
>> 2. When an existing shell is opened in the view
>> composer, the hasBorder and hasCaption values are treated as true
>> even if they are false. The work-around is to check and uncheck the
>> #hasCaption value.
>
> Recorded as #2228.
>
>> 3. I've got a situation where the #exit menu in
>> in an outer shell's menu bar is being received by a reference view
>> child causing the reference view to close leaving the parent view
>> still very much present. I'm not able to generate a simple case for
>> it, however, so if it's not a know problem then it can wait till I
>> find out more.
>
> It's not a known problem, but that is probably because (as I mentioned
> above) we hadn't really intended that standard Shells be placed inside
> other views (either as references or not). If you can come up with an
> easily reproducible case then I'll record it for future investigation.
>
>> P.S. Will we see anyone from OA at Smalltalk Solutions?
>
> No, I'm afraid not. With limited time and budget available for
> attending transatlantic conferences we've been less keen to take part
> since StS became part of LinuxWorld.
>
> --
> Best regards,
>
> Andy Bower
> Dolphin Support
> www.object-arts.com

Hi Andy,

>> 1. If a shell does not have a preferredExtent, you get a walkback
>> when dropping it on another view as a reference view (Alt drop). The
>> work-around is to add a preferredExtent (but it took a while to
>> figure out).
>>
> Recorded as issue #2228. I guess we'd never really expected Shells to
> be used as non-top level windows (at least not without some additional
> work). If you are using them like this then beware of other tricky
> bugs creeping out of the woodwork.

I've mentioned a number of other issues with the visual designer and you
have'nt confirmed workarounds or bugs on them - is there anything additional
that you would need to get them logged as bugs?

e.g.

D6 Visual Designer - can't always select inside container (06/03/2007)
Changing a menu in visual designer causes nasty deaf object image shutdown
(12/02/2007)

Tim

> D6 Visual Designer - can't always select inside container (06/03/2007)
> Changing a menu in visual designer causes nasty deaf object image
> shutdown (12/02/2007)

I also forgot to mention:

D6 Bug - ScintillaView has incorrect selector for #canScrollPastEnd (19/03/2007)

Hi:

In the ViewComposer deleting a view resource from the composition arena
using the "Edit\Delete" command from the menu bar removes the resource
from its class. This is the expected behavior? (This is on 6.02
Professional)

Best regards,
Sebastian

James Foster escribió:
> Andy,
>
> Thanks for the comments. I'll go back and see about refactoring things
> without using Shells that way. I suspected I stumbled into doing something
> non-standard and very much appreciate being pointed back to the well-worn
> path!
>
> James
>
>
> "Andy Bower" <bower@object-arts.com> wrote in message
> news:5966g3F2jtnc2U1@mid.individual.net...
>> James.
>>
>> Thanks for the bug reports.
>>
>>> 1. If a shell does not have a preferredExtent, you get a walkback
>>> when dropping it on another view as a reference view (Alt drop). The
>>> work-around is to add a preferredExtent (but it took a while to
>>> figure out).
>> Recorded as issue #2228. I guess we'd never really expected Shells to
>> be used as non-top level windows (at least not without some additional
>> work). If you are using them like this then beware of other tricky bugs
>> creeping out of the woodwork.
>>
>>> 2. When an existing shell is opened in the view
>>> composer, the hasBorder and hasCaption values are treated as true
>>> even if they are false. The work-around is to check and uncheck the
>>> #hasCaption value.
>> Recorded as #2228.
>>
>>> 3. I've got a situation where the #exit menu in
>>> in an outer shell's menu bar is being received by a reference view
>>> child causing the reference view to close leaving the parent view
>>> still very much present. I'm not able to generate a simple case for
>>> it, however, so if it's not a know problem then it can wait till I
>>> find out more.
>> It's not a known problem, but that is probably because (as I mentioned
>> above) we hadn't really intended that standard Shells be placed inside
>> other views (either as references or not). If you can come up with an
>> easily reproducible case then I'll record it for future investigation.
>>
>>> P.S. Will we see anyone from OA at Smalltalk Solutions?
>> No, I'm afraid not. With limited time and budget available for
>> attending transatlantic conferences we've been less keen to take part
>> since StS became part of LinuxWorld.
>>
>> --
>> Best regards,
>>
>> Andy Bower
>> Dolphin Support
>> www.object-arts.com
>
>

Hi,

there is also one thing that bothers me with VC. When I am designing
the view on my laptop which has resolution 1280x800 (that's a tad
wider than usual), that same view looks extremely bad whan run on the
machine with normal resolution.

Is there any work around that, aside from swithching to "standard"
resolution when I feel the need to work on Views?

thanks!

rush

On 2 May, 15:50, davorin.rusevl...@gmail.com wrote:

> there is also one thing that bothers me with VC. When I am designing
> the view on my laptop which has resolution 1280x800 (that's a tad
> wider than usual), that same view looks extremely bad whan run on the
> machine with normal resolution.

I don't understand what you mean by this? I have a widescreen laptop,
and design my views using the provided layout managers - and things
look fine on different screen resolutions in deployed apps?

Tim