Designer has just a single main kind of form. This form is called FieldView and, as its name suggests, its main task is to manage table fields. There is exactly one FieldView per Database, so everything a FieldView displays automatically belongs to a single Database. Naturally, you can open more than one FieldView concurrently if you want to work on more than one Database at the same time. You can open a FieldView in two ways. Either select the one you want from the dropdown menu opened by the FieldViews button BarDgnFieldViews, or double-click the corresponding Database in the Database Explorer form BarDgnDatabaseExplorer.




The FieldView form is remarkably simple. It is divided in two panes with a Splitter between them. The top pane is occupied by the Tables grid. The lower pane holds the Fields Grid.



Tables Grid


This grid lists all tables of the FieldView's Database. Most of its columns are fairly obvious, so let's quickly go over them:

ID is the table's ID number, unique index auto-assigned at the time of its creation.
Created/Modified are the creation and last modification dates.
Author is the user who created the table.
Name is the name of the table. This also ends up being used as the physical file name that holds the data table.
Caption/Comment have no special meaning and you can set them to whatever you find convenient/useful.
Save is simply a column full of the familiar Save buttons, albeit in a somewhat unusual place. In Designer, you can make modifications to multiple tables but postpone saving them to the actual physical tables until later. This can give you an opportunity to review your changes and perhaps make some corrections. Any tables that have not been saved will have their corresponding Save buttons enabled.


The above describes Designer's one possible behavior. The alternative is: Designer will save each table every time you make a modification to its field. This does save you the effort of clicking the Save button. There's a subtler benefit to this mode of operation though. In this mode, you can rename existing fields that are not already found on any InfoView forms. The downside is that table saving may be lengthy for a table with thousands of records, so you may prefer to "accumulate" all field modifications and save only once rather than patiently waiting after each and every field modification. Note that not all field editing results in changes to the physical table. You can specify which Designer's Table Saving Mode you prefer from the Designer's Settings dialog invoked using the Settings command BarDgnSettings. The remaining options this dialog offers are so self-explanatory, we won't bother with them.





The Wizards. In the top-right corner of the Tables grid you will find three buttons. They invoke Wizards that should assist you in creating the three types of objects the FieldView is "responsible" for:

DgnFieldViewWizardButtonNewTable New Table

DgnFieldViewWizardButtonNewField New Field

DgnFieldViewWizardButtonNewInfoView New InfoView


The Wizards are quite intuitive and self-explanatory, so we shall not explain them in detail. You can also invoke these Wizards from the File menu. It should be noted that the Wizards perform the exact same tasks that you can accomplish by simply inserting a new record into the corresponding grid directly in the FieldView form, as explained below.



You can create a new table by simply creating a new record in the Tables grid: with this grid focused, hit Insert on the keyboard, specify the table's Name (the only important value!) and you're done.
You can modify an existing table's Caption and Comment by editing the respective values.
You can also delete a table by deleting its record. As a safety measure, you cannot delete a table that has InfoView forms based on it (which would usually be the case). If you absolutely insist on deleting it, you have to delete the InfoViews first, and only then go after the table. You will obviously lose the table's structure and all its data, so be careful what you wish for.


This would be the end of our discussion of the Tables grid if it weren't for the little Plus buttons in the ID column. Yes, this is a two-level grid. The top level holds the list of tables that we have just examined, while the second level holds the InfoView forms of each table. We'll get to them in the next chapter, so let's pretend for now that they are not there.



Fields Grid


This grid lists all fields of all tables from the Database.




All fields are listed together so that you could easily find all fields by their data type (e.g., all Picture fields) or all fields that have some other feature in common. Whenever you find yourself working with a single table, you may want to reduce the clutter by simply either grouping this grid by Table or filtering on the Table column.


Whenever the Fields Grid is sorted primarily by the table, you can use drag-ordering to place a table's fields in the order you find convenient. This display order of fields is purely visual and has no effect on anything other than the Fields Grid. When the Fields Grid displays fields from multiple tables, you have to be careful to only drag-order fields of a table within that table: dragging a field outside of the range of fields belonging to the same table (or even to its top or bottom) will result in the field ending up in unexpected places. Drag-ordering therefore works best when the Fields Grid is filtered to display fields from only a single table.


