Hi and Thanks guys. I will check out the sample BT sent me, read the
suggested reading from Vic and whatever else I can find. I was actually
thinking more of the help menu a final user of a script would bring up to
set script properties. But, before I ask some uninformed question I will do
my reading on this menu and check out some of the apps and WE ObjectModel
Docs to see what I can find about Help Dialogs which a user might see. It is
good that this menu can set Script Properties but sounds like it is geared
twoard Scripters. Most end users should probilly not be expected to do much
more than download, install and either enable or disable a script.
In my LanguageConversion App I currently have a Dialog to select Translation
options and it is geared twoard Scripters. One thing I am thinking about is
having end users be able to select a language and then automatically
either modifying the script to use an existing language element or create a
new one without much, if any, user intervention. I like how some WebSites do
this. And, this thread has implications for implementing something like
that.
Well, thanks again and I've got my ears on as the old-timers use to say.
Rick USA
----- Original Message -----
From: "Vic Beckley" <[email protected]>
To: <[email protected]>
Sent: Sunday, May 22, 2011 10:18 AM
Subject: RE: a "best practices" question
Rick,
I forgot to say in my last message that the menu syntax is described in
the
App Developer's Reference: Designing Custom User Interfaces/Interface
Elements/menu.
Vic
-----Original Message-----
From: RicksPlace [mailto:[email protected]]
Sent: Sunday, May 22, 2011 6:09 AM
To: [email protected]
Subject: Re: a "best practices" question
I narrowed down the question a little...
Here is the xml I think you are talking about and a couple of questions:
BeginCopiedCode:
<wescriptui>
<options>
<languageorder>WE,OS,en-us</languageorder>
</options>
<language id="en-us">
<menu id="my_script_menu">NotePad2011<menuitem id="menu_help"
enabled="yes" shortcut="h">Help...</menuitem>
</menu>
<strings>
... Rest Removed for brevity
EndCopiedCode:
Are you talking about adding DropDown Options to this menu to allow a
final
End-User to Edit Script Options?
If a final user is working in say Sonar or VB.net, how would they view
this
menu to set options for the script or do they have to go into the
ScriptManager if this menu is displayed there.
Is it automatically added as the base menu of the Standard Help Dialog?
I have been really tied up with the LanguageConversion App so not dug into
any of this yet and, if covered in one of Chip's tutorials I must have
missed it.
A quick overview from a final-end user viewpoint on how to use this menu
and
set script options would help me get started.
As Chip mentioned, I would like to start reducing hot keys as much as
possible. With the hundred or so hot keys in WE, the hot keys in various
scripts and the ones defined in say Visual Studio there are already too
many
potential conflicts so getting away from using random hot-keys would be a
good thing.
Anyway, could you shed a little light on how a end-user would use this
menu
from their own machine and what you currently use it for.
I don't need too much detail but with a conceptual overview I could
research
the technicals if there is documentation available in the GW Reference
Manual on using this feature. If not perhaps I will create a short
Walk-Through if and when I use it.
Rick USA
----- Original Message -----
From: "RicksPlace" <[email protected]>
To: <[email protected]>
Sent: Sunday, May 22, 2011 5:16 AM
Subject: Re: a "best practices" question
Hi Guys: I don't even know what WE Objects you are talking about. I see
the Menu object in the xml and the help stuff in the auto-generated WE
code in NotePad2011 but don't really understand them yet. Is there any
write-up on using these features?
Is there some way I can plan a structured activity where I can experience
using them for learning and documentation?
Rick USA
----- Original Message -----
From: "BT" <[email protected]>
To: <[email protected]>
Sent: Saturday, May 21, 2011 9:20 PM
Subject: Re: a "best practices" question
Hi Chip,
Just getting started on this, I found myself going to the menu for
all
those settings. I just completed my first working menu at the point you
speak of.
I have the options dialog for that menu inside my main menu and that
allows me to go to options and clean up the screen; as you mentioned in
your
response to me.
I think the only problem as you hint at, is how many options and
such.
But having menu labels for each option and a pull down to each
individual
option is a nice and clean way.
Some times there is a lot of enabling or disabling, but those can all
be
done when designing by id names and passing them in since all stuff is
almost text oriented.
so far, as I have just experienced, I think that would be a good
idea.
At the moment I call up just the main menu with Options and Help for
a
choice.
My lack of experience thoughts at the moment; work in progress.
bruce
Sent: Saturday, May 21, 2011 6:13 PM
Subject: a "best practices" question
Hi all,
I'm hoping for everyone's opinion, but especially for some sort of
"official" position from GW on this design question:
When we started scripting we always put configuration options for our
apps
somewhere in their help dialogs.
then, the "script/app" menu came along, and we at least put a menu
choice
for "help" there, to keep users from having to go into the app manager
to
get to help.
Now, I find myself usually designing my app interfaces so that all
configuration options are controlled via the app menu entry (and it's
submenus), so I can leave the help dialog managed as a standard help
dialog
by the help dialog object.
This is a significant savings to me if I don't have to write two
configuration option interfaces (one for menus and one for dialogs);
especially since I can leave the help dialog as a standard dialog, and
not
write a dialog interface at all, and since I'm having to write a minimal
menu interface anyway.
What does everyone think of this practice as our new "paradigm"? That
is,
allowing users to get to all configuration options via the app menu for
the
app, and not writing a custom replacement for the standard help dialog
(which always seem "clunky" to me)? It seemed just as "clunky" if you
had
to design your app with a hotkey which served no purpose other than to
bring
up a configuration dialog.
I realize not all configuration can best be done with menu choices, but
I
see no reason why a menu choice can't bring up a dialog when needed.
I think it's good for our users if we all agree on some design goals, so
all
of our apps are consistent, and thus present less confusion for the
users,
and there's obviously less memorization needed as to how each app
handles
it. I think it's also good if we can minimize the use of hotkeys, and
the
need for going into the app manager.
What do people think?
Chip
