Hi Gianny, IMHO, the commands you mention are not obsolete at all, they are not even deprecated (which will be reported during copiler processing). There are alternatives now with the activate command, but they need other special preparations befor they can replace the "old" command. Recently, I enriched the M4LUSEQREAD dll which still uses the $-registers for information transfer because this is the API with the samllest overhead.

From the ulibrary: RUN: "Note: The run command has been superceded by activate, which provides much more functionality and flexiblity than run. " PERFORM: "Note: The perform statement has been superceded by activate for C call-out. For more information, see Call-Out to 3GL and Call-Out Using activate." (And please check if you still need to use 3GL. Most of Icomp is available in the $ude function, I also see a lot of file handling and encryption where we now have statement for.) SPAWN: No specific reference found to it being obsolete of superseded. (Still better to do activate of an OS Command) (In customer applications I see a lot of platform specific spawns that can easily be replaced by Uniface statements (copy/delete/rename a file etc)) So I would say we have 3 categories: Obsolete: You run the risk this statement will disappear from a Uniface version in the near future. (I say risk and not fact since some statements have been obsolete for a very long time) Superceded: There is a better alternative and you run the risk the statement will become obsolete. "Stuff that isn't good practise but is not on the Osolete or Superceded list": I think the SQL statement also falls in this category. Maybe we should find a good name for the third category and clearly document statements and functions being in one of these categories? I certainly would support a wish for a compiler option that flags these things. Not by default, as you would get too many warnings when working on an old application. Could be a compiler switch, but you do not want to set it each time, so maybe in the Editor Setup too. Crazy idea: specify default compiler switches in the asn file? Just my personal thoughts, Theo

Hi Theo, The "more functionality and flexibility" you mention is simply not needed in a lot of circumstances, so why put additional work to the existing code if you do not need parameter passing? It's a fact that the activate requires a lot of overhad which is not necessary using the "old" commands. No need for sigantures, URR, ... just name the DLL in your ASN and use it. You mentioned MOST of the icomp, but not all the possibilities used by customers are under the $ude roof now. And please have in mind that even big customers had to wait years before some functionality was added to the uniface commands; while it took some days to prepare their own 3GL. Think about USEQREAD to process large sequential files very fast and with minimal memory consumtion, which has no similar option in uniface so far. Same goes for the spawn: why should I hardcode a command file with the restricted possibilities of uniface if spawning a simple *.bat or *.cmd file is enough to start the processing? There may be many good reasons to use activate for new development, but why force customers to change existing and working code without any gain? BTW you mention using SQL "isn't good practise": what alternative has a uniface coder as an example to clear a table with an accetable performace? Still one of the important bonuses of uniface is to have open 3GL and SQL options to extend the functionality of the 4GL code.

instead of increasing the amount of compiler checks and messages, I would recommend a feature for the IDF to inspect the uniface repository or a uniface export file. Similar to the search function we have in the assembly workbench already. But not a simple string search but a search for TOKENS (so the syntax is involved) like the run statement or the deprecated "item(" instead of "$item(" Much more flexibility for the users who can look for the info he needs. (*) This would be as well a start for a refactoring tool which allows to change the name of lets say entity "ABC" to "XYZ" in all ist different appearances including full qualified fields without renaming texts, fields, or procedures including "ABC" ------------------------------------------------------------------------------------------------------------ (*) since the beautiful days of migrating uniface 5 to 6, I have a AWK script which scans the TRX, PRO files for buzzwords to estimate migration efforts. It is a simple string search (so looking for p_bool will find any text which includes p_bool) and has some nice additional features like listing the previous and/or next line as well etc. Very fast, very easy. Recently, I amended it to analyse XML export files. This script is "context aware" so he points to the "trigger" where the code is: @@UFORM.DICT@@DWS_DEMO@@GENERAL *** Zeile: 63 Migr-Hinweis(e): b_pool1a string p_SELECTOR : IN boolean p_bool1 : OUT boolean p_bool2 : OUT *** Zeile: 68 Migr-Hinweis(e): b_pool1a case "A" p_bool1 = (1=2) p_bool2 = (1=2) *** Zeile: 72 Migr-Hinweis(e): b_pool1a elsecase p_bool1 = (1=1) p_bool2 = (1=1) *** Zeile: 82 Migr-Hinweis(e): b_pool1a string p_SELECTOR : IN boolean p_bool1 : OUT boolean p_bool2 : OUT *** Zeile: 84 Migr-Hinweis(e): b_pool3 boolean p_bool3 : OUT *** Zeile: 88 Migr-Hinweis(e): b_pool1a case "A" p_bool1 = (1=2) p_bool2 = (1=2) *** Zeile: 90 Migr-Hinweis(e): b_pool3 p_bool3 = (1=2) *** Zeile: 93 Migr-Hinweis(e): b_pool1a elsecase p_bool1 = (1=1) p_bool2 = (1=1) *** Zeile: 95 Migr-Hinweis(e): b_pool3 p_bool3 = (1=1) @@UFORM.DICT@@DWS_DEMO_0@@GENERAL *** Zeile: 64 Migr-Hinweis(e): b_pool1a string p_SELECTOR : IN boolean p_bool1 : OUT boolean p_bool2 : OUT

