Below you'll find a brief overview of new functionality implemented in Axiell Designer 7.4, including links to more information. For some notes on compatibility issues see the Axiell Designer compatibility topic.
Any new Designer settings typically pertain to adlwin.exe-based Adlib applications, unless indicated otherwise. If a setting also pertains to applications run within an Axiell Collections environment, it will be noted explicitly. Any old or new settings which do not pertain to Axiell Collections, should have no negative effect on the operation of this software.

Contents

Access rights for data dictionary fields, based on record type

Record type access rights for enumeration values

Copying all label translations at once

Adding comments to screen and field conditions

Adding a custom data language

New Fields column in Index list view

New object list features

Adding comments to field definitions

A Simple search method for Axiell Collections

Standard field validation separated from field validation by adapl

Overridden fields in field lists displayed in ochre

Documentation functionality in Designer expanded

Looking for output formats with the Object searcher

Forcing a line break on brief display screens in Adlib

Format string also applicable to related and equivalent terms

More functionality in the Application tester

folderId=%priref% in wwwopac.ashx image server calls

 

Access rights for data dictionary fields, based on record type

The record type functionality introduced with Designer and Adlib 7.3 is the basis for new functionality in Designer 7.4 allowing you to set access rights per record type for a data dictionary field or for a selection of fields at once. This functionality has effect in both Adlib 7.4 and Axiell Collections 1.0. It is in fact a new, more robust way of limiting the use of fields than the older screen level conditional fields functionality provides, as they both allow you to hide a field based on the value in some other field. One important difference though, is that the new functionality relies on the need for and existence of a record type field which actually allows the user to register different record types in one and the same dataset. Another difference is that conditional fields are a very superficial way of hiding fields: if a database field appears on multiple screens, the field condition must be set on as many screens. The new record type based way of limiting the use of certain fields however, is as pervasive as other access rights on database level: once you set field access rights based on record type, the access rights will automatically apply to all entry fields on screens associated with the relevant data dictionary field, and even to any access points associated with the (indexed) data dictionary field.

Proceed as follows to set access rights:

Record type effects in the Search wizard

Once you've set record type access rights for fields in a database, the effects won't just be noticeable on screens (where certain fields will be hidden for certain record types), but from adlwin.exe 7.4.16152.2 the Search wizard will be affected too. If in Step 1 of the Search wizard you've selected a data source which database has a record type field, then in Step 2 and Step 3 an extra drop-down list will be present, containing all record types available to the user*. Now the list of access points in Step 2 will depend on which record type the user selects in the list. An access point will be hidden for a certain record type if the associated (indexed) field has record type access rights None for the relevant record type. The access points list will be adjusted every time you select a different record type in the drop-down list. This way the user only gets to see the access points which are relevant to the selected record type. The currently selected record type will also be remembered by Adlib, for next time the user opens this data source.
Another effect of setting a record type in Step 2 or Step 3 is that the searched records will actually be filtered on that record type, so you'll only find records of that particular record type.

* Every value in the list of any enumerative field can be assigned role access rights (the "old" type of access rights, so to say), to prevent users with a certain role to pick certain options from the list when editing a record. These access rights also affect the contents of the Record type drop-down list here in the Search wizard if for certain enumerative values None access rights have been set for the role of a user. In such case, restricted users may not get to see all values in the Record type drop-down list, simply because they don't have the access rights.

Further remarks:

Record type access rights for enumeration values

With the record type functionality allowing you to hide or show fields based on what type a particular record is, you may also like to able to rule the contents of drop-down lists, based on record type. For record type "A" you may want to offer the user a different subset of all the enumerative values specified for such a field then for record type "B".

From Designer 7.4 you can make this happen by specifying record type access rights per enumeration value. You can do this on the Record type access tab of the Enumeration properties editor which opens automatically once you click a Language value in the Enumeration values list on the Enumeration values properties tab of an enumerative field in the data dictionary. (You must have already set up a record type field for the current database, to make this work: for more information see the Record type field topic in the 7.3 release notes.)

On the Record type access tab, you may then add record types and their designated access rights, as you please. Preferably choose between None (to hide an enumerative value) and Full (to show an enumerative value). You can make different settings per enumeration value.

