Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook
Devcon 2020 Goes Virtual! LEARN MORE >

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Browse height property fails for browse used with field rule lookup

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
    #1

    Browse height property fails for browse used with field rule lookup

    This looks like a bug, but I�m posting it here before formally reporting just in case I�ve done something wrong.

    When I noted in an earlier post that A5V9 needlessly displayed extra lines at the bottom of a browse called by a field rule lookup, at least one forum member suggested changing the height of the browse.

    I�ve found that when you create any new browse, the height property has a default value of 901 regardless of the number of records actually displayed.

    When you change that height, the browse is correctly displayed in display mode, but not when the browse is called from a field rule lookup.

    Has anyone been able to successfully change the height of a browse called from a field rule lookup?

    Screen 1
    Shows a browse in design mode. Note height property is set to 150.
    Also note that the browse is appropriately shortened.

    Screen 2
    Shows the browse in view mode. The browse height appears correct.

    Screen 3
    Shows the browse called from a field rule lookup. The browse height is not correct.

    Screen 4
    Shows the browse in design mode. Note that the height property is set to 150, but when the property is selected A5V9 displays 901, not 150 as the field value. The number on the tree is 150, but the number in the type in field is 901.

    Where does the value of 901 come from?

    Bob McGaffic
    Pittsburgh
    Tags: None
    #2
    Re: Browse height property fails for browse used with field rule lookup

    I have reported this issue is a bug. Unfortunately, I have discovered yet another bug with the field rule lookup as described below. I have filed a bug report on it also.

    This brings to seven, the number of bugs I have found with the browse used as a field rule lookup. The first five were corrected by the Alpha Team in their most recent patch, leaving the last two outstanding.

    Here's the tally
    1. Browse title font property fails when used for field rule lookup
    2. Combo box font fails
    3. Combo box vertical alignment property fails
    4. Object explorer property Show Titles fails for Browse
    5. Browse line style properties fail wehn used with field rule lookup
    6. Browse height property fails with field rule lookup
    7. Custom browse selected value write to database fails when field lookup used

    Here's the latest bug report filed:

    Custom browse selected value write to database fails when field rule lookup used

    Note A5V9 updates through 08/09/08 applied

    When a custom browse is used to populate a field using a field lookup rule, the value does not persist, but reverts back to the initial value once the cursor moves to another field. In contrast, when a default browse is similarly used, the field retains its value selected from the lookup list.

    To reproduce this problem:

    1. Open table tblEaddress in design mode and edit field rules. Note that field Eaddress_type sets the Browse layout to Default browse.

    2. Open table tblTelephone in design mode and edit field rules. Note that field Telephone_type sets the browse layout to a custom browse brwLookup.

    3. Open form frmPerson in view mode.

    4. Click on the field eAddress_type and from the list displayed, select a value, then tab to another field. The value you selected remains in the field and is written to the database.

    5. Click on the field Telephone_type and from the list displayed, selected a value. Note that your selected value is correctly displayed in the field. Now tab to another field on the form. Note that the selected value that you entered is now replaced with the intial value of the field.

    Comment

      #3
      What would it take?

      What would it take to restore Version 8 functionality to Version 9 for either field rule lookup with default browse or a custom browse?

      Version 8 (Screen 1) offered the above simple display for a field rule lookup. This display is consistent with how Version 8 and Version 9 both display combo box values.

      Version 9 (Screen 2) abandoned the combo-box style list of values with the browse shown above. This field rule lookup browse was the subject of five bug reports which have been fixed by Alpha Software and two recently submitted ones which are still outstanding. Despite these fixes, I am still unable to achieve the desired consistency with A5V8 because of the row selector.

      Any ideas/rough estimates of the development effort/cost to achieve this visual consistency objective with any of the four below or other alternatives?

      1. Reinstate the code that was in place in Version 8
      2. Change the default browse in Version 9 to replicate the appearance of Version 8
      3. Assign ShowRowSelector property to a custom browse used with a field rule lookup, as presently exists for an embedded browse
      4. Create a new property of RowSelectorWidth in pixels

      I am willing to share in the development cost.

      Bob McGaffic
      Pittsburgh

      Comment

        #4
        Re: What would it take?

        Bob,

        I have enjoyed reading your posts and bug reports. You certainly are one of the most meticulous and demanding developers we have seen on this board. More power to you. Your positive criticism helps everyone here, I think. Anyway, my guess is that if Alpha fixed the first 5 bugs, they'll fix these last two.

        In the mean time, here is another possibility, although it may not meet your strict criteria (e.g. I don't believe you can control the font). See attached image...

        (In this example, the code is attached to a button)
        Peter
        AlphaBase Solutions, LLC

         [email protected]
        https://www.alphabasesolutions.com

        Comment

          #5
          Look Ma! No buttons!

          Peter,

          Thanks for your suggestion.

          Indeed there are many ways to skin a cat, but using your screenprint as an example, I would like to have the list displayed without the Gray vertical area to the left where row selector buttons or icons would normally be displayed.

          What I'm trying to do is so simple, so basic -- and something that Alpha Five Version 8 provided.

          You've worked with the Alpha Folks longer than I have, and I'd be interested in your opinion in which of the four options listed in my post above would be the most feasible.

          Why am I bothering with this? Because I love the functionality of the field rule lookup -- being able to hide the V arrow until the field receives the focus.

          A form with lots of combo box V arrows on it looks a little like acne on a teenager. Alpha gives us the possibility of a very clean appearing form. And yes, coincidentally, this is exactly the approach SAP takes. Alpha is close to giving low end developers like myself the ability to create software that looks as good as the best in the business.

          Would it surprise you to know that SAP also does not require buttons when the list is displayed as a popup, rather than a pull down?

          In summary, I don't have a problem with the row selector buttons in either pulldowns or popups but I think they should be optional rather than mandatory.

          Below are two screenprints from SAP: the first is a pull down, the second a popup. Don't these look cleaner, simpler, less fussy they they would with buttons to the left of each line.

          Or as graphic designers are oft to say: Less is More.

          I've been working with SAP software for about 14 years now. Believe me, their early form design/controls/icons were nothing to brag about. But they wisely enlisted the services of German design firm FROG (Federal Republic of Germany) who has similar upgrades for the GUI/Interfaces of Oracle, Hyperion, and Lawson among others.

          http://www.frogdesign.com/case-study...d-website.html To see other software redesign projects, click on Other Case Studies.

          Comment

          Previous template Next
          Working...
          X