How to achieve consistent appearance for field rule lookup

[rmcgaffic]

Why should the appearance of a field rule lookup look different depending on its source? Can this be changed to achieve a consistent look?

Screen 1 shows a lookup display for a field where the lookup was defined with user entries. Note that font and size of list is the same as the field; note that the entries are left aligned with the form's field.

Screen 2 shows a lookup display for a field where the lookup was defined using a table. Note that the size and font of the list are different than the size and font of the related field. Also note that the list is indented and a small checkmark appears at the left of the selected entry. Finally note that the popup appears larger than necessary and displays lots of extra white space after the last entry, not to mention the unneeded vertical scrollbar.

If the checkmark and indentation is not necessary for user defined entries, why does it appear on the list populated from a table?
Can this be fixed or must it be added to the growing list of fit-and-finish issues on the wish list?

Bob McGaffic
Pittsburgh

A stronger design be to allow both approaches to be used, with either user entries or table values, and allow the developer to choose

[Keith Hubert]

Re: How to achieve consistent appearance for field rule lookup

Hi Bob,

I dont think there is anything to fix here. I would consider this to be part of the flexibility of Alpha.

Have you tried to use your own lookup browse instead of the default?

[rmcgaffic]

Re: How to achieve consistent appearance for field rule lookup

Keith,

I was hoping the Alpha Five would allow the flexibility to choose either approach and not force such an inconsistency.

It makes no sense to me that the source of the information would determine the appearance of a look up field.

This inconsistency is not found in the native A5V9 combo box. But unfortuantely yet another problem has surfaced with it.

Screen 1 shows two combo boxes, both defined using Tahoma 24 point bold italic. The left box is defined using user entered values and the right box is defined using a table lookup.

Screen 2 shows that the values displayed are left aligned

Screen 3 shows that possible values (user entered) are left aligned, with no indentation and no little checkmark symbols

Screen 4 shows that possible values (from lookup table) are left aligned, no indentation and no little checkmark symbols.

In other words, Alpha has defined its combo box so that the appearance is the same regardless of the source of the data. It should take the same approach with the display of lookup fields.

But wait. Another problem appears. Notice on screen 2 that even though both combo boxes were defined as 24 point Tahoma bold italic, the initial display of the right combo box is 24 point Tahoma. It is only after placing the cursor on the right combo box, shown in screen 4 does the value display correctly in 24 point Tahoma bold italic.

I also tried this in A5V8 and see the same problem there.

Screen 5 shows A5V8 shows intial display of combo box values and screen 6 shows display when the right combo box receives the cursor.

Is there a setting that I'm overlooking somewhere that causes this inconsistent behavior?

Bob McGaffic
Pittsburgh

[G Gabriel]

Re: How to achieve consistent appearance for field rule lookup

Robert:
I don't dabble with Field rules and won't claim any expertise in that but from what I remember, you have an option to use a companion browse and if you choose that, then you could probably get the consistency you are looking for. I don't know how well that will look or work, but I thought I point you there and let you experiment with it.

[Keith Hubert]

Re: How to achieve consistent appearance for field rule lookup

Hi Bob,

Gabe has made the same suggestion that I gave you, have you tried that?

It seems that we both think that will help you.

[rmcgaffic]

Re: How to achieve consistent appearance for field rule lookup

Keith and G,

I probably won't have time to try your suggestion until this weekend (can you tell I'm a hobbyist developer?). I am looking forward to do so then.
Thanks to you both.

Bob McGaffic
Pittsburgh

[rmcgaffic]

Re: How to achieve consistent appearance for field rule lookup

Keith and G,

Maybe I’m missing something. --> Yes, I did. Please see subsequent posting.

The companion browse appears to be defined at a form level, not the field level. When I select a field and examine its properties, I can’t find where it is assigned.

On which tab of the field properties dialog box is the companion browse specified?

When I define a companion browse and push the F8 key, it is displayed from ANY
field on the form. For example, if I define a companion browse of Telephone types, then on the field for eAddress types, press F8, the browse will propose telephone types rather than eAddress types. This is not what I’m trying to achieve. I want to display telephone types from that the telephone type field, and eAddress types from that the eAddress type field.

Further thoughts:

I am delighted with three aspects of A5V9’s field rule lookup functionality:

1. The ability to choose between a drop down list and a popup list. Very nice!
2. The very discrete hiding of the pull down button until the cursor is on the field. Absolutely beautiful. Do you know how you do this in Access? You create a little opaque square, manually position it over the button’s arrow, and then write code to make the square transparent or opaque. No I’m not making this up. Google search for Hide Combo Box Button When Not In Focus. Imagine doing this for every combo box in your Access application!
3. Allow the field lookup values to be driven from directly from the table, not by specifying a separate query each time the lookup is used. What a time saver! What easy maintenance!