A completely diffrent dolution to finding obsolete statements could be a relatively simple extention of the cross reference functionality. And let's not forget that Gianni asked for something that warns his developers as soon as they use an obsolete statement. So we could also think in the direction of giving these statements a different color in the Proc Editor...

Hi Theo, I think the coloring would be a good idea, if it is cutomisable by the enduser. Even freeware editors allow syntax specification files for "new languages" (like uniface), http://www.ultraedit.com/files/wf/Uniface%208.4.uew http://www.textpad.com/add-ons/files/syntax/uniface84.zip On your suggestion of an extension of the cross reference which requires new implementation from "the Lab": Well, once, there was a big discussion about the performance and database consumption of the cross reference which resulted in the recommandation to use a separate database for UCROSS and rum /cro only from time to time because the compile took soooo much longer.. Perhaps a total new tool to analyse "static code" may help like the one described in eclipse.dzone.com/articles/free-static-code-analysis. But for uniface we still have the big question: - check the sourcecode scattered in the repository (aka. export-file) for "well formed code" with a scope of the single trigger only - check the final code the compiler sees in context (aka: proc listing) after all inheritence from models and templates, the #includes, #fors #defines etc.

I use Sublime Text 2 for Uniface editing these days, as the built-in Uniface 9 trigger editor is just the most hopeless pile of junk imaginable. Having to copy/paste everything to edit it is painful but still less so than using the built-in code editor. Oh, how I long to be able to assign any 3rd-party trigger editor, but anyway... I've set up Sublime Text 2 syntax highlighting for Uniface 9 that includes, among other features, highlights for obsolete keywords. You can find it at https://gist.github.com/vinceswann/5547498 if you need it. I don't personally consider "run" to be obsolete either BTW - it's far easier than activate in 99% of situations and there's been no indication it will be dropped AFAIK.

Hi, just an way to avoid the copy/paste action: - dump the contents of the edit field (for components PROC.DUMMY0) to a file with a special extension - have a synchronous spawn of just the file (this will invoke the associated application: your editor with the file) save changes before exit - load the file back to the edit field. have a menu item "external editor" with the option code: lfiledump PROC.DUMMY0, "myeditor.ued" spawn "#myeditor.ued" ; so we get a synchronous editor invocation lfileload "myeditor.ued", PROC.DUMMY0 For exploration in the IDF, you can add a menu item which tells you $fieldname, $entname, etc. for the active field.

ulrich-merkel said Hi, just an way to avoid the copy/paste action: ...

Wow, thanks. That's incredibly useful and indeed much better than my old AutoIt copy/paste hack.

Good message for us , this commands are not obsolete !!!. We use perform 3gl functions for caling excel objects. Its fairly simple against using number of signatures to Excel objects. We use SQL for complex queries .. and so on.

vojta said Good message for us , this commands are not obsolete !!!.

Hi vojta, but will they be available to the paying customers for the next years as well? the discussion started with the blog: http://unifaceinfo.com/should-goto-become-a-deprecated-statement/ and sometimes CPWR has some strange way to present facts to the customer like the deprecation of file_load to favor fileload. Has cost some customers I know some energy to have an repository wide cleanup of their sourcecode colleced in 20+ years.