This is a typical statement:
selectdb (select) from "entname" u_where (arg1 = arg2) to dest
where arg1 is a field on entity "entname", and arg2 is a string, variable or field.
It is possible to reverse the selection criteria (arg2 = arg1) without causing any error or warning at compile time, but this will NOT produce the correct results at run time.
There are 2 changes that I would like to see:
arg1 is a field within "entname", then the compiler should verify this and reject any exceptions.arg1 is forced to be a field within "entname" then the warning message "field reference X is ambiguous, cannot be optimised" should not be displayed.A <read> trigger may contain the following:
read u_where (arg1 = arg2)
where arg1 is a field within the current entity, and arg2 is a string, variable or field.
It is possible to reverse the selection criteria (arg2 = arg1) without causing any error or warning at compile time, but this will NOT produce the correct results at run time.
There are 2 changes that I would like to see:
arg1 is a field within the current entity, then the compiler should verify this and reject any exceptions.arg1 is forced to be a field within the current entity then the warning message "field reference X is ambiguous, cannot be optimised" should not be displayed.There are certain triggers (eg: <REMOVE OCCURRENCE>, <ADD/INSERT OCCURRENCE>) which cause default processing to be performed even though they do not contain any code. Not only is this not consistent with the way that all other triggers operate, it is confusing if it becomes necessary to change what the trigger does as one must remember to put in the 'hidden' code with the amendments, and not just the amendments on their own. If other triggers are initially loaded with the default code then the same should be true for ALL triggers. This would also give us developers an idea of what exactly the default processing is, and make it easier to insert changes.
Therefore, if any trigger has default processing then it should be indicated by having the relevant code pre-loaded in that trigger when the object is created. As for existing environments which contain empty triggers it would be a relatively simple process to create an update function to trawl through an application model and replace all empty triggers with the default code.
If the user hits Alt+f4 to close the whole application there is no <APPLICATION QUIT> trigger as there is a <COMPONENT QUIT> trigger. Instead the event fires the <ASYNC INTERRUPT> trigger (either in the current component, or if this is empty, in the start-up shell). This is very inconvenient as many of my components already have code in the <ASYNC INTERRUPT> trigger to deal with messages (via postmessage), which means that each of these components would need additional code to deal with application-level processing as well as component-level processing.
There should be a separate <APPLICATION QUIT> trigger defined in the start-up shell to deal with this situation, and (as per my request in item 3) this should be pre-loaded with the default code. It should be fired after the <QUIT> triggers of any active components.
Logged as SPR #50238
When a function within IDF requires the name of a file it allows the user to either enter a name manually, or displays a standard filebox which allows the user to browse through the directory structure. However, a filename which is chosen via a filebox is always returned fully qualified (eg: c:\projects\data\fname.txt) whereas a name entered manually may not be. If the ASN file contains an entry that matches that filename (eg: *.TXT = TEXT/*.TXT) then this redirection is applied to the fully qualified filename, turning it from a valid name into an invalid one. This can cause hours of confusion as the function within IDF is given a perfectly valid file name, but it refuses to work because it is being redirected to a non-existent folder.
To avoid this confusion any redirection specified in the ASN file should NOT be applied to any fully qualified filename.
I like to have field labels defined in the message file with an id of the actual field name prefixed with "L_". This can cause a problem as file names can be up to 32 characters long, whereas message file id's are limited to 16 characters. Either I have to keep my field names short, or keep them unique within the first 14 characters.
If would be helpful if message file id's were extended from 16 to 32 characters.
In all operations except the <EXEC> trigger a return will leave the instance in the component pool whereas an exit will terminate the instance completely. However, if a return is used in the <EXEC> trigger it is ignored. This is left over from version 6 where the <EXEC> trigger was the only operation, and leaving a form by any means would always result in the form being terminated.
To be consistent with all the other operations available in version 7 a return in the <EXEC> trigger should leave that instance in the component pool, and not cause it to be terminated.
Logged as SPR #50237
With the introduction of component templates and the ability to inherit the contents of certain component-level triggers, there is now the need for an additional trigger to store local proc modules which need to be inherited. They cannot be held in the existing <LOCAL PROC MODULES> trigger as all inheritance is lost as soon as the 1st amendment is made to that trigger.
This is especially important in self-contained services which cannot call global procs. Copies of these procs have to be inserted into one of the available triggers, but as all the triggers which are redundant in self-contained services have been removed from the service editor this leaves a very limited selection.
Logged as SPR #50236
At present the only way to have a tool tip for a command button is to have the button contents filled from a glyph, and to have an entry in the message file with the same name as the glyph.
I would like to have the ability to have tool tips for any type of command button, not just glyphs. There should be an additional field in the command button properties in which the value for the tool tip could be defined, either as a hard-coded string, or as $text(id).
Logged as SPR #50235
At present the value for a command button can either be TEXT or IMAGE depending on the setting for DATA TYPE which is defined at compile time.
I have a requirement where the default values for command buttons are strings of text obtained from the message file, but the user wants the ability to change them to pictures which can be customised. I therefore need the ability to be able to switch between loading the button with either TEXT or an IMAGE, to be determined at run time.
Logged as SPR #50243
At present the contents of a field label is set at compile time, either as a literal string or from the message file by means of $text(...). There is no way to change a field label with proc code.
In order to help satisfy a growing user requirement for customisable labels I would like the ability to change the contents of field labels dynamically, possibly by using a command similar to one of the following:
$fieldlabel(fieldname) = $text(...) or $properties(fieldname) = (label=value)
Currently sets of common objects can be placed in SYSTEM_LIBRARY for use across different applications. However, certain global objects (messages, menus, panels, and glyphs) cannot be referenced from SYSTEM_LIBRARY, so have to be placed instead in the USYS library, which is used for all Uniface objects.
I am not keen on the idea of having to maintain my common objects in two libraries, and I'm especially not keen on making changes to the USYS library. I would therefore like to have the search path for messages, menus, panels, and glyphs amended so that it includes SYSTEM_LIBRARY (the last one before USYS).
In reports there is the ability to define headers and footers for each page. I would also like the facility to have a report header (printed before the first page) and a report footer (printed after the last page).
With version 6 of Uniface there was a button in the trigger editor that would produce a list of all the proc modules (entries) within a trigger. By selecting one you would be taken directly to the start of that module within the trigger.
I would like the same facility available within version 7. I know that this can be provided with 3rd-party software, but I really think it should be part of the standard product.
Currently there is no way, by using standard Uniface functions, to access data at the bit level. This would be useful, for example, when creating encryption algorithms. There are two routines that I am looking for: one that would take a string of bytes and convert it to a string of 0's and 1's (eight times the length, naturally), and another which would do the reverse. This would allow me to manipulate the bits in any fashion so that I could perform such things as encryption and decryption without having to resort to a 3GL routine.
Logged as SPR #50239
Currently if a form requires global objects such as field labels they are loaded when the form is activated using the current value of $variation. This means that $variation must be set to the correct value before the form is activated. This was OK in version 6 as this had to be done before the <EXEC> trigger was processed, but in version 7 there is now the INIT operation which precedes all other operations.
I have a general-purpose menu and security system which has its own MENU library, and from this I can run any number of applications each with their own separate libraries. At present my menu system has to set $variation to the correct value before activating a form otherwise its field labels and command buttons will contain the wrong values.
The retrieval of global objects should therefore be delayed until after the INIT operation in case it has code which changes the value of $variation.
I may have several different applications running under my standard menu and security system, and each of these uses its own library for messages and field labels, therefore I have to ensure that $variation is set to the correct value for each component. I do this by having the relevant code in the INIT operation of every component. When a form is first displayed all the field labels and messages are correct. If I activate a second non-modal form which uses a different library and then return to the first non-modal form any references to the message file are now directed to the wrong library.
Settings that are in effect when a form loses focus should be reinstated when that form regains focus. This applies to $variation and pulldown menu (when it is subject to a pulldown/load statement).
The default prompt sequence when moving forwards from field to field with the TAB key is correct as it includes inner entities. When reversing the sequence with SHIFT+TAB the prompt sequence jumps over any inner entities. I would like the reverse sequence to work properly without having to insert additional code.
I can change the title of a form window with $formtitle, and I would like a similar function (for example $appltitle) that will allow me to change the application title in the same way.
It would be useful to have a way of changing the title in an askmess dialog box.
Once an application has been deployed it is not possible to alter message and label text which is contained within the DOL file without going back to the source code within the IDF. Where access to the IDF is not possible it would be very useful to have a mechanism which would allow the customer to customise text entries at will. If it is not possible to modify the DOL file directly then a routine which can decompile an existing file into source code, allow modifications, then recompile into a new DOL file would be sufficient.
With the $entinfo function it is possible to produce a list of inner or outer entities, but only from a named entity. However, there is currently no way to produce a list of all the outer entities on a form, i.e. those which are not painted within other entities. I would like to have such a facility.
Logged as SPR #50234
Currently indirection is only allowed with global variables (@$$variable) or component variables (@$variable$) but not local variables (@variable). This omission should be corrected.
Currently the only way to detect that the user is about to update an occurrence is to insert code in the <START MOD> trigger of every field of that occurrence. This can be tiresome. It would be useful to have a version of this trigger at occurrence-level which would be fired immediately before the field trigger.
Currently there is only one trigger available when leaving an occurrence, but that is only fired if the occurrence has been modified. I would like to have a version of this trigger that is fired when leaving an occurrence regardless of its modification status.
Currently the release statement will release either all occurrences of all entities or all occurrences of a named entity. I would like to see the "/o" switch added so that I can release just the current occurrence of a named entity.
Logged as SPR #50242
As well as being able to change the FIELD_SYNTAX options at run time I would like the ability to set them as default values for widget properties in the .ini file. Thus for a custom widget called NOEDITBOX I would be able to set the property (field_syntax=ned,npr) (or perhaps ned=true;npr=true) instead of having to change the field's syntax manually each time.
Logged as SPR #50241
As well as being able to change the FIELD_VIDEO options at run time I would like the ability to set them as default values for widget properties in the .ini file. Thus I would be able to create custom widgets which would automatically have any of the following attributes: (blink=true; border=true; bright=true; inverse=true; underline=true; color=nn) instead of having to change the field's layout manually each time.
When data is loaded into a presentation layer component with XMLLOAD prior to it being presented to the user all the field modification flags are set even though no value has been modified, either by the user or via proc code, since the data was originally retrieved from the database in the business layer component. This means that all <validate key>, <validate field> and <validate occ.> triggers will be fired even though the user has not changed any values. This behaviour does not exist in a 2-tier client/server application, therefore is should not exist in a 3-tier client/server application. A solution would be to provide for an optional '/init' switch on the XMLLOAD command which would set all modification flags to OFF rather than ON for the loaded data.
In the 3-tier architecture where all data validation is performed in the business layer, any errors are transmitted back to the presentation layer by using the valerr attribute in the XML stream. This is called 'remote validation'. The valerr attribute is set on occurrences using $OCCPROPERTIES and for individual fields using $FIELDPROPERTIES. However, the $FIELDPROPERTIES function is not allowed in self-contained services, which implies that none of my business layer components can be used on a remote server. This is a severe limitation if I want to distribute the processing of my application across 3 layers of hardware.
Currently XML streams can contain a set of UNIFACE-generated attributes, such as id, crc, status and valerr, but if the user wishes to include any additional attributes these are limited by having their values fixed in the DTD (Document Type Definition). This is a severe limitation should I want to make use of the XSL Transformation process to generate my HTML documents as I often require user-defined attributes where the values are not known until run time (refer to Generating dynamic web pages using XSL and XML for examples). I would therefore like the ability to include attributes in my XML stream where the values are obtained when I perform the XMLSAVE command instead of being hard-coded in the DTD. I should be able to specify additional attributes for occurrences as well as fields.
Tony Marston
26th May, 2001
mailto:tony@tonymarston.net
mailto:TonyMarston@hotmail.com
http://www.tonymarston.net
| 1st Mar 2003 | Added items 29, 30 and 31. |
| 2nd Nov 2001 | Amended item 5 to link to another document. |
| 26th May 2001 | Added items 27 and 28. |
| 1st Feb 2001 | Added item 26. |