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 >> >> >> >
