Hi, Some ADDITIONALS are contextual to the current edited object while others generally work on the UDE repository. Few examples: DOCUMENTATION: estracting values from the repository to generate documentation based on internal standard & guidelines or specs defined from customer: - in many cases texts extracted are coming from a properly structured COMMENT field in each repo entity - in other cases reports has just a specific format to accomplish a specific request from customer DEVELOPMENT EXTENSIONS: they can try to manage: - UDE complexity (signatures, large repositories) - UDE time consuming functionality (compilation / export / SQL script generation) - UDE missing in action (glyph browsing) INTEGRATION: integration with external or customized tools: - pre-development (analysis, project creation) - while developing (javascript or CSS linting/validation, version control) - post-development (test phases support, deployment) Hope it helps. Gianni

Hi Theo, The second (“editing components”) and third (“defining fields for a modelled entity”) menu option groups are context sensitive, the other menu items are not context sensitive. When editing components (in form UUEXTN23) we use $form$ to know the current component code – some of these sub-menu options loop through the UXFIELD records retrieved in the Uniface component editor and may even update them, others run a separate component to re-retrieve the relevant records. When defining fields for a modelled entity (in form UUFLDC20) we create 20 additional UCFIELD records in the current component - these are then stored by the UUFLDC20 form, when the user clicks the "Ok" button. Regards, Mark

Hi Mark, Thank you very much for your input, this helps a lot. Can please add which options require context? And how you apply changes: directly to fields in the open form, or re-retrieve the object from the repository in your tool and then make changes and store? Regards, Theo Neeskens

Here at Tribal we have added the following items to the Additional Menu bar:

Mark

Aside from some minor functionalities, we use it for version control, to see changes in the component in time, ability to compare current version with any older version (or even 2 older versions) - so we can highlight the changes (who, when and why did it). The same applies to components, global objects (procedures), model (entities and fields). Another feature is co detect concurrent developers working on the same component (and to show who the hell is modifying it while I need to modify it :)). Minor features include showing putmess in better window (not only black text on gray background, but some highlighting for warnings/errors) and opening the listing of the current component (form/service) in external viewer/editor.

I just want to add one more thing, the link to version control. It also links the checkin number from TFS to our internal task system. From the integrated screen we can do checkout / in, view history, compare, open related tasks.

Theo Neeskens said Hi Iain, Ingo, Stijn, Can you please add which items of your lists use context, and what context (current component, current entity etc) ?

