TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Re: Generic term for menu/toolbar/status-bar items
Subject:Re: Generic term for menu/toolbar/status-bar items From:TechComm Dood <techcommdood -at- gmail -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 10 Dec 2004 11:11:33 -0500
> The basic question is: What is a generic term for items that appear in a
> menu, toolbar, or status bar (including separators)?
The Microsoft Manual of Style for Technical Publications covers this
nicely, as does the documentation for the Windows Development Platform
SDK.
> The issue is what to call the abstract class that all these things inherit
> from. Neither I nor our UI designer could come up with a generic term that
> covers all of them. Microsoft's "official" UI guide has a section on "Menus,
> Controls, and Toolbars" --- in other words, they don't have a generic term,
> either.
That's because they are different. ;-)
> For now, we've settled on a solution that I'm not quite happy with, because
> it mixes levels a bit. The menus, toolbars, and status bars themselves are
> represented by classes called MenuManager, ToolbarManager and
> StatusLineManager. Each of these contains a list of items (Actions,
> Controls, and Separators). The parent class for these "managers" is called
> ActionManager.
>
> Consequently, we're calling the parent class for the items
> "ActionManagerItem", to indicate that it represents "things that an
> ActionManager manages". I don't like this solution because it uses the name
> of a specific class ("Action") in the name of a class that is more general.
I don't see anything really wrong with this.
> It's possible that this naming problem indicates a deeper flaw in the logic
> of the architecture. It's unlikely that I could convince the developer to
> change the architecture, but if someone has an argument, I'm interested in
> hearing it.
The logic of the architecture might be an issue, but it has nothing to
do with the class names used. Names and architecture are different
issues and need to be looked at individually for flaws and then
together for overall logical representation.
ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!
RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