So perhaps you can appreciate my frustration, when I find that that this awesome functionality is marred, simply because no effort was made to ensure that the field rules display of values is consistent with the appearance of other desktop controls, when used for the same purpose.

I’m hoping someone can help me understand the reason for this schism.

Why are the fonts different?
Why are the font sizes different?
Why is a vertical scroll bar displayed a few number of records do not require a scroll bar to display them all?
Why is the combo box display left aligned and the field rule display indented with a checkmark?

Why is it seemingly so hard to get these small details right?

Microsoft Access may lack a lot of A5V9's rich capability, but at least with it, you never have to apologize for a form's appearance.

Bob McGaffic
Pittsburgh

[rmcgaffic]

Re: How to achieve consistent appearance for field rule lookup

Peter and G,

I finally figured out what you were referring to:
Table>Edit field rules...
Select the field: tblTelephone->TELEPHONE_TYPE
Lookups tab
Browse layout to: ENTER THE NAME OF YOUR CUSTOM BROWSE LAYOUT HERE.

Got it!

In Microsoft Access you can populate a combo either from a table or a query.
Doing the above in A5V9 I think will allow me the visual result I am seeking, but at the expense of an extra maintenance step.

So again thanks for your suggestion. I think I can take from there. But wouldn't all developers benefit from better control appearance consistency To me, maintaining these separate browses are non-valued added work, especially since A5V9 still does not allow a browse control to be specified on its style sheet. Why must it be this hard?

Bob McGaffic
Pittsburgh

[rmcgaffic]

What's wrong with this picture?

Why do the the font, size, italics, bold, etc. properties fail when a field is defined with a data source of a table lookup?

The screen shows a type in field whose font size is Tahoma 18 point bold italic.

The Lookup tab for the field rule for this field is defined as a table lookup.

A5V9 appears to have �hardwired� font, its size, and all its attributes.

Wouldn�t a more obvious design choice be to use the same font, size, and attributes of the field being populated?

To compensate for this weakness, as pointed out by Keith and G, you can define a custom browse and then reference that in your lookup table specification. The problems in doing so are documented in a separate posting �Browse Object Explorer Settings Fail�.

Would it surprise you, that in design mode the Object Explorer settings work, but in view mode they revert back to yet more �hardwired� Alpha settings!

Bob McGaffic
Pittsburgh

[MikeC]

Re: How to achieve consistent appearance for field rule lookup

Would it surprise you, that in design mode the Object Explorer settings work, but in view mode they revert back to yet more “hardwired” Alpha settings!