And finally here is the menu option code for individual fine granular backups which gives you the secure feeling that you can always go back to the last modification without defects (implemented in 6901): variables string lvName, lvType, lvPath, lvObject, lvUser string lvItem, lvOptions, lvPath2, lvName2, lvNameType, lvTimestamp endvariables lvType = $componentname[3:4] lvUser = $user lvTimestamp = $concat($datim,"") lvTimestamp = lvtimestamp[3:12] lvPath = ".\\private_backup-%%lvUser%%%\\" lvPath2 = ".\\private_backup-%%lvUser%%%\\" if ($fileexists(".\\private_backup") != 2) dircreate ".\\private_backup" endif if ($fileexists(".\\private_backup-%%lvUser%%%") != 2) dircreate ".\\private_backup-%%lvUser%%%" endif if (lvType = "WKSP") ; call from main screen message/info "Select an Editor to export this item" return(-1) endif selectcase lvType case "EXTN" ; Components lvName = "cpt-%%ULABEL.UFORM%%%.xml" lvNameType = "cpt" lvName2 = ULABEL.UFORM lvObject = "component" lvItem = ULABEL.UFORM case "CONC" ; Business Object Models lvName = "mod-%%U_VLAB.UCSCH%%%.xml" lvNameType = "mod" lvName2 = U_VLAB.UCSCH lvObject = "model" lvItem = U_VLAB.UCSCH case "APPL" ; Startup Shells lvName = "aps-%%ULABEL.UAPPL%%%.xml" lvNameType = "aps" lvName2 = ULABEL.UAPPL lvObject = "application" lvItem = ULABEL.UAPPL case "EINT" ; Entity Templates lvName = "ten-%%U_MLAB.UGGIF%%%.xml" lvNameType = "ten" lvName2 = U_MLAB.UGGIF lvObject = "entity·;interface" lvItem = U_MLAB.UGGIF case "INTT" ; Field Interface Templates lvName = "tfi-%%U_MLAB.UGFIF%%%.xml" lvNameType = "tfi" lvName2 = U_MLAB.UGFIF lvObject = "field·;interface" lvItem = U_MLAB.UGFIF case "SYNT" ; Field Syntax Templates lvName = "tfs-%%U_MLAB.UGFSYN%%%.xml" lvNameType = "tfs" lvName2 = U_MLAB.UGFSYN lvObject = "field·;syntax" lvItem = U_MLAB.UGFSYN case "LAYT" ; Field Layout Templates lvName = "tfl-%%U_MLAB.UGFLAY%%%.xml" lvNameType = "tfi" lvName2 = U_MLAB.UGFLAY lvObject = "field·;layout" lvItem = U_MLAB.UGFLAY case "FLDT" ; Field Templates lvName = "tfx-%%TEMPLATENAME.UTPLFLD%%%.xml" lvNameType = "tfx" lvName2 = TEMPLATENAME.UTPLFIELD lvObject = "field·;template" lvItem = TEMPLATENAME.UTPLFIELD case "LIBR" ; Libraries lvName = "lib-%%ULIBRARY.ULIBR%%%.xml" lvNameType = "lib" lvName2 = ULIBRARY.ULIBR lvObject = "library" lvItem = ULIBRARY.ULIBR case "CPRC" ; Central Proc lvName = "prc-%%ULABEL.USC_PRC%%%@%%UVAR.USC_PRC%%%.xml" lvNameType = "prc" lvName2 = "%%UVAR.USC_PRC%%%@%%ULABEL.USC_PRC%%%" lvOptions = "library=%%UVAR.USC_PRC%%%" lvObject = "library·;proc" lvItem = ULABEL.USC_PRC case "INCL" ; Include Proc lvName = "inc-%%ULABEL.USC_INC%%%@%%UVAR.USC_INC%%%.xml" lvNameType = "inc" lvName2 = "%%UVAR.USC_INC%%%@%%ULABEL.USC_INC%%%" lvOptions = "library=%%UVAR.USC_INC%%%" lvObject = "library·;include" lvItem = ULABEL.USC_INC case "DEVC" ; Device Tables lvName = "dev-%%ULABEL.USC_DEV%%%@%%UVAR.USC_DEV%%%.xml" lvNameType = "dev" lvName2 = "%%UVAR.USC_DEV%%%@%%ULABEL.USC_DEV%%%" lvOptions = "library=%%UVAR.USC_DEV%%%" lvObject = "library·;device_table" lvItem = ULABEL.USC_DEV case "TRAN" ; Keyboard Tables lvName = "trn-%%ULABEL.USC_TRN%%%@%%UVAR.USC_TRN%%%.xml" lvNameType = "trn" lvName2 = "%%UVAR.USC_TRN%%%@%%ULABEL.USC_TRN%%%" lvOptions = "library=%%UVAR.USC_TRN%%%" lvObject = "library·;translation_table" lvItem = ULABEL.USC_TRN case "PANL" ; Panels lvName = "pan-%%ULABEL%%%@%%UVAR%%%.xml" lvNameType = "pan" lvName2 = "%%UVAR%%%@%%ULABEL%%%" lvOptions = "library=%%UVAR%%%" lvObject = "library·;panel" lvItem = ULABEL case "MESG" ; Messages lvName = "msg-%%ULABEL.USC_MSG%%%@%%UVAR.USC_MSG%%%@%%ULAN.USC_MSG%%%.xml" lvNameType = "msg" lvName2 = "%%UVAR.USC_MSG%%%@%%ULABEL.USC_MSG%%%@%%ULAN.USC_MSG%%%" lvOptions = "library=%%UVAR.USC_MSG%%%·;language=%%ULAN.USC_MSG%%%" lvObject = "library·;message" lvItem = ULABEL.USC_MSG case "TEXT" ; Text - not sure how this differs from Messages lvName = "txt-%%ULABEL%%%@%%UVAR%%@%%ULAN%%%.xml" lvNameType = "txt" lvName2 = "%%UVAR.USC_MSG%%%@%%ULABEL.USC_MSG%%%@%%ULAN.USC_MSG%%%" lvOptions = "library=%%UVAR%%%·;language=%%ULAN%%%" lvObject = "library·;message" lvItem = ULABEL case "HELP" ; Text - not sure how this differs from Messages lvName = "hlp-%%ULABEL.USC_HLP%%%@%%UVAR.USC_HLP%%%@%%ULAN.USC_HLP%%%.xml" lvNameType = "hlp" lvName2 = "%%UVAR.USC_HLP%%%@%%ULABEL.USC_HLP%%%@%%ULAN.USC_HLP%%%" lvOptions = "library=%%UVAR.USC_HLP%%%·;language=%%ULAN.USC_HLP%%%" lvObject = "library·;message" lvItem = ULABEL.USC_HLP case "GLYP" ; Glyphs lvName = "gly-%%UCLABEL.UGLYPH%%%@%%UCVAR.UGLYPH%%%@%%UCTYPE.UGLYPH%%%.xml" lvNameType = "gly" lvName2 = "%%UCVAR.UGLYPH%%%@%%UCLABEL.UGLYPH%%%@%%UCTYPE.UGLYPH%%%" lvOptions = "library=%%UCVAR.UGLYPH%%%" lvObject = "library·;glyph" lvItem = UCLABEL.UGLYPH case "MENU" ; Menus lvName = "men-%%UMENU.USMENU%%%@%%UVAR.USMENU%%%@%%ULAN.USMENU%%%.xml" lvNameType = "men" lvName2 = "%%UVAR.USMENU%%%@%%UMENU.USMENU%%%@%%ULAN.USMENU%%%" lvOptions = "library=%%UVAR.USMENU%%%·;language=%%ULAN.USMENU%%%" lvObject = "library·;menu" lvItem = UMENU.USMENU case "CREG" ; Variables lvName = "gva-%%U_NAME.UGREGS%%%@%%U_FORMLIB.UGREGS%%%.xml" lvNameType = "gva" lvName2 = "%%U_FORMLIB.UGREGS%%%@%%U_NAME.UGREGS%%%" lvOptions = "library=%%U_FORMLIB.UGREGS%%%" lvObject = "library·;variables" lvItem = U_NAME.UGREGS case "GCNT" ; Constants lvName = "gco-%%ULABEL.UCNST%%%@%%UVAR.UCNST%%%.xml" lvNameType = "gco" lvName2 = "%%UVAR.UCNST%%%@%%ULABEL.UCNST%%%" lvOptions = "library=%%UVAR.UCNST%%%" lvObject = "library·;constants" lvItem = ULABEL.UCNST case "GFMT" ; Format lvName = "fmt-%%ULABEL.UFORMAT%%%@%%UVAR.UFORMAT%%%@%%ULAN.UFORMAT%%%.xml" lvNameType = "fmt" lvName2 = "%%UVAR.UFORMAT%%%@%%ULABEL.UFORMAT%%%@%%ULAN.UFORMAT%%%" lvOptions = "library=%%UVAR.UFORMAT%%%·;language=%%ULAN.UFORMAT%%%" lvObject = "library·;format" lvItem = ULABEL.UFORMAT endselectcase if (lvName != "") lvName = "%%lvPath2%%%%%lvName2%%%.%%lvNameType%%%.%%lvTimestamp%%%" $1 = $ude("export", lvObject, lvItem, "xml:%%lvName%%%",lvOptions) message "%%lvObject%%%: %%lvItem%%% exported to %%lvName%%%" endif