Per enumeration value you may set both Access rights based on user roles as well as Record type access rights. Using only one of both or both at the same time, has the following consequences:

This functionality has effect in both Adlib 7.4 and Axiell Collections 1.0.

Copying all label translations at once

During application maintenance you often come across situations where you've added a new Adlib object somewhere, a method for example, which should get the same label translations as some other object, a screen field maybe. Previously that would have meant having to copy each translation of the desired label separately: quite a tedious task if you needed to copy many translations.
From 7.4 you can copy all translations of an object label or name to any other object suited for translated labels or names. Simply right-click somewhere inside the relevant Text box in the properties of an Adlib object (such as a screen, a screen field, a method, a data dictionary field, a data source, etc.), and select Copy texts in the pop-up menu. Then open the label or name properties of your target object, right-click inside the desired Text box and select Paste texts in the pop-up menu. If you paste the copied texts into a Text box which already contains texts, then the Text box will first be emptied before the copied values are pasted.

Adding comments to screen and field conditions

From 7.4, only the first line in the Screen conditions and Field conditions properties boxes are considered the conditional expression. After the first new line (press Enter behind the condition), all text is ignored by Adlib, so you could add comments here to explain the conditional expression.

Adding a custom data language

Designer 7.4 allows you to add a single* custom data language to the Windows system on which you run Designer. All software on this system, including all Adlib and Axiell applications running on it, will then be able to handle this new language. In multilingual Adlib applications and Axiell Collections you may need a custom data language if you need to register some data in that language while the relevant language doesn't have a standard language code.

Proceed as follows:

 

* The custom language will be registered in the Windows registry and Microsoft has limited this customization to the possibility of adding only a single custom language. If you need to register data in more than one language that doesn't appear in the standard codes list, you may consider creating a single dummy language name and code which represent all those non-standardized language codes: then at least you won't have to use an incorrect data language.

Removing your custom data language

If you haven't saved any record data in your custom data language yet, you can remove it safely too.

New Fields column in Index list view

In the Index list view, which appears in the right window pane of the Application browser when you select the Indexes list header underneath a database definition in the tree view in the left window pane, a new Fields column has been added to show all fields (field names and tags) indexed in that particular index. Although most indexes index just a single field, some index multiple fields, so the new column helps tracking down such indexes.

Note: if the Fields column initially appears to narrow to show all its contents, simply drag the right border of the Fields column header to the right to widen that column.

New object list features

The Field list grid view (which becomes visible once you click the Fields list header in the tree view of a database definition in the Application browser), the Index list grid view, the Method list, the Dataset list, the Internal link list, the Feedback database list, the Output job list, the Friendly database list, the Export job list, the User list and the Screen list have been revamped, offering a lot of new features. Since the new features are the same for all grid views, we'll illustrate them by the Field list grid view only.

Finally, note the following:

Adding comments to field definitions

The properties of field definitions now include an extra tab called Developer notes. It allows application managers to add comments to individual field definitions. Since the field name itself may not always explain its use or the reason why it was added, such comments help to document your changes.

Any added developer notes will also be included in the database structure documentation which Designer can automatically generate for you.

Warning: adding developer notes does break compatibility with older versions of Designer and Adlib for Windows (adlwin.exe) versions older than 7.4.17047.1.

A Simple search method for Axiell Collections

Above the context toolbar icons above the result set view in Axiell Collections, you have the option to quickly execute a new search by selecting a field from the drop-down list of all indexed fields in this database, after which you simply enter you partial of whole search key (no truncation needed) in the Enter search key box and click the magnifying glass.

Besides the full list of indexed fields, you can now add a simple-search option which can search multiple indexed fields at once. In the screenshot above it's called <Search> but you can name it differently if you want.

You must set it up per desired data source in your (.pbk) application definition in the Designer Application browser, as follows:

Standard field validation separated from field validation by adapl