Following is a list of the available columns and their descriptions.

ID is the usual auto-incremented field ID.
Table is the table the field belongs to.
Created/Modified are the usual dates.
Author is obviously the creator of the field.
Type is the data type of the field, e.g., Integer, String, etc. We'll be discussing these shortly.
Length is the length of the field. This is only meaningful for String fields. More on this later.
InfoView Item offers you a choice of what Control to represent the field with on InfoView forms. We'll talk about it in a bit.
Name is the name of the field. This is what goes into the actual physical table structure. You may not be able to change it for any fields referenced from any InfoView forms, so choose field names carefully. They must start with a letter and must only contain alphanumeric characters or the underscore.
Remark is similar to Name, except that the Remark is for your information only: it is not used by Alventis, so you can set it to whatever you find meaningful. You are free to use whatever characters you like here.
Caption will be used, where appropriate, as the default Caption for the Control representing the field on the InfoView form. You can edit all Control's Captions later, but you have an opportunity here to specify a sensible default value in case you end up "implementing" the same field more than once, perhaps on multiple InfoViews.
Comment is just a comment you want to associate with the field. Except that this Comment is saved in the physical table structure and it is used under some circumstances as a replacement for the field's Name in Captions (for instance, it may get used by grids displaying records from the table). You should therefore leave it empty unless you know what the consequences are and when/where they will manifest themselves.
Default Value is the default value you'd like this field to get assigned when creating new records. You must specify values that make sense for the data type of the field, e.g., an Integer field may have a Default value of 25 but not Xyz.
Text-Indexed, when checked, specifies that the field's contents should be indexed using Alventis' full-text indexing, so that searches performed in UniGrids would take its contents into consideration. By default, all String and Memo fields are indexed in this fashion, so Alventis searches through all your textual data. You can disable full-text indexing of some fields if you do not want them to be searched for some reason.
Read-Only, when checked, specifies that the field is read-only and should not be editable by the user. Some standard System fields are read-only due to their nature, for example. Setting this flag to true may only make sense for your own field if it has already received all the values you want, so no further editing should be possible. This sounds like a far-fetched scenarios though, so you'd typically want to leave this checkbox in its default, unchecked state. You can always make read-only the Control that implements this field on a specific InfoView, which would probably make much more sense.
Required, when checked, specifies that this field must be assigned a value for a record to be posted to the table. An attempt to post a record with this field left empty will generate an error that the user will need to correct. You can use this to ensure that the most crucial information is never left blank.
Formula is used for Calculated Fields. This is a fairly advanced topic, and we'll discuss it in the Calculated Fields chapter.
Pointer Target column is only applicable to Pointer type fields that are used to link Relational tables. We'll be looking at them in more detail at a later time.



Let's go back and examine some columns we have mentioned in more detail.


Data Types. Designer supports the following field data types:


StringText of the specified Size (1 to 512 characters)
Small Integer16-bit integer (-32,768 32,767)
Word16-bit unsigned integer (0 65,535)
Integer32-bit integer (-2,147,483,648 2,147,483,647)
Large Integer64-bit integer (up to +/-9,223,372,036,854,775,807)
FloatFloating-point number: positive or negative, 5.0 * 10^-324 to 1.7 * 10^308 with an accuracy of 15 digits
CurrencyFloating-point monetary amount number
Auto-IncrementAuto-incrementing 32-bit integer counter
BooleanBoolean (True/False)
Date/TimeTimestamp, i.e., both Date and Time
MemoAlventis Memo
Pointer32-bit integer used as foreign key


We'll be talking about some of the above Types in the following sections. Changing a field's Type may result in data loss, so you must be extremely careful (and have a recent backup which is something you should have in any case). Some field conversions work with no data loss. For example, converting a String field that holds properly-formatted integers to an Integer field should preserve the existing values. Most field types should convert to String type with few problems. Beyond that, you should exercise caution. Same goes for String field's Length. Extending the Length of an existing String field will always preserve existing data. Conversely, reducing its Length will preserve whatever fits, but may obviously "chop-off" long text values.



