Vic, ok, the in and out of the menu many times is a good point.
If you need a dialog, then I think as you say, we should at least put a menu choice for the configuration dialog here in the app menu and not in the help dialog. Chip -----Original Message----- From: Vic Beckley [mailto:[email protected]] Sent: Sunday, May 22, 2011 10:01 AM To: [email protected] Subject: RE: a "best practices" question Rick, This menu would show up on the Apps menu within the WE control panel itself. Look at most of the GW apps to see how they use the menu. As for doing the configuration from this menu, I think it is good to be able to do certain things here, but find it much more difficult if you have many configurable options. When you bring up a configuration dialog you can set all the options before exiting the dialog. If you had to do all this from the menu then you would be in and out of the menu many different times. For some of the options you would have to create a dialog anyway, such as browsing for a file to use to play a sound or the like. You might actually end up creating more dialogs with this approach depending on what your configuration options entailed. I think it is almost essential to add a menu item to bring up the configuration options here, though. Just my opinion. 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 >> >> >> >
