Contributed by Sharon Buntz
The purpose of the Required Column service is to stop the native PowerBuilder message "Value required for this item" from popping up each time the user leaves a required field empty and tabs out. Users like this feature of the PFC which eliminates this annoying message, because otherwise, they can become "trapped" in an entry field, unable to leave it until they enter something.
With the Required Column service turned on, basically, the validation of the required columns is postponed until it is time to save the DataWindow.
But please note that the name of the "Required Column" service is a bit of a misnomer. This is because with or without the Required Column service turned on, the PFC will still notify the user which required columns are missing at save time. And the PFC will still show its customized message to tell you which column on which row is missing. That logic is in the u_dw's of_CheckRequired( ) function. It happens regardless of if the service is on. (Even regardless of whether the trick "Empty String is NULL" property is set for the column.) ... To help demystify this service, here is the only time that the Required Column service comes into play:
In u_dw's ItemError event: // If appropriate replace an empty string with a null value and suppress the // standard DataWindow Value Required Message. If IsValid(inv_reqcolumn) Then If inv_reqcolumn.of_SetToNullIfEmpty(row, String(dwo.Name), This.GetText()) > 0 Then Return 3 // Reject the data value but allow focus to change. End If End If
Therefore, all that the Required Column service does is stop PowerBuilder's native message when the user tabs out of a missing required column (or whenever an AcceptText( ) flags a required column). And so it might more appropriately be thought of as something like "Stop Native PowerBuilder Required Message" service. But that is hard to say...
In summary, in layman's terms, we often intermix the Required Column service with the normal PFC u_dw behavior. And in this FAQ, will will cover the overlapping "Required Column concerns". And you may think of it this way:
The net effect of the Required Column service, combined with the normal u_dw behavior, is:
The validation of required columns is postponed until it is time to save the DataWindow.
Contributed by Sharon Buntz
Contributed by Sharon Buntz
Make sure that you have checked the "Empty String is NULL" checkbox in the DataWindow painter for each column. For the Required Column service to work properly it needs to have this NillIsNull property set for each column.
If your column has an Edit Mask, please see No matter what, I still get prompted when a required field with an Edit Mask loses focus.
Another thing to check is if you have used the of_RegisterSkipColumn(<column name>) function. If you have called this function for a particular column, you will still get prompted when that column loses focus. That is the purpose of this function.
Yes, the of_RegisterSkipColumn( ) function is a little confusing. Remember, the Required Column service simply stops the native PowerBuilder required column message of "Value required for this item" from happening. So telling the Required Column service to skip a column, tells the service to not stop the message. This is basically the same as saying, "Tell the user that this column is required as soon as the user tabs out of the column". Please note though, that even if you call this function and tell the Required Column service to go ahead and show the native PB message, the normal u_dw processing will still check all columns at save time and notify the user of missed required columns at that time as well.
Contributed by Sharon Buntz
The Required column service needs a couple of extra checks to handle required columns with Edit Masks properly. Here's how to fix it (Please see note below if you are only concerned with Numeric Edit Mask Columns):
Override the Required Column's of_SetToNullIfEmpty( ) function and add the following Blue code:
boolean lb_editmask_and_required// Determine if the field is required and has an edit mask. Set flag accordingly. ls_describe = as_colname + '.EditMask.Required ' ls_rc = idw_requestor.Describe(ls_describe) If Pos(Lower(ls_rc), 'yes') = 0 Then lb_editmask_and_required = FALSE Else lb_editmask_and_required = TRUE End If// Determine if the field has an empty value (ignoring required fields with edit masks). If not lb_editmask_and_required then If as_text <> '' Then Return 0 End If<omissions>// The field is a Required Field; Now determine if Nulls are allowable (ignoring required fields with edit masks). If not lb_editmask_and_required then ls_describe = as_colname + '.Edit.NilIsNull ' + & as_colname + '.DDLB.NilIsNull ' + & as_colname + '.DDDW.NilIsNull ' ls_rc = idw_requestor.Describe(ls_describe) If Pos(Lower(ls_rc), 'yes') = 0 Then Return 0 End If
Note: If you are only concerned with Numeric Edit Mask Required Columns then...
Your simplest option is to specifiy a format "mask", but leave the Edit Style to simply "Edit" vs. "Edit Mask".
This will display the column as formatted, but it will switch to not using a mask when the user is in a particular column on a particular row. (Most users prefer this anyway since numeric edit masks act a little non-standardly.)
Still remember to check the "Required" and "Empty String is NULL" Edit properties as usual with this option, and everything will fall into place naturally.
Contributed by Sharon Buntz
U_dw's of_CheckRequired( ) function uses the DataWindow column name when displaying an error message that tells the user that the column is required. And this column name is very cryptic to the user.
On the surface, you might think that the Required Column forgot to provide a way for us to customize the name, like the filter/sort/query services provide with their "Set Style" functions. But, again, remember, u_dw's of_CheckRequired( ) function is not a part of the Required Column service.
Therefore, in order to change all error messages to use a more user-friendly column header name throughout all of your DataWindows whenever a required message is displayed, consider simply doing the following:
In u_dw, override the of_CheckRequired( ) function to incorporate these changes:string ls_ColumnName //Add ... // Enable the base service if not already enabled If IsValid(inv_base) Then ls_ColumnName = inv_base.of_GetHeaderName(as_colname) ElseIf of_SetBase( TRUE ) = 1 Then ls_ColumnName = inv_base.of_GetHeaderName(as_colname) of_SetBase( FALSE ) Else ls_ColumnName = as_colname End If If IsValid(gnv_app.inv_error) Then ls_msgparm[1] =as_colnamels_ColumnName //Change ls_msgparm[2] = String (al_row) gnv_app.inv_error.of_Message('pfc_requiredmissing', ls_msgparm, & gnv_app.iapp_object.DisplayName) Else MessageBox ( gnv_app.iapp_object.DisplayName, "Required value missing for " + &as_colnamels_ColumnName + " on row " + String (al_row) + & ". Please enter a value.", information!) //Change End If
Contributed by Sharon Buntz
U_dw's pfc_validation event calls of_CheckRequired( <buffer>, etc ) function for only the Primary! buffer. It does not call it for the Filter! buffer. Thus, if you have filtered rows, they will not be checked for missing required columns.
To remedy this, you can simply extend pfc_validation on u_dw to call of_CheckRequired( <buffer>, etc ) function for the Filter! buffer as well.
Also, you may want to realize the impact of the filtered rows being ignored when using the Linkage service, a la Filter style. For this, you can trace through the linkage to find parent rows, select rows and then explicitly call the pfc_RequiredMissing error message.
Contributed by Sharon Buntz
Do not specify an "Initial Value" under the Row/Column Specifications for any numeric column. This is because 0 is a valid entry, so nothing will flag the column as missing.
Similarly, if an entry of the value of 0 is not valid, you must also add a validation check that says that a value of 0 is invalid in your DataWindow's pfc_validation. This is because if the user explicitly enters the value of 0, that is a valid entry, and nothing will flag it as missing.
Contributed by PFCGuide staff, except
where noted otherwise.
PFCGuide is sponsored by Dynamic Technology Group
The information provided is for advice only and not to be considered a contract or a
liability against Dynamic Technology Group.
Last revised: February 15, 2004 03:58 AM.