InfoView Item. Designer uses the following principle to simplify your task of creating InfoView forms. Each field of a table is assigned a particular InfoView Item, also referred to as Control. This is the widget or thingy that will appear in the InfoView and will be used to display and edit the field's value. We could say that a Control "implements" a field, is attached to it, and so on. Designer therefore establishes an essentially one-to-one relationship between fields and Controls. This way, when you want to "place a field on the InfoView", Designer knows what actual Control attached to that field it needs to place on the form. This is why every field must have a Control associated with it. For some field Types you have a choice among several suitable Controls. For others, e.g., Graphic or Memo, there's but a single one.


Following is a list of field Types together with what Controls may be used to represent each of them.


StringEdit Box
Radio Button Group
Immediate Lookup Combo
Multi-Line Edit Box


Small IntegerEdit Box
WordRadio Button Group
IntegerImmediate Lookup Combo
Calculator Edit Box


FloatEdit Box
Calculator Edit Box
Currency Edit Box


CurrencyEdit Box
Calculator Edit Box
Currency Edit Box


Auto-IncrementEdit Box

Large Integer


Radio Button Group
Immediate Lookup Combo


DateDate Edit Box



TimeTime Edit Box






PointerLookup Combo Box



We will now take a look at each Control individually.


Edit Box. This is the most basic of them all: the common Text Box for general-purpose text entry. A natural choice for String fields.
Multi-Line Edit Box. A plain-text memo which may be suitable for some String fields, especially Calculated or other read-only ones.
SpinEdit. An editor suitable for numeric fields. You can change its value by "scrolling" it with the mouse.
Currency Edit Box. Essentially an Edit Box that always displays its contents with your locale's Currency format, e.g., $1,200.00.
Calculator Edit Box. An Edit Box with a little calculator attached to it. Allows you to enter the value you want either directly or by using the calculator.
Checkbox. We're sure you know these "squares".
Date Edit Box. An editor with a dropdown calendar to help you enter a date (which you can key-in directly if you prefer).
Time Edit Box. Same idea, but you enter the time using a dropdown clock.
Image. A Picture Box that allows you to display, load, and save images stored in the corresponding field.
Memo. The opulent Alventis Memo editor with all its richness of formatting.
Radio Button Group. A Radio Group Control allows you to represent a small set of possible field values as a group of options (each a Radio Button). The underlying field values may be: any integral numeric type (1/2/3/4), a String ("NY"/"CA"/"TX" field values may be represented by Radio Buttons "New York"/"California"/"Texas", for example), a Boolean (True/False can be expressed as "Yes"/"No", "To be"/"Not to be" or whatever else suits you).
Immediate Lookup Combo. Same exact idea as Radio Group but implemented as a combo box. The functionality and applicability is the same, only the actual interface of the Control is different.
Lookup Combo Box. A combo box that displays a grid of records from another table, one referenced by (or pointed to) by the field this Lookup beast of a combo box represents. We will get to know it better when we talk about Relationality.


There may be times when you would want to represent a field using different Controls. For example, you may be creating two InfoView forms for the same table. One could be representing an integer field as a Radio Button Group, while the other could benefit from using an Immediate Lookup Combo in its place. Whatever the case may be, it's quite easy to implement the same field using more than one Control that it supports. Just edit the field changing its Control value to whatever you wish to create at that particular moment in time and off you go. We'll talk much more about actually placing Controls on InfoViews later though.


As soon as you create a new table (in the Tables grid), its standard System fields are automatically created. There are very few things you can modify about those, and Designer won't let you alter things you shouldn't meddle with. You may change the length of the system String fields and disable full-text indexing for them. You can also change the Control, Title, Caption, and Comment. With your own fields, you have no limitations.


You can create new fields and delete existing (non-System) ones directly in the Fields grid as you'd do with any grid record. The Fields grid tries to help you as much as it can. For example, the Type you select for your field influences the behavior of many of the remaining columns: some will offer suitable defaults, others won't let you edit them if this is not appropriate for the selected Type, etc. In all cases, if you can't seem to be able to edit a certain cell's value, this is because you shouldn't. In most cases, the grid will tell you why in the Status bar at the very bottom of the FieldView form. You can clear the message at any time once you no longer need it by clicking the Clear button on the right.