In the Validation property of a screen field you've always been able to set whether the field was mandatory, mandatory in group, had to be "complete" or whether an adapl had to be run before or after entering this field. Two new checkboxes, Run before field adapl and Run after field adapl, now expand your field validation options by allowing you to set up a field to be both mandatory (or must be complete) AND be validated by an adapl. The advantage of being able to combine these two types of field validation is if you really need to use an adapl to validate data entry while the field must be mandatory too, then from now on you no longer need to write before-storage adapl code to check whether the field has been filled in at all (and cancel saving the record): the normal Field is mandatory setting (or Field must be complete or Field is mandatory in group settings) will take care of that type of validation.

Of course you won't have to change the properties of any existing screen fields nor will you have to rewrite any adapls, if you have a functioning application, but for new screen fields or existing screens fields that you'd like to turn into mandatory, adapl validated fields the new options will come in handy. For example, suppose you have an objects database in which object numbers are mandatory but do not need to be unique, while the user must get a warning each time he or she enters an object number which already exists in the database. This requires after-field validation by adapl (for which you'll have to write the code), but it also requires you to set the field to be mandatory.

Validation of the Mandatory requirement always takes place first. If it fails (because the field is still empty), the user will be warned if appropriate and the adapl won't be executed. If it succeeds, the adapl runs.

The Validation drop-down list still contains the old Run adapl before entering this field and Run adapl after leaving this field options for backwards compatibility. You'll never have to set both the adapl Validation property and the comparable adapl checkbox: unless you're willing to rewrite the relevant adapl, just leave the Validation property as is if existing fields have been set to run an adapl, and do not mark the new checkboxes. Only for new fields, preferably use the checkboxes for adapl validation and set the Validation property to any of the other (non-adapl) options.

This functionality applies to both Adlib for Windows and Axiell Collections. (As long as you do not mark one of the checkboxes, any other changes to the screen or its properties won't break backwards compatibility, so you'll still be able to open the screen in older versions of Adlib or Designer.)

Overridden fields in field lists displayed in ochre

In the database tree view underneath Fields and in the database Field list view in the Application browser of Axiell Designer, fields of which the properties are overridden in at least one dataset are now marked with a different colour (call it yellow, ochre, olive or gold) so you'll recognize them at once and know that you should first look up the relevant field definition underneath the relevant dataset since its properties have priority over the field properties on database level. (The possibility to override fields was in introduced in Designer 7.3.)

Documentation functionality in Designer expanded

At folder level in the Application browser's tree view, the Create rights documentation option is now available. It harvests all roles/rights information for all files in the selected folder, that have actually been assigned access rights for some object. So users and their roles won't be listed here and roles (both application roles and user roles) will only show up in the documentation if they have been used to apply access rights to a data source, a method or other Adlib object in that folder. Right-click an Adlib folder (data, xplus, library or museum for example) and choose Create rights documentation in the pop-up menu.

The resulting documentation lists only objects for which access rights have been specified explicitly and sorts these per role.

Like other documentation created by Designer, you can save and/or print the generated file.

An improvement to the "normal" documentation generated by Designer is the addition of the database (.inf) name, any dataset and path to the database with which data sources in an application definition (.pbk) are associated. For example, right-click your application definition (this might be called something like Adlib Xplus 4.5, Adlib Library 4.2, etc.) directly underneath an Adlib application folder and choose Create documentation in the pop-up menu. Per data source in the application you'll now see the extra information.

Looking for output formats with the Object searcher

From 7.4 you can also search your Adlib objects for the file names of output formats (print adapls, Word templates and XSLT stylesheets). Open the Object searcher from the main Designer window (Tools > Object searcher), set the Object category drop-down list to Output format and behind it enter the file name you are looking for, with or without extension. Remember to mark the Search substrings checkbox (because the file name might be part of a path), the Ignore case checkbox and possibly the Include subfolders checkbox. Underneath File specification, only select Applications (the other objects do not have output formats).

Forcing a line break on brief display screens in Adlib

For brief display screens in Adlib there's a new option to force a line break between the displayed fields, using <br> as the text for an in-line label on the screen in design mode. You can implement a line break if you have at least two system fields specified on the relevant brief display screen and if the screen lists the fields to be displayed on the screen itself (as can be seen below) or if the fields to be displayed are listed on the List fields tab of the screen properties dialog. Since the latter option isn't used much any more, we'll show the set up for the first case.

First realize that a brief display screen always has one or more system fields (*A, *B, *C, *D and *E). These system fields function as sort of a place-holder for the actual field data while the number of system fields you place on the screen indicates how many lines Adlib will reserve for the data of each record listed in the brief display of a search result. So if you only have system field *A, only one line of text can be displayed per record, while *A and *B reserves two lines of text. If your brief display screen only contains *A, the displayed line of data in the search result can get as long as the Adlib window is wide: if you were to narrow that window, you would see that a long line of data would just be cut off when it no longer fits the width of the window. If you often work with narrow Adlib windows, adding the *B system field would already be beneficial: a long line of text would then be word-wrapped to continue on the second reserved line. In other cases though, where the Adlib window is wide enough and you don't need word-wrapping but you would like to spread the displayed fields per record over different lines, simply because you think it would  improve readability and layout of the screen, then from Designer and Adlib 7.4 you can force such a line break if the screen has at least two system fields to display the extra line(s).

Format string also applicable to related and equivalent terms

The Hierarchy browser in Adlib displays all narrower and broader terms of the current term and you can expand the hierarchy by displaying related and/or equivalent terms as well. In the internal link definition for these types of relations you can set a Format string to specify which fields must be displayed in the tree structure, but previously this format string was only used for internal links of type 1 (broader and narrower). From 7.4 though, format strings set for internal links of type 2 (related) and type 3 (equivalent) are used in the Hierarchy browser as well.

More functionality in the Application tester

Axiell Designer has a special tool with which you can check your application for certain common errors. Start this Application tester tool from the main Designer window by selecting Tools > Application tester in the menu.

For all data fields (not system fields) on screens used in all data sources in an Adlib application, the Application tester now also checks if the tag associated with the screen field has been defined in the data dictionary of the database associated with the data source. In the past these undefined field tags have never been a problem, but in Axiell Collections a more strict validation of data structures has been implemented so that all tags used on screens need to have been fully defined in the data dictionary, providing the correct data type and such. So next time you use the Application tester on your applications, test results like the following might show up too, indicating that your application is not quite ready to be exposed via Axiell Collections:

So if you plan on deploying Axiell Collections or if you simply like your databases' data dictionaries to be in perfect order, you should take action on these test results. The solution is to create an actual field definition for all such reported fields in the relevant databases. From the label for the screen field, the screen(s) it is located on and the database the field should be specified in, you can usually easily deduce the basic properties for the new field definitions. However, if you think the Data type of a field should be anything other than Text, you have to be sure that all data that was entered into this field previously is indeed of the other type! Undefined tags on screens may contain any value because they are implicitly considered text fields, but once you specify the field in a database as an integer, numeric or date field, etc., then all existing data in that field should be of that type as well, otherwise you may inadvertently create data corruption. So if you are not sure about the type of your existing data in these fields, just assign them the data type Text, set the Maximum length to 0 (or otherwise sufficiently large) and let them be Repeatable. After you've defined all these fields in their respective databases, you're already done! There's no need for any data conversion or reindexing.

With regards to Adlib SQL databases the Application tester now also checks the following:

Other new checks:

folderId=%priref% in wwwopac.ashx image server calls

The folderId parameter is a new parameter for the wwwopac.ashx getcontent command, which can be used to reference a specific folder from which the images must be retrieved. This comes in handy in enterprise solutions in which each branch of your organisation uses its own images folder, while still addressing one and the same image server configuration in the adlibweb.xml file. Using this configuration (more specifically, the new <folderMappingList> setting in that file), the api indirectly identifies an images folder by means of the record number of the reproduction record linking to the image file. This is possible because the record number falls within a record number range which, together with the relevant image folder path, has been specified in this configuration.
For a wwwopac.ashx call that you may wish to set up in the Retrieval path and/or Thumbnail retrieval path properties of an image field, here in Designer, you can only make sensible use of the folderId parameter if the record number of the currently processed record in Adlib can be inserted in that call automatically. To do this, you can use the %priref% system variable: in this context, %priref% will always contain the current record number, so that the api can deduce from which images folder the requested image (specified with value=%data%) must be retrieved.

Example:

https://ourserver.com/wwwopacx/wwwopac.ashx?command=getcontent&server=images&folderId=%priref%&value=%data%&width=%width%&height=%height%