Not at all, am sad to say. :(

Have had my share of these issues, but submitted 3 similar ones about a month too late (by my guess) for a version 8 "bug"---problem is, any fix may well be just to take out the contradictory Object Explorer references....which would be a step backward but at least reduce the confusion over why it does not work.

[gmeredith17]

Re: How to achieve consistent appearance for field rule lookup

The question is

'is it a bug or a flaw?'

One requires a bug report and the other needs to be added to the wish list. Maybe do both to cover all bases.

[rmcgaffic]

Good news: it works in V8; Bad news: it doesn't in V9

Here is a copy of the bug report I filed today. I filed this as a wish list item last week, but have retracted that request.

Bug description: Field rule lookup based on table fails in V9, OK in V8

I originally posted this issue on the wish list, but have now determined that it is a bug, new to version 9. There was no such bug in Version 8.

Whether the data source is user entries or a table lookup, field rule edit lookups should look the same. This is not the case with version 9, but was the case for version 8.

Actually, I stumbled on this Version 8 capability in your documentation. See "Comparing drop-down lists and popup dialogs". The example used is the Alpha Sports Invoice form. Note in that documentation, the field lookup for Product description has the desired appearance.

When I noticed that the lookup was defined using a table and had exactly the look and feel I sought, I said EUREKA!!! I felt better knowing that at least in the past, Alpha got this right.

Screen 1 Version 8: A type in field on a form is defined with a field rule to use a table lookup. Notice how clean and simple this is. Nothing out of the ordinary, just what you would expect.

Screen 2 Version 9: Exactly the same tables, forms, field rule definititions but what a difference in display, namely:

a. The lookup list is not displayed in the font of the type in field; it should be. The field is Tahoma 12 point and the list is Arial 8 point.

b. The lookup list is displayed with buttons. Note in Version 8, values are listed without buttons.

c. The selected button has a checkmark on it, and a hard to see one at that. Black on dark blue doesn't get high marks for readability.

d. The display needlessly displays unneeded white space for the list. There are only four records and yet a vertical scrollbar is used in an area that would accomodate three times as many records. Aren't Alpha scrollbars supposed to be displayed dynamically?

Bob McGaffic
Pittsburgh
[email protected]

[Keith Hubert]

Re: How to achieve consistent appearance for field rule lookup

Hi Bob,

I understand what you have written, but just need to ask you a couple of things to clarify what you regard as being a bug.

field rule edit lookups should look the same

Who said so? Where is this written?

The lookup list is not displayed in the font of the type in field; it should be

Who said it should be?

b. The lookup list is displayed with buttons

What is wrong with that?

c. The selected button has a checkmark on it

IMHO Not enough to regard as a bug.

d. The display needlessly displays unneeded white space for the list

The size can be changed in design mode of field rules. Not really a bug.

Aren't Alpha scrollbars supposed to be displayed dynamically?

Seems not on all occasions. If you change the size, then this is also not an issue.

There are many things in V9 that are not in V8, I would not regard these differences as Bugs. Personally I would ask Alpha why some of these things have changed and if it was possible to get a little more consistency.

I'm sure that these items that you have spent so much time on, have not meant the application could not be built to perform as a viable database.

[rmcgaffic]

Re: How to achieve consistent appearance for field rule lookup

General design principles

Users expect controls to behave in a consistent way and to have a consistent appearance. This is a general rule of good gui design.

A useful reference is User Interface Design for Mere Mortals, 2007, available from Amazon.com, $36.47. Relevant chapters include:

Chapter 4 Good Design
Chapter 5 How User Behave
Chapter 6 Analyzing Your Users
Chapter 7 Designing a User Interface

Note this book focuses on the design of controls and the user interface, not the misapplication of controls. For the latter, see GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos, available from Amazon.com, 2007, 32.97. Relevant chapters include:

Chapter 5: Graphic Design & Layout Bloopers

Also http://www.gui-bloopers.com/

Commercial application development tools and controls

I have done a search on third party activeX controls and can not find one ActiveX or .net controls displays its values like A5V9 forces upon a user. Take a look at the following ActiveX controls from commercial controls firms whose business is creating useful, functional, consistent, and yes, beautiful appearance.

http://www.dbi-tech.com/ctCombo.asp
http://www.codejock.com/products/com...rs/tour_19.asp
http://www.infragistics.com/dotnet/n....aspx#Overview

not to mention the 800 pound gorillas of Microsoft Visual Studio, Miscrosoft Access 2003 and Access 2007, and SAP.

Alpha's own design

1. When Alpha creates a default form, the font, size, and attributes of the label are the same as the text. Consistency in appearance is not a new concept to Alpha.

2. When Alpha displays records for a combo box, the font, size, and attributes of the list are the same as the field for entry. Further, and most importantly, the source of the data doesn't matter. A combo box populated with user defined entries looks the same as a combo box populated with table lookup entries. A user doesn't care about the source of the data. Consistency in appearance is not a new concept to Alpha.

3. Software houses generally go to great lengths to offer upgrades with backwards compatibility. As seen in screen 1 of my earlier posting, Version 8 Alpha can display field rule lookup values in a manner consistent with Version 8's combo box, but Version 9, shown in screen 2, can not. Upgrades and new versions generally offer additional functionality, rather than removing existing functionality.

4. I haven't been able to find any documentation suggesting that the lookup for a type in field should be different from a lookup field in a browse. See Alpha's own documentation cited in my earlier post.

Summary

Alpha Five should offer the backwards compatibility for Version 9 with Version 8. The fact that this functionality previously existed suggests to me that it was an oversight not to bring it into Version 9.

If on the other hand, Alpha just says tough, we don't care what your form looks like, go and design your own custom browse (which is non-value added work), they need to correct the four bugs I identified in trying to do just that:

1. Browse Title font property fails when used for rule lookup
2. Object explorer property Show Titles fails for Browse
3. Combo box font fails
4. Combo box vertical alignment property fails

Bob McGaffic
Pittsburgh

[rmcgaffic]

Another bug reported for field rule lookup using browse

I have reported another bug in my attempt to use a browse as a field rule lookup based on a table.

The browse lines properties all fail when the browse is used with the field rule, even though the browse itself seems OK.

Just for the record, here's the problem:

Browse line style properties fail when used with field rule lookup

To reproduce this error:

1. In design mode, note that browse brwLookup is defined with the following line style properties, screen 1:

Title Rose Solid
Row selector Rose Solid
Horizontal lines Rose Solid
Vertical lines Rose Solid

2. In view mode, note that the browse is correctly displayed with rose solid lines, screen 2

3. Assign the browse to the field rule for Telephone type, screen 3.

4. Execute form frmPerson and click on field telephone type, screen 4.

Note the following bugs:

Horizontal lines are not Rose, in fact, there are no horizontal lines
Vertical lines are not Rose, in fact, there are no vertical lines