Theo Neeskens said Hi Iain, Ingo, Stijn, Can you please add which items of your lists use context, and what context (current component, current entity etc) ?

Even in the early 2000s, commercial editors provide a lot of features like templates, textblocks, etc. After associating ".eec" with the editor of your choice the unifacecode from the IDF is transfered to the external editor and brought back to the component fields holding the active code    by this 9601 implementation : Trigger <OPTN> of item: 01 from Menu: DITO_X2EDITOR2X selectcase ($componentname) case "UUEXTN23" ; Components call code2editor2code(PROC.DUMMY0) case "UUCPRC20" ; Global Procs call code2editor2code(UTEXT.USC_PRC9) case "UUINCL20" ; Include Procs call code2editor2code(UTEXT.USC_INC9) case "UUCONC22" ; Model triggers call code2editor2code(DUMMYSS.DUMMY1) case "UUMENU22" ; Menu triggers call code2editor2code(DUMMYSS.DUMMY1) endselectcase entry code2editor2code params string p_codefield : INOUT endparams variables string v_exteditorfilename, v_exteditortext_old , v_exteditortext_new endvariables v_exteditorfilename = "code2editor2code.eec" v_exteditortext_old = p_codefield filedump v_exteditortext_old, v_exteditorfilename spawn $concat("#",v_exteditorfilename) fileload v_exteditorfilename, v_exteditortext_new if (v_exteditortext_new = v_exteditortext_old) message/info "no changes found" else askmess/info "accept change in the proc code?" if ($status = 1) p_codefield = v_exteditortext_new endif endif end ; code2editor2code P.S. Up to U8, there was UNIASSIST, an external tool to link code from IDF with an external editor by pushing the mouse wheel.

