Directly accesing items in ViewComposer

This is a repost of an unanswered question.

As usual, I am sure there is a better way for doing this that I don't
know.
In case there is one, please tell me, if not, take it as a suggestion.
I am editing a View in the ViewComposer, and want to access and edit
some item I placed both on my toolbar and my status bar.  When I click
on the particular item I want to modify I get the toolbar (or status
bar for that matter) selected.  However, further clicks don't sharpen
the selection just as with other kind of components.
Thus, I must select the toolbar and use the tree, open the items
aspect, and then open the desired one.
Visual Object Finder doesn't help either.

Am I overlooking anything?

Best regards,
Daniel

Daniel,

>                    However, further clicks don't sharpen
> the selection just as with other kind of components.
[]
>
> Am I overlooking anything?

The reason that these objects (ToolbarButtons, StatusBarItems and
ListViewColumns) don't behave in the same way as the other views is that
they are not actually views at all.  If you find them in the image then
you will see that none of them are subclasses of View.  This is because
Dolphin has to follow the way that Windows implements them and each case
the view is the "container" (Toolbar, StatusBar and ListView) and it is
this which receives all the messages.

I would think that the way the ViewComposer works would make it very
difficult (I won't say impossible) to implement these objects in a way
that replicated the behaviour of "normal" views and, to be honest, I
don't think you would gain much anyway.

<aside>  Why is the Toolbar class name got a little b and StatusBar got
a big B - just to confuse? </aside>

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote in message
news:eX4Eb.2097$[hidden email]...
> ....
> <aside>  Why is the Toolbar class name got a little b and StatusBar got
> a big B - just to confuse? </aside>

It's because Microsoft refer to Toolbars using one word and Status Bars
using two, e.g. in the "Official Guidelines for User Interface Developers
and Designers":

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch08d.asp

Since it is "official" terminology we thought we'd better stick with it :-).

Regards

Blair

"Ian Bartholomew" <[hidden email]> wrote in message news:<eX4Eb.2097$[hidden email]>...
I see, I was just wondering if there could be a way for the
ViewComposer to intercept the mouse click on those and take appropiate
actions.


> I would think that the way the ViewComposer works would make it very
> difficult (I won't say impossible) to implement these objects in a way
> that replicated the behaviour of "normal" views

I don't know about the complexity, so I take your word on it.


> and, to be honest, I don't think you would gain much anyway.

On this one, I respectfully disagree.
Take this as an example:
I am composing a simple dialog with a toolbar containing several items
(more than 10).
I want to change the command one of those items triggers when
activated, so I must:
1. Click on the toolbar view
2. Scroll down the control tree until the 'items' entry appears
3. Click on the '+' to open the item's subtree
4. Scroll down again to find the specific item (with more than 10
items, the one is probably not visible)
5. One found the item open its subtree again with '+'
6. Then continue to modify the command

Otherwise, with my suggestion, only 1. and 6. would be needed.
Unless I am missing something obvious, it would be a time saver for
me.

Thanks Ian for your response.
Best regards,
Daniel

Daniel,

> I don't know about the complexity, so I take your word on it.

Well, I haven't actually _tried_ it you understand but, from the
occasions I have looked into how the VC works, I would think that it
could get messy.

> Otherwise, with my suggestion, only 1. and 6. would be needed.
> Unless I am missing something obvious, it would be a time saver for
> me.

Have you looked into creating separate toolBar resources and then using
these as reference views in your Shell.  This would go some way towards
shortening the steps needed to edit each button. There are a lot of
examples of this in the D5 image and, in some cases, it can be quite
useful to have toolBars as reusable views.

On a more general note I do agree that the VC can induce a bit too much
clicking of mouse buttons, the one that gets to me is setting up
FramingConstraints in sub views, but I can't really say I consider it
excessive - you obviously disagree.

One thing I have thought of doing in the past is rearranging the layout
of the VC.  I usually edit views in full screen mode and end up with a
lot of empty space at the right hand side of the screen but having to
scroll to see the bottom of the view I am editing.  Moving (optionally)
the hierarchy and PAI so they are arranged vertically on the right hand
side might solve both problems, allow more usable room for the view
being edited and a;so allowing more aspects to be visible at one time.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.