$ude("Compile"): using compile sub switches

Author: daniel.iseli@uniface.com (diseli)

Dear Uniface Community,

In Uniface version 9 it is possible (as you all hopefully know) to compile components from Proc using the (new) function $ude("compile"). But unfortunately it is (currently) not possible to specify some of the compiler command line sub switches (like for example /nodebug).

There is however a way to invoke the different compiler command line sub switches using the undocumented (and currently unsupported) function $ude("List2Object", "Settings"), which is executed before $ude("compile").

For example: ; Compile all components with /nodebug

$1 = $ude("List2Object", "Settings", "ExecuteOnly=1")
$1 = $ude("Compile", "Component", "")

It is also possible to specify multiple sub switches by passing the settings in a Uniface associative list.

For example ; Compile all components with /nodebug and generate Type 1 Proc Listing (/lis)

$1 = $ude("List2Object", "Settings", "ExecuteOnly=1< GOLD >;listinglevel=1")
$1 = $ude("Compile", "Component", "")

And here's the list of the different compiler command line sub switches and how they are set:

* Generate Info Messages (equal to using /inf /war):
=> "messagelevel=0" ; setting False
=> "messagelevel=1" ; setting True

* Generate Proc Listing (equal to using /lis{=2}):
=> "listinglevel=0" ; No Listing
=> "listinglevel=1" ; Type 1 Listing
=> "listinglevel=2" ; Type 2 Listing

* Do Not Compress Component (equal to using /noc):
=> "NoCompression=0" ; setting False
=> "NoCompression=1" ; setting True

* No debug (equal to using /nodebug):
=> "ExecuteOnly=0" ; setting False
=> "ExecuteOnly=1" ; setting True

/* Update January 7, 2011 - Begin */

* Compile objects modified after and/or before the date specified.  (equal to using /aft and/or /bef):
=> "After=DateTime" ; /aft
=> "Before=DateTime" ; /bef
*** DateTime equals to "yyyymmddhhnnss"

/* Update January 7, 2011 - End */

Please be aware that Uniface will "remember" the "compiler sub switch" settings. The settings can however be reset passing an empty string to the function $ude("List2Object", "Settings").

$1 = $ude("List2Object", "Settings", "")

Hope the provided information is useful.

Best regards,
Daniel

***
DISCLAIMER: PLEASE BE AWARE THAT THE PROVIDED INFORMATION IS SUPPLIED "AS IS". COMPUWARE DISCLAIMS ALL EXPRESS AND IMPLIED WARRANTIES, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. USER ASSUMES RESPONSIBILITY FOR ANY USE OF THE PROVIDED INFORMATION. COMPUWARE RESERVES THE RIGHT TO CHANGE OR REMOVE THE MENTIONED FUNCTIONALITY FROM A FUTURE VERSION OF UNIFACE WITHOUT ANY PREVIOUS NOTICE OR WARNING.

4 Comments

  1. Very useful Daniel Many thanks


    Author: tribalgroup (david.wraith@tribalgroup.com)
  2. Hi take in account ";" => is "Gold;" regards


    Author: fmoritz (francois.moritz@hewitt.com)
  3. I'm currently using the $ude to compile forms and look at the result CPTLST file output. I use the List2Object setting in $ude to set my environment correctly, but have recently noticed that the messagelevel setting appears to be the opposite to what the initial post in this thread states: * Generate Info Messages (equal to using /inf /war): => "messagelevel=0" ; setting False => "messagelevel=1" ; setting True These appear to be the actual values of messagelevel: Messagelevel=0 > info, warning, and error messages Messagelevel=1 > warning and error messages (no info) Messagelevel=2 > error messages (no info or warning)


    Author: Mark Wheeler (mark.wheeler@tribalgroup.com)
  4. It also appears that information message about unused component variables is only output to the message buffer and not the proc listing (e.g. List Proc or CPTLST file). For example: info: 1301 - Component variable "C_EXAMPLE" is not referenced in the component. This doesn't seem consistent with other behaviour around the proc listing functionality. Could someone confirm if the missing Component Variable information is missing from the proc listing and if so then I would presume this is a bug?


    Author: Mark Wheeler (mark.wheeler@tribalgroup.com)