Theo Neeskens said Can you please add which items of your lists use context, and what context (current component, current entity etc) ?

Hi Theo, a lot of people use this "active object" PK to support individual exports of this object as some kind of backup copy. So it's more or less any part of the repository down to the last Include Proc or individual Entity (using the CIF option). AFAIK, most of the sourcecode management tools (including the UNICON provided by CPWR?) make use of this context as well. Greetings from Frankfurt (at 0°), Uli

Hi all My case is similar

All of them are, let's say, global. I know someone was working in beautifying javascript and applying Lint or similar (within the current trigger at the current component). I think a simple way to add this kind of "code" tools could be very interesting. From time to time I would like to have a way to collect some code metric to compare the before and the after (it is easy to imagine the situation: me in front of an entry with hundreds of lines and dozens of loops). I know it is a bigger issue, related with this subject but not only.   Regards

Okay, 

  We would find it time consuming to work without 2, close to impossible to work without 3 and mildly annoying not to have 4 & 5. 

Stijn Courtheyn said

Version management	Link with TFS listing and xml export for component, entities, menus, include procs, global vars, messages, startup shells, templates, device tables) Uses context of current open component + .Net dll (com exposed) for link with TFS
Search for entity	Where is an entity painted / used (form / service / report / dsp) It also allows to quickly compile the forms/services/reports/dsp when we do a model change
Global actions	To quickly do some stuff
Add operation	Create a new operation in the open component based on a template Uses context of current open component
Add remark template	Add remark template to an operation (some base documentation about the operation) Uses context of current open component
Standard exec for forms	Add default params section to and operation / trigger Uses context of current open component
Standard exec for services	Add default params section to and operation / trigger Uses context of current open component
Extract operation comments	Extract all the structured documentation of operation's in the components Will store the data in table in the repo database, we added a new entity in the DICT model On this table Full Text Indexing is actif and an external webpage reads on this table.
Add operation COMP_INFO	Quickly create the operation COMP_INFO Uses context of current open component

  

Hi Iain, Ingo, Stijn, Can you please add which items of your lists use context, and what context (current component, current entity etc) ? It would help us in designing something that is fit for purpose. Regards, Theo Neeskens

Here is what we are using the Additional Menu for. 1. Setup of new components and packages 2. Search tools (entity search/compile, repository search/compile) 3. Setup RI between tables 4. Modify Create/Alter table scripts to include additional drop/modify/insert triggers/procedures 5. Check out of our Version Control software (scripts to do additional validation to ensure we don't overwrite code).

Adrian, thank you for touching this topic. We are using the Additional Menu to call all kinds of Utilities that we programmed to enhance the IDF and query/update the model as we like it. Also we call c/c++ routines to get more information about the form we are in, cursor position and so forth. These information are needed for utility programs like post-compiler. @Admins: I retract the rest of my statement myself, thank you. Regards, Daniel

As presented in german usergroup meetings 2006 and 2008, the ADDITIONAL menu is THE key to improve productivity in the IDF. Invoking ADDITIONAL in the different IDF editors (UUCONC22 for example), gives me the PK for the active object in the editor. This PK I can use for any additional task like starting a test, start 2-phase compiles or pass proccode to an external editor of my choice with much more comfort and support than I have in the IDF. There is (in contrast to U10) no need to remember and retype the PK of the active object in some other form. Edited to remove non relevant content. 

I've seen the additional being used to have a really tight integration to Team Foundation Server - incl searching objects for (and suggesting to remove debug statements, adding version numbers directly into the description / defines trigger and a whole lot more.

We are calling a 'menu' component which then calls a lot of other components Components we are using from the menue are  (e.g.) * Compile all component for a list of entities * Search for Text in all components, tables, ... * Compare to objects (as in search) side by side * Compare objects across different environments (incl. different UnifAce versions) * Print table descriptions as HTML * Graphical dependence of table or components * Create our licences files * and so on ... To use our 'normal' environment out of IDF, before activating the menu, we do a whole 'init' of the background processes (instances) and after the activate we do a proper cleanup. From 'productive' (UNIFACE.EXE) environment, the path to IDF is deactivated to be sure that there are no 'calls' to IDF&Co Ingo